International Journal of Innovative Research in Science, Engineering and Technology
MenuISSN ONLINE(2319-8753)PRINT(2347-6710)
ISSN ONLINE(2319-8753)PRINT(2347-6710)
| P.Durga, S.Jeevitha, A.Poomalai, Prof.M.Sowmiya and Prof.S.Balamurugan Department of IT, Kalaignar Karunanidhi Institute of Technology, Coimbatore, TamilNadu, India |
| Related article at Pubmed, Scholar Google |
Visit for more related articles at International Journal of Innovative Research in Science, Engineering and Technology
The paper proposes a set of diagrams based on object orientation principle which describes the functionalities from various perspectives. The diagrams depicts the functional, behavioral and structural aspects of examination management system. The proposed modeling methodology is based on the principle of object orientation, which allows describing both software and functionalities explicitly. Furthermore, it is illustrated how the well-known object-oriented specification language unified modeling language can be adopted, to provided an adequate formalization of its semantics, to describe structural and behavioral aspects of smart phone database management system related to both logical and physical parts. It is needed to implement the software on the basis of Object Oriented Model developed. Flaw in modeling process can substantially contribute to the development cost and time. The operational efficiency may be affected as well. Here special attention is paid in planning phase and the same is extended to the implementation phase of the paper.
Keywords |
| Functional Model, Behavioral Model, Object, Modeling, Operational Efficiency. |
INTRODUCTION |
| Software is very abstract and hard to visualise. A visual modelling language, such as UML, allows software to be visualised in multiple dimension, so that a computer system can be completely designed before construction work starts. Furthermore, UML can be used to produce several models at increasing levels of detail. The overall plan of the software can quickly and easily be defined at the start of the project with a high level model allowing for accurate estimation. Increasing levels of detail can then be added to each part of the software as it is constructed, until finally the software is developed.UML is applicable for both new developed and already existing systems. It is been wrongly understanded that a older system should be Re-documented for the application of newer application into it. It also improves the quality of the software engineering staffs as most of the engineers look for the company modeled with UML. The Unified Modelling Language was created by Rational Software in order to provide a standard for software modelling languages an independent organisation. |
| UML is a universal language because it can be applied in many areas of software development. It includes userdefined extensions so that it can be adapted for specific environments. Industrial standard extensions now available for business modelling and web-based applications development. The Use Case Gives the nature of modelling with UML ensuring that all levels of model trace back resembles elements of the original functional requirements. This traceability between models comes without the extra effort of creating and maintaining a 'traceability matrix' which can be a complex and time consuming job. As a result of this the required changes for the document can easily be made. With the help of this UML any requirement changes can be made without any intreruption to other requirements even the lines. If any changes were been effected then that can be easily been changed without any difficulties. In many design processes, the use case diagram is the first that designers will work with when starting a project. This diagram allows for the specification of high level user goals that the system must carry out. These goals are not necessarily tasks or actions, but can be more general required functionality of the system. |
CLASS DIAGRAM |
 |
USE CASE DIAGRAM |
| UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is rather than representing the details of individual features of an system. UCDs can be used to show all of its available functionality. It is should be noted that a USD is differernt from the flow chart, sequence diagrams because these diagrams won’t explain the details about the next execution and sub-execution steps of the system. |
| The UCD have 4 major elements, the use case diagram depicit: |
| • Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and it is drawn as a horizontal ellipse. |
| • Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures |
| • Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. The arrowheads are typically confused with data flow and as a result I avoid their use. |
| • System boundary boxes (optional). You can draw a rectangle around the use cases, called the system boundary box, to indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not. System boundary boxes are rarely used, although on occasion I have used them to identify which use cases will be delivered in each major release of a system. |
| • Packages (optional). Packages are UML constructs that enable you to organize model elements (such as use cases) into groups. Packages are depicted as file folders and can be used on any of the UML diagrams, including both use case diagrams and class diagrams. I use packages only when my diagrams become unwieldy, which generally implies they cannot be printed on a single Page. |
 |
INTERACTION DIAGRAM |
| Interaction diagrams are models that describe how a group of objects collaborate in some behavior - typically a single use-case. The diagrams show a number of example objects and the messages that are passed between these objects within the use-case. |
| Interaction diagrams should be used when you want to look at the behavior of several objects within a single use case. They are good at showing the collaborations between the objects, they are not so good at precise definition of the behavior. If we want to look at the behavior of a single object across many use-cases then use of State Transition Diagram. If you want to look at behavior of many use cases or many threads, consider an activity diagram. Much like the class diagram, developers typically think sequence diagrams were meant exclusively for them. However, an organization's business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement. When that occurs, use cases are often refined into one or more sequence diagrams. |
| • Purpose |
| The main purpose of a sequence diagram is to define event sequences that result in some desired outcome. The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to. |
| • Lifelines |
| When drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled. In fully modeled systems the objects (instances of classes) will also be modeled on a system's class diagram. Lifelines are drawn as a box with a dashed line descending from Messages. |
| • Messages |
| The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower than the previous message. At the center of the bottom edge the lifeline's name is placed inside the box. |
| • Guards |
| When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow. Here, I will discuss guards in both UML 1.x as well as UML 2.0. In UML 1.x, a guard could only be assigned to a single message. To draw a guard on a sequence diagram in UML 1.x, you placed the guard element above the message line being guarded and in front of the message name. Except for the activity nodes the other notation elements of interaction overview diagrams are the same as for activity diagrams, such as initial, final, decision, merge, fork and join nodes. The two new elements in the interaction overview diagrams are the "interaction occurrences" and "interaction element. UML 2 has introduced significant improvements to the capabilities of sequence diagrams. Most of these improvements are based on the idea of interaction fragments which represent smaller pieces of an enclosing interaction. Multiple interaction fragments are combined to create a variety of combined fragments, which are then used to model interactions that include parallelism, conditional branches, optional interactions. |
 |
 |
CONCLUSION AND FUTURE WORK |
| The paper proposes a set of diagrams based on object orientation principle which describes the functionalities from various perspectives. The diagrams depicts the functional, behavioral and structural aspects of examination management system. The proposed modeling methodology is based on the principle of object orientation, which allows describing both software and functionalities explicitly. Furthermore, it is illustrated how the well-known objectoriented specification language unified modeling language can be adopted, to provided an adequate formalization of its semantics, to describe structural and behavioral aspects of smart phone database management system related to both logical and physical parts. It is needed to implement the software on the basis of Object Oriented Model developed. Flaw in modeling process can substantially contribute to the development cost and time. The operational efficiency may be affected as well. Here special attention is paid in planning phase and the same is extended to the implementation phase of the paper. |
References |
|