OOAManual Lab

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.
IIM
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
AIIM
MSS O
OF
FU
UM
MLL
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
NIIF
FIIE
ED
DL
LIIB
BR
RA
AR
RY
Y SSY
YSST
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
USSE
EC
CA
ASSE
ED
DIIA
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
USSE
EC
CA
ASSE
ESS
D
DO
OC
CU
UM
MEEN
NTTA
ATTIIO
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
CLLA
ASSSS D
DIIA
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
Copy
Status
Fine
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()
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
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
TIIV
VIIT
TY
YD
DIIA
AG
GR
RA
AM
MSS
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.

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

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

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.
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
Modeling an Embedded System
Modeling a Client/Server System
Modeling a Fully Distributed System
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.
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
7.
State Chart Diagram
8.
Component Diagram
9.
Deployment Diagram
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:
at airports.
Description:
43
www.jntuworld.com
Example: Use case diagram of Airlines reservation management system
Figure: Use Case Diagram
44
www.jntuworld.com
List of Use Cases:

List of Actors:
at airports.
Description:
45
www.jntuworld.com
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:
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:
01
employer
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:
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:
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

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:
Description:
checked off all the java.util items; we checked on all the Airline items. Hyperlinks
52
www.jntuworld.com
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:
54
www.jntuworld.com
another, its name appears in blue.
Example:
Figure: Make Passenger Reservation
55
www.jntuworld.com
List of objects:
List of Messages:

Description:
56
www.jntuworld.com

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:
58
www.jntuworld.com
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:
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:
01
employer
employee
Figure: Association
60
www.jntuworld.com
Example:
Figure: Planned Flight Object created
61
www.jntuworld.com
List of objects:
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:
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:
62
www.jntuworld.com

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:
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:
65
www.jntuworld.com

Example:
Figure: Make Flight Reservation
66
www.jntuworld.com
List of objects:
List of Messages:

Description:
67
www.jntuworld.com

Example:
Figure: Make Passenger Reservation
68
www.jntuworld.com
List of objects:
List of Messages:

69
www.jntuworld.com
Description:
Example:
Figure: Generate a Sequence diagram from Flight.makeReservation (1)
70
www.jntuworld.com
List of objects:
List of Messages:

Description:
71
www.jntuworld.com
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:
01
employer
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:
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:

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
Relationships:
Dependency:
Figure: Dependency
Association:
01
employer
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
Relationships:
Dependency:
Figure: Dependency
Association:
01
employer
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

OOAManual Lab

Uploaded by

Copyright:

Available Formats

You might also like

OOAManual Lab

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

OOAManual Lab

Uploaded by

Copyright:

Available Formats

www.jntuworld.

Through modeling, we achieve four aims.

Application areas of UML

A use case diagram commonly contain

Primary Actor: Member

If member is not a student or staff then librarian rejects his

8) RESERVE BOOK:Primary actor: Member

A member can reserve a book or magazine that is not currently

Terms and Concepts

Terms and Concepts

To model a flow of control,

Modeling Flows of Control by Time Ordering

appropriately stereotyped messages.

Activity diagrams commonly contain

Member visits the library either to borrow a book or return a

Common Modeling Techniques

In this state chart diagram contains:

Common Modeling Techniques

To model the lifetime of an object,

DESCRIPTION OF THE STATE CHART DIAGRAM:

Component diagrams commonly contain

Modeling source code

Common Modeling Techniques

1. To model source code

Modeling Adaptable Systems

vertices and arcs.

Nodes and Components

1. To model embedded systems

Common Modeling systems:

software components ) and devices (which, at that level of abstraction, dont

to use an intelligent search, even a basic personal computer can contain

AIRLINES RESERVATION PROCESS MANAGAMENT

Indexing the things..

Use Case Diagram

State Chart Diagram

A well-defined, proprietary program management and migration methodology

Airline reservations software key functions are:

Real time entry of flight reservations during telephone calls

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.)

Figure: Make Reservation and Arrange Tour both depend on

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