OOAD Lab Manual

www.jntuworld.
com
HISTORY OF UML
Objectoriented modeling language appeared some time between the mid 1970s and the 1980s as methodologist faced with genera of OOP languages and increasingly complex applications began to experiment with alternative approaches to analysis and design. Many users of these methods had trouble finding a modeling language that met their needs completely, thus finding the so-called method wars. A critical mass of ideas started by the mid 1990s, when Grady Boach (Rational Software Cooperation), Ivar Jacobson (Objectory), and James Rum Baugh (General electric) began to adopt ideas from each others methods, which collectively were becoming recognized as the leading object-oriented methods world wide. As the primary authors of the Boach, OOSE and OMT methods we were motivated to create a unified modeling language for three reasons, First, our methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart. Second by unifying our methods, we would bring some stability of the object-oriented market place, allowing projects to settle on mature modeling language and letting tool builders focus on delivering more useful features. Third, we expected that our collaboration would yield improvements for all three earlier methods handled well. As unification began there established three goals: 1) To model systems, from concept to executable anti-fact, using object-oriented techniques. 2) To address the issues of scale inherent in complex, mission-critical systems. 3) To create a modeling language usable by both humans and machines. The UML effort started officially in October 1994, when Ram Baugh Joined Bough at Rational. Maintenance of the UML was taken by the OMG. Revision Task Force (RTF), led by Kris Kobryn. The RTF released UML 1.3 in 1998 which provides some technical cleanup.
I IM MP PO OR RT TA AN NC CE EO OF FU UM ML L
Modeling is a proven and well-accepted engineering technique. A model is a simplification of reality A model provides blue prints of a system. Model includes those elements that have broad effects and omits minor elements that are not relevant to different aspects using different models. Each is a semantically closed abstraction of system. We build models so that we can better understand the system we are developing. Modeling is not just for big systems. However, its definitely true that the larger and more complex the system, the more important modeling becomes, for one very simple reason. We build models of complex systems we cannot comprehended such a system in its entirely.
www.jntuworld.com
A AI IM MS SO OF FU UM ML L
1) 2) 3) 4) Through modeling, we achieve four aims. Models help us to visualize a system as it is or an as we want it to be. Models permit us to specify the structure or behavior of a system. Models gives us a template guides us in constructing a system. Models document the decisions we have made.
Application areas of UML UML is intended primarily for software-intensive systems. It has been used effectively for domains such as o Enterprise information systems. o Banking and financial services. o Tele communications. o Transportation. o Defense/Aerospace. o Retail. o Medical electronics. o Scientific. o Distributed web-based services.
U UN NI IF FI IE ED DL LI IB BR RA AR RY YS SY YS ST TE EM M
REQUIREMENTS:A library lends books and magazines to members who are registered in the system. It also handles the purchases of new books and magazines for the library. Popular titles are brought in multiple copies. Books and magazines are removed when they are out dated (or) in poor conditions. A member can reserve a book or a magazine that is not currently available, so that it can be notified to the reserved person when it is return or purchased by library. The library can create, update (or) delete information about the books (or) delete information about the books (or) members and borrowings.
U US SE EC CA AS SE ED DI IA AG GR RA AM M
TERMS AND CONCEPTS:A use case diagram is a diagram that shows a set of use cases and actors and their relationships.
www.jntuworld.com
A use case diagram commonly contain Use cases Actors Dependency Generalization and Association Relationships.
Use case diagrams may also contain packages, which are used to group elements of your model into larger chants. Use case diagram is used in one of two ways 1) To model the context of a system. 2) To model the requirements of a system. Modeling Techniques: 1) Identity the actors that surround the system by considering which groups require help from the system to perform their tasks, which groups are needed to execute the systems functions; which groups interact with external hardware or other software systems; and which groups perform secondary functions for administration & maintenance. 2) Organize actors that are similar to one another in a generalization/specification hierarchy. 3) Where it aids understandability, provide a stereotype for each such actor. 4) Populate a use case diagram with these actors and specify the paths of communications from each actor to the systems use cases.
www.jntuworld.com
U US SE EC CA AS SE ES S
D DO OC CU UM ME EN NT TA AT TIIO ON N::-1) Issue Membership:
Primary Actor: Member Secondary Actor: Librarian The person who are interested can take the membership in the library and can use for services. All the information about members is maintained by the system. Flow of Events: The member asks the librarian for membership to library. Then librarian verifies the member is from staff or is a student.
www.jntuworld.com
If member is not a student or staff then librarian rejects his request. If the member is either from staff or a student then the gives a form to fill up with his details. When the member finishes the form the librarian issues membership. So that the member can access the books from library when ever S/he requires. Precondition:The person who is requesting for a membership should be a staff or student. Post condition:- NO. 2) BOOK ISSUE:Primary actor: Library staff Secondary actor: Member. The library staff issues the requested book to the member by specifying issue date and return date. Flow of Events: The library assistant fills the form by selecting book requested by the student and requested for a search in the current list. If the book is found in the list, mark the book in student account by student id. If the book is marked under issue, indicate the same to the student. If book not found in the list indicates the same to the student. Precondition: the student should have an account in library and book should be available in catalogue. Post condition:- The library assistant receives the acknowledgement whether book is available or not. 3) FINE COLLECTION:Primary actor: Library staff Secondary actor: Member The library clerk checks the return date, if it expires S/he calculates the fines for extra dates and accepts from the member. Flow of Events: The member returns the books to the library. The librarian receives the books and checks the returned date. If the return date does not exceeds the specified date then the takes the books and the member is capable for taking other books. If the return date exceeds the specified date then librarian calculates the fines based on exceed time and collects money from the member.
www.jntuworld.com
4)
5)
6)
7)
When the member pays the fine then librarian gives a slip[ specifying that fine is paid and hence member can access the books. Precondition: The library clerk checks for the status of a book. Post condition: NO REQUEST BOOK:Primary actor: Member Secondary actor: library staff. Requesting a book taking place between a member and library staff. Member requests for book from the library. Flow of Events: Member request a book in the library. Librarian checks for membership if book is available issues book to member. If book that is requested is not available it to member. Librarian records the transaction of book. Precondition: The person making the request must be a member of the library. Post condition: NO. PLACE ORDER:Primary actor: librarian Secondary actor: NO Flow of Events: The librarian places the book in a particular order according to the subjects. Precondition: The librarian checks whether the books are placed in an order. Post condition: NO> CATALOG:Primary actor: Librarian Secondary actor: NO The library clerk displays the book in an order according to the subjects. Precondition: NO Post condition: NO BOOK RETURNS:Primary actor: Member Secondary actor: Library staff. The book taken by the member is returned back after the return date has been completed. Precondition: The member checks for return date of a book and then the returns the book. Post condition: NO
8) RESERVE BOOK:Primary actor: Member Secondary actor: Library staff 6
www.jntuworld.com
A member can reserve a book or magazine that is not currently available so that when it is reserved or purchased by library the person is notified. Flow of Events: The members who have membership in the library requests a book. The librarian checks the book is currently available or not. If the book is available then librarian issues the book to the member. If the book is not available currently then librarian reserves the specified book in account of person who requested it. When the book is available then librarian notifies the person who requested it and informs to the person. Precondition: A requesting person must be member of library. Post condition: NO 9) BOOK RENEWAL: Primary actor: Library clerk Secondary actor: Member. A person/member who was issued by a book should renewal the book if the return date is exceeded. Flow of Events: The members who have a book already issued by librarian can renewal the book to library. The member brings back the book to library whenever the return date of book exceeds. The librarian checks the return date and book condition and renew. i.e., reissues the book to the member. Precondition: The person should be issued by a book. Post condition: NO.
C CL LA AS SS SD DI IA AG GR RA AM M
www.jntuworld.com
S.NO. 1
CLASS Librarian
Member
Book
ATTRIBUTES Librarian_ID Librarian_name Librarian_phnno. Librarian_address Member_ID Member_name Member_address Book_ID Book_publisher Book_name
OPERATIONS
Membership()
Bookissue() Bookstatus() Bookreserved() 8
www.jntuworld.com
Book_author 4 Catalog No. of copies Book_ID Book_publisher Book_name Book_author Book_ID Book_price Book_name Book_author Book_edition status Available Reserved Issued Referenced Book_ID Member_ID Issuedate Returndate
Bookrenewal() Bookreturned() addNew() delete() modify() viewcatalog() Bookissue() Bookstatus() Bookreserved() Bookrenewal() Bookreturned Getstatus() Setstatus()
Copy
Status
Fine
CalculateFine()
Terms and Concepts

A class is a description of a set of objects that share the same attributes, operations, relationships and semantics. Graphically, a class is rendered as a rectangle. Class diagram commonly contains the following things. Classes, Interfaces, Collaboration, Dependency, Generalization and Association, Relationships. Class diagrams may also contain packages or subsystems both of which are used to group elements of your model into layer chunks. Class diagrams are used in one of 3 ways. Modeling the Vocabulary of a System. Modeling the Distribution of Responsibilities in a System. Modeling Nonsoftware Things. Common Modeling Techniques You'll use classes most commonly to model abstractions that are drawn from the problem you are trying to solve or from the technology you are using to implement a solution to that problem. Each 9
www.jntuworld.com
of these abstractions is a part of the vocabulary of your system, meaning that, together, they represent the things that are important to users and to implementers. Modeling Nonsoftware Things To model the vocabulary of a system, Identify those things that users or implementers use to describe the problem or solution. Use CRC cards and use case-based analysis to help find these abstractions. For each abstraction, identify a set of responsibilities. Make sure that each class is crisply defined and that there is a good balance of responsibilities among all your classes. Provide the attributes and operations that are needed to carry out these responsibilities for each class. Modeling the Distribution of Responsibilities in a System To model the distribution of responsibilities in a system, Identify a set of classes that work together closely to carry out some behavior. Identify a set of responsibilities for each of these classes. Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own. Consider the ways in which those classes collaborate with one another, and redistribute their responsibilities accordingly so that no class within a collaboration does too much or too little. Modeling Nonsoftware Things To model nonsoftware things, Stereotypes are discussed in Chapter 6. Model the thing you are abstracting as a class. If you want to distinguish these things from the UML's defined building blocks, create a new building block by using stereotypes to specify these new semantics and to give a distinctive visual cue. If the thing you are modeling is some kind of hardware that itself contains software, consider modeling it as a kind of node, as well, so that you can further expand on its structure. INTERACTION DIAGRAM:
Terms and Concepts An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose. A message is a specification of a communication 10
www.jntuworld.com
between objects that conveys information with the expectation that activity will ensue. A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. Interaction diagrams commonly contain Objects Links Messages Interaction diagrams are used in two ways: Modeling a Flow of Control Modeling Flows of Control by Time Ordering Common Modeling Techniques Modeling a Flow of Control
To model a flow of control, Set the context for the interaction, whether it is the system as a whole, a class, or an individual operation. Set the stage for the interaction by identifying which objects play a role; set their initial properties, including their attribute values, state, and role. If your model emphasizes the structural organization of these objects, identify the links that connect them, relevant to the paths of communication that take place in this interaction. Specify the nature of the links using the UML's standard stereotypes and constraints, as necessary. In time order, specify the messages that pass from object to object. As necessary, distinguish the different kinds of messages; include parameters and return values to convey the necessary detail of this interaction. Also to convey the necessary detail of this interaction, adorn each object at every moment in time with its state and role. Book issue:
11
www.jntuworld.com
Issue membership:
Fine collection:
12
www.jntuworld.com
Book status:
Book renewal:
13
www.jntuworld.com
Book return:
Modeling Flows of Control by Time Ordering To model a flow of control by time ordering, Set the context for the interaction, whether it is a system, subsystem, operation, or class, or one scenario of a use case or collaboration. Set the stage for the interaction by identifying which objects play a role in the interaction. Lay them out on the sequence diagram from left to right, placing the more important objects to the left and their neighboring objects to the right. Set the lifeline for each object. In most cases, objects will persist through the entire interaction. For those objects that are created and destroyed during the interaction, set their lifelines, as appropriate, and explicitly indicate their birth and death with 14
www.jntuworld.com
appropriately stereotyped messages. Starting with the message that initiates this interaction, lay out each subsequent message from top to bottom between the lifelines, showing each message's properties (such as its parameters), as necessary to explain the semantics of the interaction. If you need to visualize the nesting of messages or the points in time when actual computation is taking place, adorn each object's lifeline with its focus of control. If you need to specify time or space constraints, adorn each message with a timing mark and attach suitable time or space constraints. If you need to specify this flow of control more formally, attach pre- and postconditions to each message. Book issue:
Issue membership:
15
www.jntuworld.com
Fine Collection:
Book status:
16
www.jntuworld.com
Book renewal:
Book return:
17
www.jntuworld.com
A AC CT TI IV VI IT TY YD DI IA AG GR RA AM MS S
Terms and Concepts
An activity diagram shows the flow from activity to activity. An is an ongoing nonatomic execution within a state machine. Activities ultimately result in some action, which is made up of executable atomic computations that result in a change in state of the system or the return of a value. Actions encompass calling another operation, sending a signal, creating or destroying an object, or some pure computation, such as evaluating an expression. Graphically, an activity diagram is a collection of vertices and arcs.
Activity diagrams commonly contain Activity states and action states Transitions Objects Modeling a Workflow Modeling an Operation DESCRIPTION FOR THE ACTIVITY DIAGRAM: Swim lines: Member, 18
www.jntuworld.com
Librarian. Activities: 1. Find book on shelf. 2. Wait in queue. 3. Record return. 4. put book on shelf. 5. Record borrowing. 6. Prepare for next member Decisions: Is borrower
Is returner
Member
librarian
Description:
19
www.jntuworld.com
Member visits the library either to borrow a book or return a book. If member needs to borrow a book then he finds book on shelf after finding the book he wait in queue. If member needs to return book then also be waits in queue. Librarian checks the person in queue borrower or returner. If member is returner then librarian records return transaction and put book on the shelf. If member is borrower then the librarian issues the book to member and records borrowing transactions. If the members work is completed the librarian prepares for next member, until waiting queue is completed. When waiting queue is empty then it is final state of activity diagram.
Common Modeling Techniques

Modeling a Workflow To model a workflow, Establish a focus for the workflow. For nontrivial systems, it's impossible to show all interesting workflows in one diagram. Select the business objects that have the high-level responsibilities for parts of the overall workflow. These may be real things from the vocabulary of the system, or they may be more abstract. In either case, create a swimlane for each important business object. Identify the preconditions of the workflow's initial state and the postconditions of the workflow's final state. This is important in helping you model the boundaries of the workflow. Beginning at the workflow's initial state, specify the activities and actions that take place over time and render them in the activity diagram as either activity states or action states. For complicated actions, or for sets of actions that appear multiple times, collapse these into activity states, and provide a separate activity diagram that expands on each. Render the transitions that connect these activity and action states. Start with the sequential flows in the workflow first, next consider branching, and only then consider forking and joining. If there are important objects that are involved in the workflow, render them in the activity diagram, as well. Show their changing values and state as necessary to communicate the intent of the object flow.
Modeling an Operation To model an operation, Collect the abstractions that are involved in this operation. This includes the operation's parameters (including its return type, if any), the attributes of the enclosing class, and certain neighboring classes. Identify the preconditions at the operation's initial state and the postconditions at the operation's final state. Also identify any invariants of the enclosing class that must hold during the execution of the operation.
20
www.jntuworld.com
Beginning at the operation's initial state, specify the activities and actions that take place over time and render them in the activity diagram as either activity states or action states. Use branching as necessary to specify conditional paths and iteration. Only if this operation is owned by an active class, use forking and joining as necessary to specify parallel flows of control. STATE CHART DIAGRAM: Terms and Concepts A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events. A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.
In this state chart diagram contains: . States, transitions, and activities Modeling the lifetime of an object Creating well-structured algorithms
Common Modeling Techniques Modeling the Lifetime of an Object 21
www.jntuworld.com
To model the lifetime of an object, Set the context for the state machine, whether it is a class, a use case, or the system as a whole. 1. If the context is a class or a use case, collect the neighboring classes, including any parents of the class and any classes reachable by associations or Dependences. These neighbors are candidate targets for actions and are Candidates for including in guard conditions. 2. f the context is the system as a whole, narrow your focus to one behavior of the system. Theoretically, every object in the system may be a participant in a model of the system's lifetime, and except for the most trivial systems, a complete model would be intractable. Establish the initial and final states for the object. To guide the rest of your model, possibly state the pre- and post conditions of the initial and final states, respectively. Decide on the events to which this object may respond. If already specified, you'll find these in the object's interfaces; if not already specified, you'll have to consider which objects may interact with the object in your context, and then which events they may possibly dispatch. Starting from the initial state to the final state, lay out the top-level states the object may be in. Connect these states with transitions triggered by the appropriate events. Continue by adding actions to these transitions. Identify any entry or exit actions (especially if you find that the idiom they cover is used in the state machine). Expand these states as necessary by using substates. Check that all events mentioned in the state machine match events expected by the interface of the object. Similarly, check that all events expected by the interface of the object are handled by the state machine. Finally, look to places where you explicitly want to ignore events. Check that all actions mentioned in the state machine are sustained by the relationships, methods, and operations of the enclosing object. Trace through the state machine, either manually or by using tools, to check it against expected sequences of events and their responses. Be especially diligent in looking for unreachable states and states in which the machine may get stuck. After rearranging your state machine, check it against expected sequences again to ensure that you have not changed the object's semantics.
Modeling the Lifetime of An Object
22
www.jntuworld.com
DESCRIPTION OF THE STATE CHART DIAGRAM:
States: Not borrowable Borrowable Transitions: Reserves Return Last copy Borrow
23
www.jntuworld.com
Description: When member needs to borrow a book then librarian checks whether copies of book are available or not. There are two states borrowable and not borrowable states. The member returns the copy or book to the librarian then it goes under the state of borrowable. The member borrows a book which was not the last copy then also it goes to under the state of borrowable. The member borrows a book which was the last it goes under the not borrowable state. The member if reserves the book which was not there then it goes under the not borrowable state.
COMPONENTS DIAGRAM:
Terms and Concepts
A component diagram shows a set of components and their relationships. Graphically, a component diagram is a collection of vertices and arcs.
Component diagrams commonly contain Components Interfaces Dependency, generalization, association, and realization relationships
Components:
24
www.jntuworld.com
In this chapter
Modeling source code Modeling executable releases Modeling physical databases Modeling adaptable systems Forward and reverse engineering
Common Modeling Techniques

Modeling Source Code Modeling an Executable Release Modeling a Physical Database Modeling Adaptable Systems Forward and Reverse Engineering
1. To model source code With most contemporary object-oriented programming languages, you'll cut code using integrated development environments that store your source code in files. You can use component diagrams to model the configuration management of these files, which represent workproduct components. 2. To model executable releases A release is a relatively complete and consistent set of artifacts delivered to an internal or external user. In the context of components, a release focuses on the parts necessary to deliver a running system. When you model a release using component diagrams, you are visualizing, specifying, and documenting the decisions about the physical parts that constitute your software that is, its deployment components. 3. To model physical databases
25
www.jntuworld.com
Think of a physical database as the concrete realization of a schema, living in the world of bits. Schemas, in effect, offer an API to persistent information; the model of a physical database represents the storage of that information in the tables of a relational database or the pages of an Object-oriented database. You use component diagrams to represent these and other kinds of Physical databases. 4. To model adaptable systems Some systems are quite static; their components enter the scene, participate in an execution, and then depart. Other systems are more dynamic, involving mobile agents or components that migrate for purposes of load balancing and failure recovery. You use component diagrams in conjunction with some of the UML's diagrams for modeling behavior to represent these kinds of systems. Common modeling techniques: Modeling Source Code To model a source code, Either by forward or reverse engineering, identify the set of source code files of interest and model them as components stereotyped as files. For larger systems, use packages to show groups of source code files. Consider exposing a tagged value indicating such information as the version number of the source code file, its author and the date it was last changed. Use tools to manage the value of this tag. Model the compilation dependencies among these files using dependencies. Again, use tools to help generate and manage these dependencies. Modeling an Executable Release To model an executable release, Identify the set of components youd like to model. Typically, this will involve some or all the components that live on one node, or the distribution of these sets of components across all the nodes in the system. Consider the stereotype of each component in this step. For most systems, youll find a small number of different kinds of components (such as executables, libraries, tables, files and documents). You can use the UMLs extensibility mechanism to provide visual cues for these stereotypes. For each component in this set, consider its relationship to its neighbors. Most often, this will involve interfaces that are exported (realized) by certain 26
www.jntuworld.com
components and then imported (used) by others. If you want to expose the seams in your system, model these interfaces explicitly. If you want your model at a higher level of abstraction, elide these relationships by showing only dependencies among the components. Modeling a Physical Database To model a physical database, Identify the classes in your model that represent your logical database schema. Select a strategy for mapping these classes to tables. You will also want to consider the physical distribution of your databases. Your mapping strategy will be affected by the location in which you want your data to live on your deployed system. To visualize, specify, construct, and document your mapping, create a component diagram that contains components stereotyped as tables. Where possible, use tools to help you transform your logical design into a physical design. Modeling Adaptable Systems To model an adaptable system, Consider the physical distribution of the component that may migrate from node to node. You can specify the location of a component instance by marking it with a location tagged value, which you can then render in a component diagram (although, technically speaking, a diagram that contains only instances is an object diagram). If you want to model the actions that cause a component to migrate, create a corresponding interaction diagram that contains component instances. You can illustrate a change of location by drawing the same instance more than once, but different values for its location tagged value. Forward and Reverse Engineering To forward engineer a component diagram, For each component, identify the classes or collaborations that the component implements. Choose the target for each component. Your choice is basically between source code (a form that can be manipulated by development tools) or a binary library or executable (a form that can be dropped into a running system). Use tools to forward engineer your models. To reverse engineer a component diagram, Choose the target you want to reverse engineer. Source code can be reverse engineered to components and the classes. Binary libraries can be reverse engineered to uncover their interfaces. Executables can be reverse engineered the least. Using a tool, point to the code youd like to reverse engineer. Use your tool to generate a model or to modify an existing one that was previously forward engineered.
27
www.jntuworld.com
Using your tool, create a component diagram by querying the model. For example, you might start with one or more component, then expand the diagram by following relationships or neighboring components. Expose or hide the details of the contents of this component diagram as necessary to communicate your intent.
DEPLOYMENT DIAGRAMS: Terms and Concepts A deployment diagram is a diagram that shows the configuration of run time processing nodes and the components that live on them. Graphically, a deployment diagram is a collection of 28
www.jntuworld.com
vertices and arcs. Deployment diagrams commonly contain Nodes Dependency and association relationships
Nodes and Components
In this chapter Modeling an embedded system Modeling a client/server system Modeling a fully distributed system Forward and reverse engineering Common Modeling Techniques Modeling an Embedded System Modeling a Client/Server System Modeling a Fully Distributed System Forward and Reverse Engineering
29
www.jntuworld.com
1. To model embedded systems An embedded system is a software-intensive collection of hardware that interfaces with the physical world. Embedded systems involve software that controls devices such as motors, actuators, and displays and that, in turn, is controlled by external stimuli such as sensor input, movement, and temperature changes. You can use deployment diagrams to model the devices and processors that comprise an embedded system. 2. To model client/server systems A client/server system is a common architecture focused on making a clear separation of concerns between the system's user interface (which lives on the client) and the system's persistent data (which lives on the server). Client/ server systems are one end of the continuum of distributed systems and require you to make decisions about the network connectivity of clients to servers and about the physical distribution of your system's software components across the nodes. You can model the topology of such systems by using deployment diagrams. 3. To model fully distributed systems At the other end of the continuum of distributed systems are those that are widely, if not globally, distributed, typically encompassing multiple levels of servers. Such systems are often hosts to multiple versions of software components, some of which may even migrate from node to node. Crafting such systems requires you to make decisions that enable the continuous change in the system's topology. You can use deployment diagrams to visualize the system's current topology and distribution of components to reason about the impact of changes on that topology.
Common Modeling systems: Modeling an Embedded System To model an embedded system, Identify the devices and nodes that are unique to your system. Provide visual cues, especially for unusual devices, by using the UMLs extensibility mechanisms to define system specific stereotypes with appropriate icons. At the very least, youll want to distinguish processors (which contain
30
www.jntuworld.com
software components ) and devices (which, at that level of abstraction, dont directly contain software). Model the relationships among these processors and devices in a deployment diagram. Similarly, specify the relationship between the components in your systems deployment view. As necessary, expand on any intelligent devices by modeling their structure with a more detailed deployment diagram. Modeling a Client/Server System To model a client/server system, Identify the nodes that represent your systems client and processors. Highlight those devices that are germane to the behavior of your system. For example, youll want model special devices, such as credit card readers, and display devices other than monitors, because their placement in the systems hardware topology are likely to be architecturally significant. Provide visual cusses for these processors and devices via stereotyping. Model the topology of these modes in a deployment diagram. Similarly, specify the relationship between the components in your systems implementation view and the nodes in your systems deployment view. Modeling a Fully Distributed System: To model a fully distributed system, Identify the systems and processors as for simpler client /server systems. If you need to reason about the performance of the systems network or the impact of changes to the network, be sure to model this communication devices to the level of detail sufficient to make these assessments. Pay close attention to logical groupings of nodes, which you can specify by using packages. Model these devices and processors using deployment diagrams. Where possible, use tools that discover the topology of your system by walking your systems networks. If you need to focus on the dynamics of your system, introduce usecase diagrams to specify the kinds of behavior you are interested in, and expand on these usecases with interaction diagrams. Forward and Reverse Engineering To reverse engineer a deployment diagram, Choose the target that you want to reverse engineer. In some cases youll want to sweep across your entire network; in others, you can limit your search. Choose also the fidelity of your reverse engineering. In some cases, its sufficient to reverse engineer just to the level of all the systems processors; in others, youll want to reverse engineer the systems networking peripherals, as well. Use a tool that walks across your system, discovering its hardware topology. Record that topology in a deployment model. Along the way, you can use similar tools to discover the components that live on each node, which you can also record in a deployment model. Youll want 31
www.jntuworld.com
to use an intelligent search, even a basic personal computer can contain gigabytes of components, many of which may not be relevant to your system. Using your modeling tools, create a deployment diagram by querying the model. For example, you might start with visualizing the basic client/server topology, then expand on the diagram by populating certain nodes with components of interest that live on them. Expose or hide the details of the contents of this deployment diagram as necessary to communicate your intent.
32
www.jntuworld.com
AIRLINES RESERVATION PROCESS MANAGAMENT SYSTEM
33
www.jntuworld.com
Indexing the things..

Sr. No. Concept Page No.
Abstract
1.
Introduction
2.
Use Case Diagram
3.
Sequence Diagram
4.
Collaboration Diagram
5.
Class Diagram
6.
Activity Diagram State Chart Diagram Component Diagram Deployment Diagram
7.
8.
9.
34
www.jntuworld.com
Introduction:
An airline reservation system migration is one of the more complex, timeintensive and costly undertakings for airlines today. The challenge lies in finding the right balance between doing it expeditiously and successfully mitigating risks while handling the monumental logistical challenges of maintaining airline operations during the migration. A management system for a transportation carrier such as an airline is described that provides network-based management of customer data by allowing a user to form a list comprising multiple customers associated with different sets of criteria and to process customer data corresponding to customers associated with multiple lists defined by different criteria. In one embodiment, an airline management system allows a user to append additional customers to a list comprising previously selected customers without having to re-request the list with additional search criteria and re-select the previously selected customers. The airline management system also allows a user to simultaneously display multiple lists of customers that are defined by different criteria. As a result, airline personnel using the airline management system may more effectively and efficiently access and manage customer data required to provide airline services. In today's competitive market it's imperative that we offer our customers the same functionality and service online as we would in the traditional ticket sales process. The flight details: It includes the originating flight terminal and destination terminal, along with stops in between, number of seats booked/available seats between two destination etc. Customer Description: It includes customer code, name, address and phone number. This information may be used for keeping the records of customer for any emergency or for any other kind of information. Reservation Description: It includes customer code number, flight number, date of booking, date of traveling, (You may assume any other fild/relation, if needed). Experience counts: Keeping an airline operating during a migration involves moving millions of electronic passenger name records (PNRs) and electronic tickets, while continuing to process passengers and move airplanes. It also involves aligning those migrated PNRs with 35
www.jntuworld.com
Travel agencies and industry partners, such as alliance code share partners, and Coordinating countless details. Airlines today want partners with proven experience.EDS airline industry specialist have performed more than 50 successful passenger service system migrations in the last 20 years. As a result, the industry has confidence in EDS ability to effectively perform system migrations on schedule and correctly.. A number of critical factors continue to make a reliable and valued partner for such a vitally important undertaking: A well-defined, proprietary program management and migration methodology Architecture capabilities that can minimize risk and impact Largest pool of available resources with migration-specific experience and capabilities Knowledge of trends and issues shaping the airline industry Detailed knowledge of enterprise airline IT environments and their relationship to reservations Established relationships with industry airline reservations partners Substantial investment in building the future architecture and systems for airlines, in partnership with our airline partners
Airline reservations software key functions are:

Real time entry of flight reservations during telephone calls Maintenance of returning customer database functions Group reservation by date and time to dispatch fights Assign pilots and plans to dispatched flights Multi-leg flights with partial passenger list segment drop-off Create various reports for process management
36
www.jntuworld.com
USE CASE DIAGRAM

AIM: To draw the Use Case diagram for Airlines Reservation Process Management System. USE CASE: The Use case diagram is used to define the core elements and processes that makeup a system. The key elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case. This definition defines what a use case diagram is primarily made up ofactors and use cases.
Figure: Actors and Use Cases
Relationships: Association:
An association is a structural relationship that describes a set of links, a link being a connection among objects. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and role names. 01 employer
employee
Figure: Association 37
www.jntuworld.com
Generalization:
A generalization is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). In this way, the child shares the structure and the behavior of the parent. The graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent.
Figure: Generalization
Dependency:
A dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing. Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label.
Figure: Dependency
Realization:
A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship.
Figure: Realization
Aggregation:
A special form of association that specifies a whole-part relationship between the aggregate (the whole) and a component (the parts).
38
www.jntuworld.com
Figure: Aggregation
Composition:
A form of aggrepation with strong ownership and coincident lifetime of the parts by the whole; parts with nonfixed multiplicity may be created after the composite itself,but once created they live and die with it. Such parts can also be explicitly removed before the death of the composite.
Figure: Composition
Actor:
A coherent set of roles that users of use cases play when interacting with the use cases.
Figure: Reservation Agent
39
www.jntuworld.com
Example:
Figure: Use Case captures some actor-visible function
40
www.jntuworld.com
List of Use Cases:

Use case within an Airline Reservation system might include checking the flight, assigning a seat, purchase tickets, search for flights and canceling the flight. One common fragment of a user-perceivable action has been pulled out into a separate use case like use case subroutine. A Use Case Diagram is well suited to the task of describing all of the things that can be done with a database system, by all of the people who might use it (administrators, developers.) You should NOT use Use Case Diagrams to represent exception behavior.
List of Relationships:
Make Reservation and Arrange both depend on peruse Available Fights. Note that arrows go from the dependent use cases. Typically used when the same unit of functionality is part of more than one use case. The base use cases are, in a sense, incomplete without the included use case. A significant alternative course of action exists within the use like use case inheritance. Assign Seat and check both depend on check in Passenger. Note that the arrows go from the dependent use cases. Typically used when there is import, optional variations on the basic theme of the base use case the base use case is complete in and of itself.
List of Actors:
A Use Case captures some actor-visible function achieves some discrete (business-level) goal for that actor and may be read, write, or read-modify-write in nature. Actors for an Airline Reservation system is Airline administrators(fare/schedule setting),Travel Agent, Airline Reservations Agent, check-in agents at airport, Gate-agent at airports.
Description:
A use case diagram should capture the functional system components. It embosses the business processes within the system. While you traverse your system, you will learn significant system attributes that you model in the use case diagram. Because use case diagrams are simple in nature, they are free of technical jargon, use case diagrams are a great way to storyboard flows with users. Use case diagrams have another critical role. Use case diagrams define the system requirements being modeled and help write the scenarios later used in testing. Use Case Diagrams have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements. You should use Use Case Diagrams to represent the functionality of your system from a top-down perspective (that is, at a glance the system's functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to
41
www.jntuworld.com
elucidate interesting points in the system's behavior.)
Example:
Figure: Make Reservation and Arrange Tour both depend on peruse Available Filghts
42
www.jntuworld.com
List of Use Cases:

List of Actors:
Description:
A use case diagram should capture the functional system components. It embosses the business processes within the system. While you traverse your system, you will learn significant system attributes that you model in the use case diagram. Because use case diagrams are simple in nature, they are free of technical jargon, use case diagrams are a great way to storyboard flows with users. Use case diagrams have another critical role. Use case diagrams define the system requirements being modeled and help write the scenarios later used in testing. Use Case Diagrams have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements. You should use Use Case Diagrams to represent the functionality of your system from a top-down perspective (that is, at a glance the system's functionality is obvious, but 43
www.jntuworld.com
all descriptions are at a very high level. Further detail can later be added to the diagram to elucidate interesting points in the system's behavior.)
Example: Use case diagram of Airlines reservation management system
Figure: Use Case Diagram
44
www.jntuworld.com
List of Use Cases:

List of Actors:
Description:
A use case diagram should capture the functional system components. It embosses the business processes within the system. While you traverse your system, you will learn significant system attributes that you model in the use case diagram. Because use case diagrams are simple in nature, they are free of technical jargon, use case diagrams are a great way to storyboard flows with users. Use case diagrams have another critical role. Use case diagrams define the system requirements being modeled and help write the scenarios later used in testing. Use Case Diagrams have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements. You should use Use Case Diagrams to represent the functionality of your system from a top-down perspective (that is, at a glance the system's functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to 45
www.jntuworld.com
elucidate interesting points in the system's behavior.)
Sequence Diagram
AIM:
To draw the sequence diagram for Airlines Reservation Process Management System. The sequence diagram toolbar has five items of interest for creating the diagrams on this page.
Actor:
A coherent set of roles that users of use cases play when interacting with the use cases. An actor can start the message chain.
Figure: Actor
Object:
An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases.
Figure: Object
Link:
A semantic connection among objects; an instance of an association.
46
www.jntuworld.com
Figure: Link
Message:
A message link between objects. An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular contest to accomplish a specific purpose. The behavior of a society of objects of an individual operation may be specified with an interaction. An interaction involves a number of other elements, including messages, action sequences, and links. Graphically, a message is rendered as directed line, almost always including the name of its operation. display
Figure: Messages
A Self Message:
A self message can call to a method on the same object.
Figure: A self message
Association:
employee
Figure: Association
47
www.jntuworld.com
Example:
Figure: Planned Flight Object created
48
www.jntuworld.com
List of objects:
Our sequence diagram snapshot shows strictly generic classes and messages, which are completely unrelated to classes or operations in the class diagram. After you pick the classes, your sequence diagram should show the three objects and their activation bars in the pink and green stereotype colors. The easiest way to change the name of an object through the in-place editor. The PlannedFlight object linked to the Airline object. For Prepare Flight Plan to organize the long term plan to meet excepted demand and to make actual flights available for reservations. Flight scheduler is an actor, action is at the start of each month the Flight scheduler reviews the flights planned for 6 months from now, the scheduler adds a new day to an existing planned flight, the scheduler adds a new day to an existing planned flight and when the scheduler is satisfied with the plan, they prepare the actual flights for the month according to the plan. In Branching Action, the scheduler can add actual flights that are in addition to the planned flights.
List of Messages:
Our sequence diagram snapshot shows strictly generic classes and messages, which are completely unrelated to classes or operations in the class diagram. Make sure that you start that last message within the activation bar and not below. Otherwise, you will get a new, separate activation bar on the Object lifeline. You can convert generic objects to instances of existing or new classes. You can make the generic messages correspond to actual operations on these classes as well. To add a planned Flight a PlannedFlight object created. Attributes flightCode, departTime, arriveTime, departLocation, arriveLocation, aircraftType set to corresponding parameters. The PlannedFlight object linked to the Airline object.
List of Self Messages:

The Designer toolbar for sequence diagrams has a self-message button. After you create the self-message, choose ticketPurchased ( ) as its operation. For the remainder of this step, you need the message properties inspector. The "return" on the Link tab of the property inspector gives the name of the value to be returned. Together uses that name to generate code. In our case, the code that Together generates on demand is: booleanhasTicket = this.ticketPurchased (); the return property of a message specifies the name of a variable to be assigned the return value of the operation. You access it via the message's properties inspector.
49
www.jntuworld.com
Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the AirlinePD items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. When you create as sequence diagram from an operation, together automatically hyperlinks the operations to the sequence diagram. Look at your Flight in the Airline diagram. The Flight operation named make Reservation should be blue because it is hyperlinked to the collaboration diagram Flight.makeReservation (1). Sequence diagrams are tied intimately to code, but together keeps code and sequence diagrams in sync only on demand. You can use the in-place editor for messages to change the name of the operation but not its return type.
50
www.jntuworld.com
Example:
Figure: The Planned Flight object linked to the DayOfWeek object
51
www.jntuworld.com
List of objects:
Our sequence diagram snapshot shows strictly generic classes and messages, which are completely unrelated to classes or operations in the class diagram. After you pick the classes, your sequence diagram should show the three objects and their activation bars in the pink and green stereotype colors. The easiest way to change the name of an object through the in-place editor. The PlannedFlight object linked to the Airline object. For Prepare Flight Plan to organize the long term plan to meet excepted demand and to make actual flights available for reservations. Flight scheduler is an actor, to add a day to a planned flight. A PlannedFlight object linked to the DayOfWeek object. Link each Actual object to the Airline object.
List of Messages:
Our sequence diagram snapshot shows strictly generic classes and messages, which are completely unrelated to classes or operations in the class diagram. Make sure that you start that last message within the activation bar and not below. Otherwise, you will get a new, separate activation bar on the Object lifeline. You can convert generic objects to instances of existing or new classes. You can make the generic messages correspond to actual operations on these classes as well. To create the actual flights ready for the flight reservation from customers. For each planned Flight object calculate the days in the month that the flight will be flying. For each of the flying days, set the ActualFlight.flightDate to the day, set the attributes flight Code and etc. Link each Actual object to the Airline object.

The Designer toolbar for sequence diagrams has a self-message button. After you create the self-message, choose ticket Purchased ( ) as its operation. For the remainder of this step, you need the message properties inspector. The "return" on the Link tab of the property inspector gives the name of the value to be returned. Together uses that name to generate code. In our case, the code that Together generates on demand is: booleanhasTicket = this.ticketPurchased (); the return property of a message specifies the name of a variable to be assigned the return value of the operation. You access it via the message's properties inspector.
Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks 52
www.jntuworld.com
between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. When you create as sequence diagram from an operation, together automatically hyperlinks the operations to the sequence diagram. Example:
Figure: Make Flight Reservation
53
www.jntuworld.com
List of objects:
For Prepare Flight Plan to organize the long term plan to meet excepted demand and to make actual flights available for reservations. To make a reservation for a flight, Actors Customer, Reservation officer and action is the use case begins when a customer contacts the airline to make a reservation. The reservation officer asks for customers flight information, is departure and arrival location and departure day and the number of people flying. The reservation officer looks up the available flights on that day and informs the customer of flight availability. The customer selects one of the flights and makes a reservation, providing the names of the passengers that are making the trip. The customer information is recorded each time a customer makes a reservation. The airline does not reuse information about a customer made from prior bookings.
List of Messages:

Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we 54
www.jntuworld.com
checked off all the java.util items; we checked on all the Airline items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. Example:
Figure: Make Passenger Reservation
55
www.jntuworld.com
List of objects:
List of Messages:

Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for 56
www.jntuworld.com
Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. Example: Below is our sequence diagram. Its (default) name is Flight.makeReservation (1). Light rectangles are activation bars (corresponding to method calls). Dark rectangle corresponds to loop or conditional statements. The final five objects are lowered on the diagram to indicate that they are created as the reservation is made.
Figure: Generate a Sequence diagram from Flight.makeReservation (1) 57
www.jntuworld.com
List of objects:
List of Messages:

Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of 58
www.jntuworld.com
which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue.
Collaboration Diagram
AIM:
To draw the collaboration diagram for Airlines Reservation Process Management System. The sequence diagram toolbar has five items of interest for creating the diagrams on this page.
Actor:
A coherent set of roles that users of use cases play when interacting with the use cases. An actor can start the message chain.
Figure: Actor
Object:
An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases.
Figure: Object
59
www.jntuworld.com
Link:
A semantic connection among objects; an instance of an association.
Figure: Link
Message:
A message link between objects. An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular contest to accomplish a specific purpose. The behavior of a society of objects of an individual operation may be specified with an interaction. An interaction involves a number of other elements, including messages, action sequences, and links. Graphically, a message is rendered as directed line, almost always including the name of its operation. display
Figure: Messages
A Self Message:
A self message can call to a method on the same object.
Figure: A self message
Association:
employee
Figure: Association
60
www.jntuworld.com
Example:
Figure: Planned Flight Object created
61
www.jntuworld.com
List of objects:
Our sequence diagram snapshot shows strictly generic classes and messages, which are completely unrelated to classes or operations in the class diagram. After you pick the classes, your sequence diagram should show the three objects and their activation bars in the pink and green stereotype colors. The easiest way to change the name of an object through the in-place editor. The PlannedFlight object linked to the Airline object. For Prepare Flight Plan to organize the long term plan to meet excepted demand and to make actual flights available for reservations. Flight scheduler is an actor, action is at the start of each month the Flight scheduler reviews the flights planned for 6 months from now, the scheduler adds a new day to an existing planned flight, the scheduler adds a new day to an existing planned flight and when the scheduler is satisfied with the plan, they prepare the actual flights for the month according to the plan. In Branching Action, the scheduler can add actual flights that are in addition to the planned flights.
List of Messages:
Our sequence diagram snapshot shows strictly generic classes and messages, which are completely unrelated to classes or operations in the class diagram. Make sure that you start that last message within the activation bar and not below. Otherwise, you will get a new, separate activation bar on the Object lifeline. You can convert generic objects to instances of existing or new classes. You can make the generic messages correspond to actual operations on these classes as well. To add a planned Flight a PlannedFlight object created. Attributes flight Code, departTime, arriveTime, departLocation, arriveLocation, aircraftType set to corresponding parameters. The PlannedFlight object linked to the Airline object.

Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for 62
www.jntuworld.com
Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. When you create as sequence diagram from an operation, together automatically hyperlinks the operations to the sequence diagram. Look at your Flight in the Airline diagram. The Flight operation named make Reservation should be blue because it is hyperlinked to the collaboration diagram Flight.makeReservation (1). Sequence diagrams are tied intimately to code, but together keeps code and sequence diagrams in sync only on demand. You can use the in-place editor for messages to change the name of the operation but not its return type.
63
www.jntuworld.com
Example:
Figure: The Planned Flight object linked to the DayOfWeek object
64
www.jntuworld.com
List of objects:
Our sequence diagram snapshot shows strictly generic classes and messages, which are completely unrelated to classes or operations in the class diagram. After you pick the classes, your sequence diagram should show the three objects and their activation bars in the pink and green stereotype colors. The easiest way to change the name of an object through the in-place editor. The PlannedFlight object linked to the Airline object. For Prepare Flight Plan to organize the long term plan to meet excepted demand and to make actual flights available for reservations. Flight scheduler is an actor, to add a day to a planned flight. A PlannedFlight object linked to the DayOfWeek object. Link each Actual object to the Airline object.
List of Messages:

Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects 65
www.jntuworld.com
together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. When you create as sequence diagram from an operation, together automatically hyperlinks the operations to the sequence diagram. Example:
Figure: Make Flight Reservation
66
www.jntuworld.com
List of objects:
List of Messages:

Description:
67
www.jntuworld.com
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. Example:
Figure: Make Passenger Reservation
68
www.jntuworld.com
List of objects:
List of Messages:

69
www.jntuworld.com
Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue. Example:
Figure: Generate a Sequence diagram from Flight.makeReservation (1)
70
www.jntuworld.com
List of objects:
List of Messages:

Description:
The Generate Sequence Diagram command is on operation right-click menus in class diagrams. The snapshot to the right shows part of the right-click menu for Flight.makeReservation (). The Generate Sequence Diagram Expert gives a choice of which classes and implementation details to show. For our sequence diagram, we checked off all the java.util items; we checked on all the Airline items. Hyperlinks 71
www.jntuworld.com
between Together objects (such as diagrams and diagram elements) can tie objects together and shortcut project navigation. If an object on a diagram has a hyperlink to another, its name appears in blue.
Class Diagram
AIM:
To draw the class diagram for Airlines Reservation Process Management System.
Class:
A class diagram describes the static structure of the symbols in your new system. It is a graphic presentation of the static view that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships. Classes are arranged in hierarchies sharing common structure and behavior, and are associated with other classes. Class diagrams are particularly useful for business modeling, too. Business analysts can use class diagrams to model a business's current assets and resources, such as account ledgers, products, or geographic hierarchy. A class diagram illustrates the graphical view of the static structure of a system. It is a collection of classes, interfaces, and their relationships.
Figure: Classes A class diagram models the static structure of entities. Modeling the static structure of classes, the class diagram shows each class's internal structure along with the relationship that the class has to other classes. The UML representation of a class -- a class diagram -- is a rectangle containing three compartments stacked vertically.
Name:
Modeling the static structure of classes, the class diagram shows each class's internal structure along with the relationship that the class has to other classes. The top compartment shows the class's name.
72
www.jntuworld.com
Figure: Class Name
Attributes:
The middle compartment lists the class's attributes. The attribute section of a class (the middle compartment) lists each. Class's attributes on a separate line. In business class diagrams, the attribute types usually correspond to units that make sense to likely readers of the diagram (i.e., minutes, dollars, etc.). However, a class diagram that will be used to generate code needs classes whose attribute types are limited to the types provided by the programming language, or types included in the model that will also be implemented in the system.
Figure: A generic Class diagram with Attribute List
Operations:
The class's operations are documented in the third (lowest) compartment of the class diagram's rectangle. Like attributes, the operations of a class are displayed in a list format, with each operation on its own line. Operations are documented using the following notation: name (parameter list): type of value returned. When an operation has parameters, they are put inside the operation's parentheses; each parameter uses the format "parameter name : parameter type", which can include an optional indicator to show whether or not the parameter is input to, or output of, the operation. This optional indicator appears as an "[in]" or "[out]" .
73
www.jntuworld.com
Figure: A generic Class diagram with Operations
Example:
Figure: Class diagram of the airline Class Flight
Inheritance:
A very important concept in object-oriented design, inheritance, refers to the ability of one class (child class) to inherit the identical functionality of another class (super class), and then add new functionality of its own. (Imagine that I inherited my mother's general musical abilities, but in my family I'm the only one who plays electric guitar.) To model inheritance on a class diagram, a solid line is drawn from the child class (the class inheriting the behavior) with a closed arrowhead (or triangle) pointing to the super class. Consider types of bank accounts: Figure shows how both Checking Account and Savings Account classes inherit from the Bank Account class.
74
www.jntuworld.com
Figure: Inheritance is indicated by a solid line with a closed arrowhead pointing at the super class
Associations:
When you model a system, certain objects will be related to each other, and these relationships themselves need to be modeled for clarity. There are five types of associations. We will discuss bi-directional and uni-directional associations in this section and the remaining three association types in the Beyond the basics section. Please note that a detailed discussion of when to use each type of association is beyond the scope of this article. Instead, I will focus on the purpose of each association type and show how the association is drawn on a class diagram.
Bi-directional Association:
An association is a linkage between two classes. Associations are assumed to be bi-directional -- in other words, both classes are aware of their relationship and of the other class -- unless you qualify the association as some other type of association. A bidirectional association is indicated by a solid line between the two classes. At either end of the line, we place a role name and a multiplicity value.
75
www.jntuworld.com
Figure: A bi-directional association between a Flight class and a Plane class
Figure shows that the Flight is associated with a specific Plane, and the Flight class knows about this association. The Plane takes on the role of "assigned Plane" in this association because the role name next to the Plane class says so. The multiplicity value next to the Plane class of 0..1 means that when an instance of a Flight exists, it can either have one instance of a Plane associated with it or no Planes associated with it (i.e., maybe a plane has not yet been assigned). Figure 6 also shows that a Plane knows about its association with the Flight class. In this association, the Flight takes on the role of "assigned Flights".
Uni-directional association:
A uni-directional association shows that two classes are related, but only one class knows that the relationship exists. Figure shows an example of an Overdrawn Accounts report with a uni-directional association. A uni-directional association is drawn as a solid line with an open arrowhead pointing to the known class. Like standard associations, the uni-directional association includes a role name and a multiplicity value, but unlike the standard bi-directional association, the uni-directional association only contains the role name and multiplicity value for the known class. In our example in Figure, the OverdrawnAccountsReport knows about the Bank Account class, and the Bank Account class plays the role of "overdrawn Accounts."
76
www.jntuworld.com
Figure: A uni-directional association
Interfaces:
The fact is, classes are entities, but the term entities refer to more things then just classes. Entities also include things like data types and interfaces. A complete discussion of when and how to use data types and interfaces effectively in a system's class diagram is beyond the scope of this article. Drawing these entity types incorrectly will likely confuse readers of your class diagram, and the ensuing code will probably not meet requirements. A class and an interface differ: A class can have an actual instance of its type, whereas an interface must have at least one class to implement it.
Figure: Example of a class diagram in which the Professor and Student classes implement the Person interface
Relationships: Dependency:
Figure: Dependency
77
www.jntuworld.com
Generalization:
A generalization is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). In this way, the child shares the structure and the behavior of the parent. The graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent.
Figure: Generalization
Association:
employee
Figure: Association
78
www.jntuworld.com
Example:
Figure: Class diagram
79
www.jntuworld.com
Classes Identified:
A trip reservation consists of a sequence of flight reservations and each flight reservation refers to a specific flight, sometimes it may also have a substitute flight and also may refer to a seat. Each trip reservation is reserved on particular date and is distinguished by record locator for further tracking, as one may not purchase the ticket on the same day of reservation. A customer makes a trip reservation and may use a frequent flyer account. The customer will receive the ticket only after the purchase has been made. Multiple payments can be made with one purchase. An agent, who works for a travel agency or an airline, may reserve a trip.
Attributes Identified:
A class diagram that will be used to generate code needs classes whose attribute types are limited to the types provided by the programming language, or types included in the model that will also be implemented in the system. Sometimes it is useful to show on a class diagram that a particular attribute has a default value. (In our Flight class example, an airline flight will rarely be under 60 minutes, because the "flight time" -flight Duration --includes time for the plane to prepare for departure, back out and proceed to the runway, take off, land, etc.) The UML specification allows for the identification of default values in the attribute list section.
Relationships:
Relationships are mainly classified into association, aggregation, composition, and generalization. An association is a generic relationship between two classes and is shown as a thin line connecting two classes. Association has cardinality and role (optional) on the each end and a label (optional) for the relationship. Role is the named end of an association to indicate its purpose. Cardinality indicates the number of objects from each class that may participate in the relationship.
Description:
Typically, class diagrams are accompanied by comments or notes about each class, and/or its relationships, attributes, and operations. These notes can be placed directly on the class diagram, or, better yet, associated with each level (e.g. class, attribute, etc.). The class diagram is important because it shows the static structure of the entities in a system. Developers may think that class diagrams are created specially for them, but business analysts can also use class diagrams to model business systems. As we will see in other articles in this series on UML basics, other diagrams -- including the activity, sequence, and state chart diagrams. The case study records information about scheduled and planned flights for an airline and the flight reservations made by customers. The key elements in the system revolve around Planned and Actual Flights, and the reservations made by customers of actual flights. A Planned Flight represents a forward schedule of the expected flight pattern for a flight.
80
www.jntuworld.com
Example:
Figure: A class diagram of Airline Reservation
81
www.jntuworld.com
Classes Identified:
Figure is an analysis-level class diagram of the Airline Reservation system obtained from and adapted for UML, which will be used as the sample for analyzing and evaluating the methodologies. This class diagram illustrates classes, attributes, associations, multiplicities, generalization and specializations, and roles. A trip reservation consists of a sequence of flight reservations and each flight reservation refers to a specific flight, sometimes it may also have a substitute flight and also may refer to a seat. Each trip reservation is reserved on particular date and is distinguished by record locator for further tracking, as one may not purchase the ticket on the same day of reservation. A customer makes a trip reservation and may use a frequent flyer account. The customer will receive the ticket only after the purchase has been made. Multiple payments can be made with one purchase. An agent, who works for a travel agency or an airline, may reserve a trip.
Attributes Identified:
In business class diagrams, the attribute types usually correspond to units that make sense to likely readers of the diagram (i.e., minutes, dollars, etc.). However, a class diagram that will be used to generate code needs classes whose attribute types are limited to the types provided by the programming language, or types included in the model that will also be implemented in the system. Sometimes it is useful to show on a class diagram that a particular attribute has a default value. (In our Flight class example, an airline flight will rarely be under 60 minutes, because the "flight time" -- flight Duration -includes time for the plane to prepare for departure, back out and proceed to the runway, take off, land, etc.) The UML specification allows for the identification of default values in the attribute list section.
Relationships:
Relationships are mainly classified into association, aggregation, composition, and generalization. An association is a generic relationship between two classes and is shown as a thin line connecting two classes. Association has cardinality and role (optional) on the each end and a label (optional) for the relationship. Role is the named end of an association to indicate its purpose. Cardinality indicates the number of objects from each class that may participate in the relationship. Aggregation indicates whole-part relationship between two classes, shown as a line with a hollow diamond on the whole class end. Composition is a strong form of aggregation where the "whole" is completely responsible for its parts and each "part" class is only member of one "whole" class, shown as a line with a filled (black) diamond on the whole class end. Generalization is taxonomic relationship between a more generalized class and specialized classes. It represents super-class (generalized) and subclass (specialized) relationship between the classes, shown as a line with a hollow triangle on the generalized class end. The notation
82
www.jntuworld.com
to model these relationships shows the types of cardinalities, which indicate the multiplicities.
Normalization:
Normalization is the process of analyzing the relationships between various elements of the relational database and arranging the data efficiently in order to increase the consistency of the data. This is accomplished by applying various normal forms to the tables. First normal form states that each row-column combination in a table must contain a single value rather than a set of values. Second normal form states that a table should be in first normal form and all attributes of the table must depend on the entire primary key. Third normal form states that a table should be in second normal form and no attribute should transitively depend on the primary key. As tables satisfy higher normal forms, they are more consistent and store less redundant data. Tables of objectrelational databases may not be in the first normal form as they contain nested relations and abstract data types with set of values as opposed to single value for the row-column combination.
Methodology:
Methodology implements the transformation by using the UML extension mechanism (Stereotypes, tagged values and constraints) to define a new set of UML model elements that represent object-relational database concepts. These new model elements are then used to design the object-relational databases. Table 3 illustrates some of the extensions that are proposed for relational databases. Table 4 lists the extensions proposed for object-relational databases which can support collection types, methods etc. in methodology. This methodology proposes some rules as guidelines for object-relational database design. Application of the extension mechanisms on the object-relational database design model for the section in Figure that contains Trip Reservation, Agent, Travel Agent, Airline Agent, Travel Agency and Airline classes of the Airline Reservation system results in the stereotyped.
Description:
Typically, class diagrams are accompanied by comments or notes about each class, and/or its relationships, attributes, and operations. These notes can be placed directly on the class diagram, or, better yet, associated with each level (e.g. class, attribute, etc.). The class diagram is important because it shows the static structure of the entities in a system. Developers may think that class diagrams are created specially for them, but business analysts can also use class diagrams to model business systems. As we 83
www.jntuworld.com
will see in other articles in this series on UML basics, other diagrams -- including the activity, sequence, and state chart diagrams. The case study records information about scheduled and planned flights for an airline and the flight reservations made by customers. The key elements in the system revolve around Planned and Actual Flights, and the reservations made by customers of actual flights. A Planned Flight represents a forward schedule of the expected flight pattern for a flight.
Activity Diagram
AIM:
To draw the class diagram for Airlines Reservation Process Management System.
Activity Diagram:
An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation. Because an activity diagram is a special kind of statechart diagram, it uses some of the same modeling conventions.
Action states:
Action states represent the non interruptible actions of objects. You can draw an action state in SmartDraw using a rectangle with rounded corners.
Figure: Active state
Action Flow:
84
www.jntuworld.com
Action flow arrows illustrate the relationships among action states.
Figure: Action flow
Object Flow:
Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object.
Figure: Object flow
Initial State:
A filled circle followed by an arrow represents the initial action state.
Figure: Initial state
Final State:
An arrow pointing to a filled circle nested inside another circle represents the final action state. 85
www.jntuworld.com
Figure: Final state
Branching:
A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard expression. You can also label one of the paths "else.
Figure: Branching
Swimlanes:
Swimlanes group related activities into one column.
Figure: Swimlanes
Transition:
A transition is a directed relationship between a source state vertex and a target state vertex. It may be part of a compound transition, which takes the state machine from 86
www.jntuworld.com
one state configuration to another, representing the complete response of the state machine to a particular event instance. A solid arrow represents the path between different states of an object. Label the transition with the event that triggered it and the action that results from it. A relationship between two states, indicating that an object in the first state will enter the second state and perform certain specified actions when a specified event occurs, if specified conditions are satisfied. event / action Figure: Transition
Synchronization:
A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and joining.
Figure: Synchronization
Decision:
The decision button is the diamond on the diagram toolbar. To get the snapshot on the right, we set our Diagram Options to show rectilinear links. Make a decision node to compare the number of tickets to the capacity of the airplane. Make a transition from the join to the decision. Then make a transition from the decision to Create reservation and another transition to Refuse request.
87
www.jntuworld.com
Example:
88
www.jntuworld.com
Action States Identified:

Creating activities on activity diagrams is analogous to creating use cases on use case diagrams. Activity diagram transitions are analogous to use case diagram communications. The initial activity for the activity diagram will be receiving a reservation request. Create an activity named Receive request and put it inside the Flight Reservations swimlane. Link the start to the activity with a transition. The fork buttons on the diagram toolbar give a choice of horizontal forks or vertical forks. Before our airline can make a reservation, it checks to see if the flight has room. That is where the business rule comes in. Get capacity and Get #tickets can be performed in either order. But they both have to be completed before the remaining activities can begin. Be sure to look for the halo when you draw a transition to a fork. Forks are so slim that it is easy to miss a target fork and land on a swimlane instead. If you try to end a transition on a diagram entity that is not a valid target. Make a decision node to compare the number of tickets to the capacity of the airplane. Make a transition from the join to the decision. Then make a transition from the decision to Create reservation and another transition to Refuse request.
Description:
Activity diagrams are fancy flow charts. Use them to spell out the details of potentially complicated or arcane business rules. Together makes no direct connection between code and activity diagrams. Activity diagrams are useful for sketching out the flow of activities. They need not spell out exact messages, message sequencing, or control structures. When Together cannot determine where you want a transition to end, it displays a "Choose Destination" dialog box giving you a choice of possible endpoints. An activity diagram has mostly actions as states. It represents some king of flow diagram and has therefore some visual constructs for handling conditions, like a diamond shaped box for conditionals and plates for merging control flow.
89
www.jntuworld.com
State Chart Diagram

AIM:
To draw the State Chart diagram for Airlines Reservation Process Management System.
State Chart:
A state chart diagram can be used to describe the behavior of an object. It is a graph of states as nodes and state transitions as directed edges. A state is displayed as rectangle, an edge as arrow. A node is labeled with the state name inside the bounds. It may also be divided in two areas where the first contains the name and the other an activity in process while in this state, the start state, is a little empty circle. An end state is a double bordered circle. State diagrams can be nested hierarchically, indicating sub state machines. Entering a sub state machine begins at starting state of the sub machine. Reaching an end state means leaving a sub state.
Initial state:
A condition at the beginning of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.
Figure: Initial state
Final state:
A condition at the end of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. Figure: Final state
State:
A condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.
Figure: State Chart Diagram
States:
States represent situations during the life of an object. You can easily illustrate a state in Smart Draw by using a rectangle with rounded corners.
90
www.jntuworld.com
Figure: States
History Indicator:
When a transition to a super state occurs, a History Indicator shows control resumes at the state within the super state that was current when the super state was interrupted.
Figure: History indicator
Transition:
A relationship between two states, indicating that an object in the first state will enter the second state and perform certain specified actions when a specified event occurs, if specified conditions are satisfied. event / action Figure: Transition
91
www.jntuworld.com
Example:
Figure: State Chart Diagram
States Identified:
Dynamic behavior is described in terms of a set of potentially nested states, the transitions between these states, the events (calls of the class's operations) that trigger these transitions, and actions that are performed, both while transitioning between states, and on entry to, whilst within, and on exit from a state. A transition may be to a superstate, in which case the flow of control begins at the initial state symbol nested within the superstate. A superstate may contain more than one set of nested states and transitions, each set separated from all other sets, and each set having its own initial state and final state(s) symbols. These sets are considered to run concurrently.
Composite States Identified:

A transition from a superstate is considered to come from any or all of the states directly within it. A superstate may have superstates nested within it, each of which may 92
www.jntuworld.com
in turn contain states and transitions, and possibly other superstates. As such, it is possible to create a hierarchy of states within an SCD by nesting states inside superstates, and then nesting superstates inside other superstates. At each level of state nesting, there may be any number of superstates. For example, an SCD may contain some states and two superstates, each with states nested inside it.
Description:
A state diagram is a diagram used in the field of computer science, representing the behavior of a system, which is composed of a finite number of states. There are many forms of state diagrams, which differ slightly and have different semantics. State diagrams are used to describe the behavior of a system. State diagrams can describe the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system. State diagram can be used to graphically represent finite state machines. Classes that are believed to have a distinct lifestyle, that is, which are believed to exhibit or provide different external behavior in different circumstances, may be augmented by a State Chart Diagram (SCD).An SCD depicts a finite-state-machine that describes how the class responds to different external stimuli. These stimuli are the receipt of messages by instances of the class, in the form of calls of the class's operations. is the dot-concatenation of the SCD number (the class name) and the state number.
Example:
Figure: State Chart Diagram 93
www.jntuworld.com
States Identified:
Dynamic behavior is described in terms of a set of potentially nested states, the transitions between these states, the events (calls of the class's operations) that trigger these transitions, and actions that are performed, both while transitioning between states, and on entry to, whilst within, and on exit from a state. A transition may be to a superstate, in which case the flow of control begins at the initial state symbol nested within the superstate. A superstate may contain more than one set of nested states and transitions, each set separated from all other sets, and each set having its own initial state and final state(s) symbols. These sets are considered to run concurrently.
Composite States Identified:

A transition from a superstate is considered to come from any or all of the states directly within it. A superstate may have superstates nested within it, each of which may in turn contain states and transitions, and possibly other superstates. As such, it is possible to create a hierarchy of states within an SCD by nesting states inside superstates, and then nesting superstates inside other superstates. At each level of state nesting, there may be any number of superstates. For example, an SCD may contain some states and two superstates, each with states nested inside it.
Description:
A state diagram is a diagram used in the field of computer science, representing the behavior of a system, which is composed of a finite number of states. There are many forms of state diagrams, which differ slightly and have different semantics. State diagrams are used to describe the behavior of a system. State diagrams can describe the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system. State diagram can be used to graphically represent finite state machines. Classes that are believed to have a distinct lifestyle, that is, which are believed to exhibit or provide different external behavior in different circumstances, may be augmented by a State Chart Diagram (SCD).An SCD depicts a finite-state-machine that describes how the class responds to different external stimuli. These stimuli are the receipt of messages by instances of the class, in the form of calls of the class's operations. is the dot-concatenation of the SCD number (the class name) and the state number.
Component Diagram
AIM:
To draw the Component diagram for Airlines Reservation Process Management System.
Component Diagram:
They show the dependencies of implementation components. A component diagram is a graph of components connected through edges representing simple dependency, containment and implementation relationships. A component diagram describes the organization of the physical components in a system.
94
www.jntuworld.com
Basic Component Diagram Symbols and Notations Component:

A component is a physical building block of the system. It is represented as a rectangle with tabs.
Figure: Component
Interface:
An interface describes a group of operations used or created by components.
Figure: Interface
Dependencies:
Draw dependencies among components using dashed arrows.
Figure: Component with dependency
Package Diagram:
Package diagrams organize the elements of a system into related groups to minimize dependencies among them.
95
www.jntuworld.com
Basic Package Diagram Symbols and Notations:
Packages:
Use a tabbed folder to illustrate packages. Write the name of the package on the tab or inside the folder. Similar to classes, you can also list the attributes of a package.
Figure: Packages
Visibility:
Visibility markers signify who can access the information contained within a package. Private visibility means that the attribute or the operation is not accessible to anything outside the package. Public visibility allows an attribute or an operation to be viewed by other packages. Protected visibility makes an attribute or operation visible to packages that inherit it only.
Figure: Visibility
Dependency:
Dependency defines a relationship in which changes to one package will affect another package. Importing is a type of dependency that grants one package access to the contents of another package.
96
www.jntuworld.com
Figure: Package with dependency
Figure: Dependency
Association:
employee
Figure: Association
Realization:
A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship.
97
www.jntuworld.com
Figure: Realization
Example:
98
www.jntuworld.com
Example:
Example:
99
www.jntuworld.com
Packages Identified:
As the Airlines collaborates directly with only two classes (Applet and Graphics), and these two classes are but a small part of the larger library of predefined Java classes. To manage this large collection, Java organizes its interfaces and classes in a number of different packages. The root package in the Java environment is named, not surprisingly, java.Nested inside this package are several other packages, which contain other packages, interfaces, and classes. Object lives in the package lang, so its full path name is java.lang.Object. Similarly, Panel, Container, and Component live in awt; the class Applet lives in the package applet.
Components Identified:
Each of the icons in the figure represents a UML element in the implementation view of the system. The component called Airlines.java represents the source code for the logical class Airlines, so it is a file that may be manipulated by development environments and configuration management Airlines.class by a Java compiler, making it suitable for execution by a computers Java virtual machine. The canonical icon for a component is a rectangle with two tabs. The binary applet Airlines.class is a variation of this basic symbol, with its lines made thicker, indication that it is an executable component.
Description:
A Component is a modular part of a system, whose behavior is defined by its provided and required interfaces; the internal workings of the Component should be invisible and its usage environment-independent. Source code files, DLLs, Java beans and other artifacts defining the system can be manifested in Components. A Component can be composed of multiple Classes, or Components pieced together. As smaller Components come together to create bigger Components, the eventual system can be modeled, building-block style, in Component diagrams. By building the system in discrete Components, localization of data and behavior enables decreased dependency between Classes and Objects, providing a more robust and maintainable design. A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type whose conformance is defined by these provided and required interfaces
100
www.jntuworld.com
Deployment Diagram
AIM:
To draw the Deployment diagram for Airlines Reservation Process Management System.
Deployment Diagram:
Deployment diagrams depict the physical resources in a system including nodes, components, and connections. Basic Deployment Diagram Symbols and Notations
Node:
A node is a physical resource that executes code components.
Figure: Node
Association:
Association refers to a physical connection between nodes, such as Ethernet.
Figure: Association between the nodes
Components and Nodes:

Place components inside the node that deploys them.
101
www.jntuworld.com
Figure: Components and nodes
Figure: Dependency
Association:
employee
Figure: Association
102
www.jntuworld.com
Example:
Figure: Deployment diagram for Airlines Reservation
Example:
Figure: Deployment diagram
103
www.jntuworld.com
Nodes Identified:
A Node is a physical piece of equipment on which the system is deployed, such as a workgroup server or workstation. A Node usually hosts components and other executable pieces of code, which again can be connected to particular processes or execution spaces. Typical Nodes are client workstations, application servers, mainframes, routers and terminal servers. Nodes are used in Deployment diagrams to model the deployment of a system, and to illustrate the physical allocation of implemented artifacts. They are also used in web modeling, from dedicated web modeling pages in the Enterprise Architect UML Toolbox. In the metamodel, a Node is a subclass of Class. It is associated with a Deployment of an Artifact. It is also associated with a set of Elements that are deployed on it. This is a derived association in that these PackageableElements are involved in a Manifestation of an Artifact that is deployed on the Node. Nodes may have an internal structure defined in terms of parts and connectors associated with them for advanced modeling applications.
Description:
A Deployment Specification (spec) specifies parameters guiding deployment of an artifact, as is necessary with most hardware and software technologies. A specification lists those properties that must be defined for deployment to occur, as represented in a Deployment diagram. An instance of this specification specifies the values for the parameters; a single specification can be instantiated for multiple artifacts. These specifications can be extended by certain component profiles. Examples of standard Tagged Values that a profile might add to a Deployment Specification are concurrency Mode with Tagged Values {thread, process, none} or transactionMode with Tagged Values {transaction, nestedTransaction, none}. A deployment specification specifies a set of properties that determine execution parameters of a component artifact that is deployed on a node. A deployment specification can be aimed at a specific type of container. An artifact that reifies or implements deployment specification properties is a deployment descriptor.
104

OOAD Lab Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOAD Lab Manual

Uploaded by

Copyright:

Available Formats

www.jntuworld.

8) RESERVE BOOK:Primary actor: Member Secondary actor: Library staff 6

Bookissue() Bookstatus() Bookreserved() 8

Terms and Concepts

Common Modeling Techniques

Common Modeling Techniques Modeling the Lifetime of an Object 21

DESCRIPTION OF THE STATE CHART DIAGRAM:

Common Modeling Techniques

Nodes and Components

AIRLINES RESERVATION PROCESS MANAGAMENT SYSTEM

Indexing the things..

Use Case Diagram

Activity Diagram State Chart Diagram Component Diagram Deployment Diagram

Airline reservations software key functions are:

USE CASE DIAGRAM

Figure: Actors and Use Cases

Figure: Reservation Agent

Figure: Use Case captures some actor-visible function

List of Use Cases:

elucidate interesting points in the system's behavior.)

List of Use Cases:

Example: Use case diagram of Airlines reservation management system

Figure: Use Case Diagram

List of Use Cases:

elucidate interesting points in the system's behavior.)

Figure: A self message

Figure: Planned Flight Object created

List of Self Messages:

Figure: The Planned Flight object linked to the DayOfWeek object

List of Self Messages:

Figure: Make Flight Reservation

List of Self Messages:

Figure: Make Passenger Reservation

List of Self Messages:

Figure: Generate a Sequence diagram from Flight.makeReservation (1) 57

List of Self Messages:

Figure: A self message

Figure: Planned Flight Object created

List of Self Messages:

Figure: The Planned Flight object linked to the DayOfWeek object

List of Self Messages:

Figure: Make Flight Reservation

List of Self Messages:

Figure: Make Passenger Reservation

List of Self Messages:

Figure: Generate a Sequence diagram from Flight.makeReservation (1)

List of Self Messages:

Figure: Class Name

Figure: A generic Class diagram with Attribute List

Figure: A generic Class diagram with Operations

Figure: Class diagram of the airline Class Flight

Figure: A bi-directional association between a Flight class and a Plane class

Figure: A uni-directional association

Figure: Class diagram

Figure: A class diagram of Airline Reservation

Figure: Active state

Action flow arrows illustrate the relationships among action states.

Figure: Action flow

Figure: Object flow

Figure: Initial state

Figure: Final state

Action States Identified:

State Chart Diagram