uml lab manual
DESCRIPTION
UML Lab ManualTRANSCRIPT
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
SNo.
NAME OF THE EXPERIMENT
PAGE NO
REMARKS
1 UML INTRODUCTION
2 A POINT-OF-SALES SYSTEM
3 ONLINE BOOKSHOP
4sAN AUCTION APPLICATION
5 A MULTI THREADED AIRPORT SIMULATION
6
A SIMULATED COMPANY
UNIFIED MODELING LANGUAGE Page | 1
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
UML INTRODUCTION
STUDY OF UML AIM: General study of UML
DESCRIPTION: The heart of object-oriented problem solving is the construction of a model. The
model abstracts the essential details of the underlying problem from its usually
UNIFIED MODELING LANGUAGE Page | 2
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
complicated real world. Several modeling tools are wrapped under the heading of the
UML, which stands for Unified Modeling Language. The purpose of this course is to
present important highlights of the UML.
CLASS A class is a blueprint or prototype from which objects are created. This section
defines a class that models the state and behavior of a real-world object. It intentionally
focuses on the basics, showing how even simple classes can cleanly model state and
behavior. For example, the class Dog would consist of traits shared by all dogs, such as
breed and fur color (characteristics), and the ability to bark and sit (behaviors).
OBJECT An object is a software bundle of related state and behavior. Software objects are
often used to model the real-world objects that you find in everyday life. This lesson
explains how state and behavior are represented within an object, introduces the concept
of data encapsulation, and explains the benefits of designing your software in this
manner. A pattern(exemplar) of a class. The class Dog defines all
possible dogs by listing the characteristics and behaviors they can have; the object Lassie
is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie
has brown-and-white fur.
OBJECT ORIENTATION CONCEPTS: Object-Orientation goes beyond just modeling attributes and behavior. It considers
the other aspects of objects as well. Object-oriented programming (OOP) is a
programming paradigm that uses "objects" – data structures consisting of data fields and
methods together with their interactions – to design applications and computer programs.
Programming techniques may include features such as data abstraction, encapsulation,
modularity, polymorphism, and inheritance. These aspects are called abstraction,
Inheritance, polymorphism and encapsulation.
UNIFIED MODELING LANGUAGE Page | 3
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
ABSTRACTION: Abstraction is simplifying complex reality by modeling classes appropriate to the
problem, and working at the most appropriate level of inheritance for a given aspect of
the problem.
For example, Lassie the Dog may be treated as a Dog much of the time, a Collie
when necessary to access Collie-specific attributes or behaviors, and as an Animal
(perhaps the parent class of Dog) when counting Timmy's pets. Abstraction is also
achieved through Composition. For example, a class
ENCAPSULATION: Encapsulation conceals the functional details of a class from objects that send
messages to it.
For example, the Dog class has a bark () method. The code for the bark() method defines
exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and
volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks.
Encapsulation is achieved by specifying which classes may use the members of an object.
The result is that each object exposes to any class a certain interface — those members
accessible to that class.
The reason for encapsulation is to prevent clients of an interface from depending on
those parts of the implementation that are likely to change in the future, thereby allowing
those changes to be made more easily, that is, without changes to clients. For example, an
interface can ensure that puppies can only be added to an object of the class Dog by code
in that class. Members are often specified as public, protected or private, determining
whether they are available to all classes, sub-classes or only the defining class. Some
languages go further: Java uses the default access modifier to restrict access also to
classes in the same package, C# and VB.NET reserve some members to classes in the
same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel and C++
allow one to specify which classes may access any member.
POLYMORPHISM:
UNIFIED MODELING LANGUAGE Page | 4
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Polymorphism allows the programmer to treat derived class members just
like their parent class's members. More precisely, Polymorphism in object-oriented
programming is the ability of objects belonging to different data types to respond to
calls of methods of the same name, each one according to an appropriate type-specific
behavior. One method, or an operator such as +, -, or *, can be abstractly applied in many
different situations. If a Dog is commanded to speak(), this may elicit a bark(). However,
if a Pig is commanded to speak(), this may elicit an oink(). Each subclass overrides the
speak() method inherited from the parent class Animal.
INHERITANCE: Subclasses are more specialized versions of a class, which inherit attributes and
behaviors from their parent classes, and can introduce their own.
For example, the class Dog might have sub-classes called Collie, Chihuahua,
and Golden Retriever. In this case, Lassie would be an instance of the Collie subclass.
Suppose the Dog class defines a method called bark() and a property called fur Color.
Each of its sub-classes (Collie, Chihuahua, and Golden Retriever) will inherit these
members, meaning that the programmer only needs to write the code for them once.
Each subclass can alter its inherited traits. For example, the Collie subclass might
specify that the default four-Color for a collie is brown-and-white. The Chihuahua
subclass might specify that the bark() method produces a high pitch by default.
Subclasses can also add new members. The Chihuahua subclass could add a method
called tremble (). So an individual Chihuahua instance would use a high-pitched bark ()
from the Chihuahua subclass, which in turn inherited the usual bark () from Dog. The
Chihuahua object would also have the tremble () method, but Lassie would not, because
she is a Collie, not a Chihuahua. In fact, inheritance is an "a... is a" relationship between
classes, while instantiation is an "is a" relationship between an object and a class: a
Collie is a Dog ("a... is a"), but Lassie is a Collie ("is a"). Thus, the object named Lassie
has the methods from both classes Collie and Dog.
Multiple inheritances are inheritance from more than one ancestor class, neither
of these ancestors being an ancestor of the other. For example, independent classes could
define Dogs and Cats, and a Chimera object could be created from these two which
UNIFIED MODELING LANGUAGE Page | 5
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
inherits all the (multiple) behavior of cats and dogs. This is not always supported, as it
can be hard to implement
At the center of the UML are its nine kinds of modeling diagrams, which we describe here.
● Use case diagrams ● Class diagrams ● Object diagrams ● Sequence diagrams ● Collaboration diagrams ● State chart diagrams ● Activity diagrams ● Component diagrams ● Deployment diagrams
Why is UML important?Let's look at this question from the point of view of the construction trade.
Architects design buildings. Builders use the designs to create buildings. The more
complicated the building, the more critical the communication between architect and
builder. Blueprints are the standard graphical language that both architects and builders
must learn as part of their trade.
Writing software is not unlike constructing a building. The more complicated
the underlying system, the more critical the communication among everyone involved
in creating and deploying the software. In the past decade, the UML has emerged as the
software blueprint language for analysts, designers, and programmers alike. It is now
part of the software trade. The UML gives everyone from business analyst to designer to
programmer a common vocabulary to talk about software design.
The UML is applicable to object-oriented problem solving. Anyone interested
in learning UML must be familiar with the underlying tenet of object-oriented problem
solving -- it all begins with the construction of a model. A model is an abstraction of the
underlying problem. The domain is the actual world from which the problem comes.
Models consist of objects that interact by sending each other messages. Think of an
object as "alive." Objects have things they know (attributes) and things they can do
(behaviors or operations). The values of an object's attributes determine its state.
UNIFIED MODELING LANGUAGE Page | 6
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Classes are the "blueprints" for objects. A class wraps attributes (data) and
behaviors (methods or functions) into a single distinct entity. Objects are instances of
classes.
Use case diagrams:
Use case diagrams describe what a system does from the standpoint of an
external observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of what
happens when someone interacts with the system. Here is a scenario for a medical clinic.
"A patient calls the clinic to make an appointment for a yearly checkup. The
receptionist finds the nearest empty time slot in the appointment book and
schedules the appointment for that time slot. "
A use case is a summary of scenarios for a single task or goal. An actor is who
or what initiates the events involved in that task. Actors are simply roles that people or
objects play. The picture below is a Make Appointment use case for the medical clinic.
The actor is a Patient. The connection between actor and use case is a communication
association (or communication for short).
Actors are stick figures. Use cases are ovals. Communications are lines that link
actors to use cases.
UNIFIED MODELING LANGUAGE Page | 7
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
A use case diagram is a collection of actors, use cases, and their communications.
We've put Make Appointment as part of a diagram with four actors and four use cases.
Notice that a single use case can have multiple actors.
Use case diagrams are helpful in three areas.
● Determining features (requirements). New use cases often generate new
requirements as the system is analyzed and the design takes shape.
● Communicating with clients. Their notational simplicity makes use case
diagrams a good way for developers to communicate with clients.
● Generating test cases. The collection of scenarios for a use case may suggest a
suite of test cases for those scenarios.
Class diagrams:
A Class diagram gives an overview of a system by showing its classes and the
relationships among them. Class diagrams are static -- they display what interacts but not
what happens when they do interact.
The class diagrams below models a customer order from a retail catalog. The
central class is the Order. Associated with it is the Customer making the purchase and
the Payment? A Payment is one of three kinds: Cash, Check, or Credit. The order
contains Order Details (line items), each with its associated Item.
UNIFIED MODELING LANGUAGE Page | 8
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
UML class notation is a rectangle divided into three parts: class name, attributes, and
operations. Names of abstract classes, such as Payment, are in italics. Relationships
between classes are the connecting links.
Our class diagram has three kinds of relationships.
● Association -- a relationship between instances of the two classes. There is an
association between two classes if an instance of one class must know about the
other in order to
● Perform its work. In a diagram, an association is a link connecting two classes.
● Aggregation -- an association in which one class belongs to a collection. An
aggregation has a diamond end pointing to the part containing the whole. In our
diagram, Order has a collection of Order Details.
● Generalization -- an inheritance link indicating one class is a super class of the
other. A generalization has a triangle pointing to the super class. Payment is a
super class of Cash, Check, and Credit.
An association has two ends. An end may have a role name to clarify the nature of
the association. For example, an Order Detail is a line item of each Order.
A navigability arrow on an association shows which direction the association can be
traversed or queried. An Order Detail can be queried about its Item, but not the other
UNIFIED MODELING LANGUAGE Page | 9
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
way around. The arrow also lets you know who "owns" the association's implementation;
in this case, Order Detail has an Item. Associations with no navigability arrows are bi-
directional. The multiplicity of an association end is the number of possible instances
of the class associated with a single instance of the other end. Multiplicities are single
numbers or ranges of numbers. In our example, there can be only one Customer for
each Order, but a Customer can have any number of Orders. This table gives the most
common multiplicities.
Multiplicities Meaning
0..1 zero or one instance. The notation n . . m indicates n to m instances.
0..* or * no limit on the number of instances (including none).
1 exactly one instance
1..* at least one instance
Every class diagram has classes, associations, and multiplicities. Navigability and roles
are optional items placed in a diagram to provide clarity.
Packages and object diagrams
To simplify complex class diagrams, you can group classes into packages. A
package is a collection of logically related UML elements. The diagram below is a
business model in which the classes are grouped into packages.
UNIFIED MODELING LANGUAGE Page | 10
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Packages appear as rectangles with small tabs at the top. The package name is
on the tab or inside the rectangle. The dotted arrows are dependencies. One package
depends on another if changes in the other could possibly force changes in the first.
Object diagrams show instances instead of classes. They are useful for
explaining small pieces with complicated relationships, especially recursive relationships.
This small class diagram shows that a university Department can contain lots of other
Departments.
The object diagram below instantiates the class diagram, replacing it by a concrete
example.
Each rectangle in the object diagram corresponds to a single instance. Instance
names are underlined in UML diagrams. Class or instance names may be omitted from
object diagrams as long as the diagram meaning is still clear.
UNIFIED MODELING LANGUAGE Page | 11
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Sequence diagrams:
Class and object diagrams are static model views. Interaction diagrams are
dynamic. They describe how objects collaborate.
A sequence diagram is an interaction diagram that details how operations
are carried out -- what messages are sent and when. Sequence diagrams are organized
according to time. The time progresses as you go down the page. The objects involved in
the operation are listed from left to right according to when they take part in the message
sequence.
Below is a sequence diagram for making a hotel reservation. The object initiating
the sequence of messages is a Reservation window.
The Reservation window sends a make Reservation () message to a Hotel
Chain. The Hotel Chain then sends a make Reservation () message to a Hotel. If the
Hotel has available rooms, then it makes a Reservation and a Confirmation.
UNIFIED MODELING LANGUAGE Page | 12
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Each vertical dotted line is a lifeline, representing the time that an object exists.
Each arrow is a message call. An arrow goes from the sender to the top of the activation
bar of the message on the receiver's lifeline. The activation bar represents the duration of
execution of the message.
In our diagram, the Hotel issues a self call to determine if a room is available. If
so, then the Hotel creates a Reservation and a Confirmation. The asterisk on the self
call means iteration (to make sure there is available room for each day of the stay in the
hotel). The expression in square brackets, [ ], is a condition.
Collaboration diagrams:
Collaboration diagrams are also interaction diagrams. They convey the same
information as sequence diagrams, but they focus on object roles instead of the times that
messages are sent. In a sequence diagram, object roles are the vertices and messages are
the connecting links.
The object-role rectangles are labeled with either class or object names (or both).
Class names are preceded by colons (: ).
UNIFIED MODELING LANGUAGE Page | 13
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Each message in a collaboration diagram has a sequence number. The top-level
message is numbered 1. Messages at the same level (sent during the same call) have the
same decimal prefix but suffixes of 1, 2, etc. according to when they occur.
State chart diagrams:
Objects have behaviors and state. The state of an object depends on its current
activity or condition. A state chart diagram shows the possible states of the object and
the transitions that cause a change in state.
Our example diagram models the login part of an online banking system. Logging
in consists of entering a valid social security number and personal id number, then
submitting the information for validation.
Logging in can be factored into four non-overlapping states: Getting SSN,
Getting PIN, Validating, and Rejecting. From each state comes a complete set of
transitions that determine the subsequent state.
UNIFIED MODELING LANGUAGE Page | 14
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
States are rounded rectangles. Transitions are arrows from one state to another.
Events or conditions that trigger transitions are written beside the arrows. Our diagram
has two self-transitions, one on Getting SSN and another on Getting PIN.
The initial state (black circle) is a dummy to start the action. Final states are also
dummy states that terminate the action.
The action that occurs as a result of an event or condition is expressed in the form
/action. While in its Validating state, the object does not wait for an outside event to
trigger a transition. Instead, it performs an activity. The result of that activity determines
its subsequent state.
Activity diagrams:
An activity diagram is essentially a fancy flowchart. Activity diagrams and state
chart diagrams are related. While a state chart diagram focuses attention on an object
undergoing a process (or on a process as an object), an activity diagram focuses on the
flow of activities involved in a single process. The activity diagram shows the how those
activities depend on one another.
For our example, we used the following process.
"Withdraw money from a bank account through an ATM."
The three involved classes (people, etc.) of the activity are Customer, ATM, and
Bank. The process begins at the black start, circle at the top and ends at the concentric
white/black stop circles at the bottom. The activities are rounded rectangles.
UNIFIED MODELING LANGUAGE Page | 15
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Activity diagrams can be divided into object swim-lanes that determine which
object is responsible for which activity. A single transition comes out of each activity,
connecting it to the next activity.
A transition may branch into two or more mutually exclusive transitions. Guard
expressions (inside [ ]) label the transitions coming out of a branch. A branch and
its subsequent merge marking the end of the branch appear in the diagram as hollow
diamonds.
A transition may fork into two or more parallel activities. The fork and the subsequent
join of the threads coming out of the fork appear in the diagram as solid bars.
UNIFIED MODELING LANGUAGE Page | 16
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Component and deployment diagrams:
A component is a code module. Component diagrams are physical analogs of
class diagram. Deployment diagrams show the physical configurations of software and
hardware.
The following deployment diagram shows the relationships among software and
hardware components involved in real estate transactions.
The physical hardware is made up of nodes. Each component belongs on a node.
Components are shown as rectangles with two tabs at the upper left.
STEPS FOR MODELING UML DIAGRAMS Modeling steps for Use case Diagram:
1. Draw the lines around the system and actors lie outside the
system.
UNIFIED MODELING LANGUAGE Page | 17
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
2. Identify the actors which are interacting with the system.
3. Separate the generalized and specialized actors.
4. Identify the functionality the way of interacting actors with
system and specify the behavior of actor.
5. Functionality or behavior of actors is considered as use cases.
6. Specify the generalized and specialized use cases.
7. Se the relationship among the use cases and in between actor
and use cases.
8. Adorn with constraints and notes.
9. If necessary, use collaborations to realize use cases.
Modeling steps for Sequence Diagram:
1. Set the context for the interactions, system, subsystem, classes,
object or use cases.
2. Set the stages for the interactions by identifying objects which are
placed as actions in interaction diagrams.
3. Lay them out along the X-axis by placing the important object at
the left side and others in the next subsequent.
4. Set the lifelines for each and every object by sending create and
destroy messages.
5. Start the message which is initiating interactions and place all other
messages in the increasing order of items.
6. Specify the time and space constraints.
7. Set the pre and post conditioned.
Modeling steps for Collaboration Diagram:
1. Set the context for interaction, whether it is system, subsystem,
operation or class or one scenario of use case or collaboration.
UNIFIED MODELING LANGUAGE Page | 18
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
2. Identify the objects that play a role in the interaction. Lay them
as vertices in graph, placing important objects in centre and
neighboring objects to outside.
3. Set the initial properties of each of these objects. If the attributes
or tagged values of an object changes in significant ways over the
interaction, place a duplicate object, update with these new values
and connect them by a message stereotyped as become or copy.
4. Specify the links among these objects. Lay the association links
first represent structural connection. Lay out other links and adorn
with stereotypes.
5. Starting with the message that initiates this interaction, attach each
subsequent message to appropriate link, setting sequence number
as appropriate.
6. Adorn each message with time and space constraints if needed
7. Attach pre & post conditions to specify flow of control formally.
Modeling steps for Activity Diagram:
1. Select the object that has high level responsibilities.
2. These objects may be real or abstract. In either case, create a swim-
lane for each important object.
3. Identify the precondition of initial state and post conditions of final
state.
4. Beginning at initial state, specify the activities and actions and
render them as activity states or action states.
5. For complicated actions, or for a set of actions that appear multiple
times, collapse these states and provide separate activity diagram.
6. Render the transitions that connect these activities and action
states.
7. Start with sequential flows. Consider branching, fork and joining.
8. Adorn with notes tagged values and so on.
UNIFIED MODELING LANGUAGE Page | 19
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Modeling steps for State chart Diagram:
1. Choose the context for state machine, whether it is a class, a use
case, or the system as a whole.
2. Choose the initial & final states of the objects.
3. Decide on the stable states of the object by considering the
conditions in which the object may exist for some identifiable
period of time.
4. The high-level states of the objects & only then consider its
possible sub-states.
5. Decide on the meaningful partial ordering of stable states over the
lifetime of the object.
6. Decide on the events that may trigger a transition from state to
state. Model these events as triggers to transitions that move from
one legal ordering of states to another.
7. Attach actions to these transitions and/or to these states.
8. Consider ways to simplify your machine by using sub states,
branches, forks, joins and history states.
9. Check that all states are reachable under some combination of
events.
10. Check that no state is a dead from which no combination of events
will transition the object out of that state.
11. Trace through the state machine, either manually or by using tools,
to check it against expected sequence of events & their responses.
Modeling steps for Class Diagram:
1. Identity the things that are interacting with class diagram.
2. Set the attributes and operations.
3. Set the responsibilities.
4. Identify the generalization and specification classes.
5. Set the relationship among all the things.
6. Adorn with tagged values, constraints and notes.
UNIFIED MODELING LANGUAGE Page | 20
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Modeling steps for Object Diagram:
1. Identify the mechanisms which you would like to model.
2. Identify the classes, use cases, interface, subsystem which are
collaborated with mechanisms.
3. Identify the relationship among all objects.
4. Walk through the scenario until to reach the certain point and
identify the objects at that point.
5. Render all these classes as objects in diagram.
6. Specify the links among all these objects.
7. Set the values of attributes and states of objects.
Modeling steps for Component Diagram:
1. Identify the component libraries and executable files which are
interacting with the system.
2. Represent this executables and libraries as components.
3. Show the relationships among all the components.
4. Identify the files, tables, documents which are interacting with the
system.
5. Represent files, tables, documents as components.
6. Show the existing relationships among them generally dependency.
7. Identify the seams in the model.
8. Identify the interfaces which are interacting with the system.
9. Set attributes and operation signatures for interfaces.
10. Use either import or export relationship in b/w interfaces &
components.
11. Identify the source code which is interacting with the system.
12. Set the version of the source code as a constraint to each source
code.
13. Represent source code as components.
UNIFIED MODELING LANGUAGE Page | 21
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
14. Show the relationships among components.
15. Adorn with nodes, constraints and tag values.
Modeling steps for Deployment Diagram:
1. Identify the processors which represent client & server.
2. Provide the visual cue via stereotype classes.
3. Group all the similar clients into one package.
4. Provide the links among clients & servers.
5. Provide the attributes & operations.
6. Specify the components which are living on nodes.
7. Adorn with nodes & constraints & draw the deployment diagram.
APPLICATION OF RATIONAL ROSE TO UML: Rational Rose was developed by IBM Corporation in order to develop a software
system based on the concepts of Object Oriented Analysis and Design approach as
developed from the models of Grady Booch, Jacobson and Ram Baugh methodologies,
resulting into a Unified approach.
Rational Rose is an object-oriented Unified Modeling Language (UML) software
design tool intended for visual modeling and component construction of enterprise-level
software applications. In much the same way a theatrical director blocks out a play, a
software designer uses Rational Rose to visually create (model) the framework for an
application by blocking out classes with actors (stick figures), use case elements (ovals),
objects (rectangles) and messages/relationships (arrows) in a sequence diagram using
drag-and-drop symbols. Rational Rose documents the diagram as it is being constructed
and then generates code in the designer's choice of C++, Visual Basic, Java, Oracle8,
CORBA or Data Definition Language.
Two popular features of Rational Rose are its ability to provide iterative
development and round-trip engineering. Rational Rose allows designers to take
advantage of iterative development (sometimes called evolutionary development)
because the new application can be created in stages with the output of one iteration
UNIFIED MODELING LANGUAGE Page | 22
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
becoming the input to the next. (This is in contrast to waterfall development where the
whole project is completed from start to finish before a user gets to try it out.) Then, as
the developer begins to understand how the components interact and makes modifications
in the design, Rational Rose can perform what is called "round-trip engineering" by going
back and updating the rest of the model to ensure the code remains consistent.
The overall model contains classes, use cases, objects, packages, operations,
component packages, components, processors, devices and the relationship between
them. Each of these model elements possess model properties that identify and
characterize them.
A model also contains diagrams and specifications, which provides a means of
visualizing and manipulating the model’s elements and their model properties. Since
diagram is used to illustrate multiple views of a model, icons representing a model
element can appear in none, or several of a model’s diagrams.
The application therefore enables you to control, which element, relationship
and property icons appear on each diagram, using facilities provided by its application
window. Within its application window, it displays each diagram in a diagram window
and each specification in a specification window.
It provides a separate tool, called Model Integrator to compare and merge models
and their controlled units. It also enables teams to reuse large- scale design assets
developed in earlier modeling efforts by providing the possibility to add frame works in
Rational Rose.
UNIFIED MODELING LANGUAGE Page | 23
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Point of Sale System
UNIFIED MODELING LANGUAGE Page | 24
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Point of Sale System
AIM: To create a Point of Sale System
ACTORS:
1. customer
2. cashier
USECASES:
1. Bar code scanning
2. Process sale
3. Close sale
4. Pay Bill.
5. Tax calculation
6. Buy product
7. Update Inventory
ALGORITHMIC PROCEDURE: STEP 1: Start the application
STEP 2: Create the require actors and use cases in the browser window
STEP 3: Go to new use case view and then click the use case view and open a new
package
STEP 4: Rename the new package with the package with required names
STEP 5: Create two packages actor and use case
UNIFIED MODELING LANGUAGE Page | 25
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Class diagram:
Use case Diagram:
UNIFIED MODELING LANGUAGE Page | 26
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Sequence diagram:
Collaboration diagram:
UNIFIED MODELING LANGUAGE Page | 27
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Activity diagram:
Component Diagram:
Deployment diagram:
UNIFIED MODELING LANGUAGE Page | 28
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
RESULT:
Thus various UML Diagrams were generated for POINT OF SALE SYSTEM and the
corresponding code was generated using Visual Basic.
UNIFIED MODELING LANGUAGE Page | 29
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
ONLINE BOOK SHOP SYSTEM
UNIFIED MODELING LANGUAGE Page | 30
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
ONLINE BOOKSHOP SYSTEM SPECIFICATIONS:
Objectives:
The purpose of this document is to define requirements of the online bookshop
system. This specification lists the requirements that are not readily captured in the use
cases of the Use case model. The supplementary specifications and the use case model
together capture a complete set of requirement on the system.
Scope:
The specification defines the non-functional requirements of the system, such as
reliability, usability, performance and supportability. The functional requirements are
defined in the use case specifications.
References: Amazon.com, BN.com, Tigris.com
UNIFIED MODELING LANGUAGE Page | 31
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Functionality: Multiple users must be able to perform work concurrently. The user must be
notified about the stock of books in the inventory.
Usability: The desktop user-interface shall be Windows 95, 98 compliant.
Reliability: The system shall be available 24 hrs a day and 7 days a week.
Performance:● The system shall support large number of simultaneous users against the central
database at any time.
● The system shall provide access to catalog database with no more then ten
seconds latency.
● The system must be able to complete 80% of all transactions within 2 minutes.
Supportability: None
Brief Description of the Project: The current project emphasizes on analysis and design of an online
bookshop system. That serves the customers needs. The customer’s available activities
in the proposed system from logging on the browsing the book store, selecting items and
making purchases are described.
PROBLEM STATEMENT FOR ONLINE BOOKSHOP SYSTEM:
As a young promising student you are tasked with developing an
online book shop system. The system should be competitive enough by providing the
facilities/options that are currently provided by reputed systems like Amazon.com and
BN.com. The proposed system should allow the customer with activities from logging
on to the system, browsing the book store, selecting items and making purchases i.e., the
UNIFIED MODELING LANGUAGE Page | 32
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
customer will be able to browse, select and buy books online.
An internet customer should have a login to access the book store. Registration of the
customer with the book shop is primary. A registered customer can browse through the
book catalogue and can make selections. The new system should even assist the customer
in locating a book in that, the customer can browse the current book catalogue online and
this should detail the book details and stock details for the books.
The user should be able to filter by book title, author and book
category. If the user cannot find a book in current category, they should place an order
and request the book. This includes details like Author, Publishers, Title, Book Name and
Category. The payment is done through credit card and also through gift cheques etc., the
customer is informed about the transaction details through e-mails. The shipment details
are entered by the customer and through those details the delivery is processed.
USE CASE The use case model describes the proposed functionality of the system. A use
case represents a discrete unit of interaction between a user and the system. A use case
is a single unit of meaningful work. Each use case has a description which describes the
functionality that will be built in a proposed system. A use case may ‘include’ another
use case functionality or ‘extend’ another use case with its own behavior.
ACTORS: ● Customer
● Amazon
USE CASES:● Registration
● Login
● Create order
● Book catalog
UNIFIED MODELING LANGUAGE Page | 33
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
● Manage cart and payments
● Order status
● Inventory
RELATIONSHIPS USED:● Association
● Dependency
● Composition
Modeling steps for Use case Diagram:
1. Draw the lines around the system and actors lie outside the system.
Identify the actors which are interacting with the system.
2. Separate the generalized and specialized actors.
3. Identify the functionality the way of interacting actors with system and
specify the behavior of actor.
4. Functionality or behavior of actors is considered as use cases.
5. Specify the generalized and specialized use cases.
6. See the relationship among the use cases and in between actor and use
cases. Adorn with constraints and notes.
7. If necessary, use collaborations to realize use cases.
Modeling steps for Sequence Diagram:
1. Set the context for the interactions, system, subsystem, classes, object or use
cases.
2. Set the stages for the interactions by identifying objects which are placed as
actions in interaction diagrams.
UNIFIED MODELING LANGUAGE Page | 34
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
3. Lay them out along the X-axis by placing the important object at the left side
and others in the next subsequent.
4. Set the lifelines for each and every object by sending create and destroy
messages.
5. Start the message which is initiating interactions and place all other messages
in the increasing order of items.
6. Specify the time and space constraints.
7. Set the pre and post conditioned.
Modeling steps for Collaboration Diagram:1. Set the context for interaction, whether it is system, subsystem, operation
or class or one scenario of use case or collaboration.
2. Identify the objects that play a role in the interaction. Lay them as vertices
in graph, placing important objects in centre and neighboring objects to
outside.
3. Set the initial properties of each of these objects. If the attributes or tagged
values of an object changes in significant ways over the interaction, place
a duplicate object, update with these new values and connect them by a
message stereotyped as become or copy.
4. Specify the links among these objects. Lay the association links first
represent structural connection. Lay out other links and adorn with
stereotypes.
5. Starting with the message that initiates this interaction, attach each
subsequent message to appropriate link, setting sequence number as
appropriate.
6. Adorn each message with time and space constraints if needed
7. Attach pre & post conditions to specify flow of control formally.
Modeling steps for Activity Diagram:
UNIFIED MODELING LANGUAGE Page | 35
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
1. Select the object that has high level responsibilities.
2. These objects may be real or abstract. In either case, create a swim lane for
each important object.
3. Identify the precondition of initial state and post conditions of final state.
4. Beginning at initial state, specify the activities and actions and render
them as activity states or action states.
5. For complicated actions, or for a set of actions that appear multiple times,
collapse these states and provide separate activity diagram.
6. Render the transitions that connect these activities and action states.
7. Start with sequential flows; consider branching, fork and joining.
8. Adorn with notes tagged values and so on.
Modeling steps for State chart Diagram:
1. Choose the context for state machine, whether it is a class, a use case, or
the system as a whole.
2. Choose the initial & final states of the objects.
3. Decide on the stable states of the object by considering the conditions
in which the object may exist for some identifiable period of time. Start
with the high-level states of the objects & only then consider its possible
substrates.
4. Decide on the meaningful partial ordering of stable states over the lifetime
of the object.
5. Decide on the events that may trigger a transition from state to state.
Model these events as triggers to transitions that move from one legal
ordering of states to another.
6. Attach actions to these transitions and/or to these states.
UNIFIED MODELING LANGUAGE Page | 36
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
7. Consider ways to simplify your machine by using sub states, branches,
forks, joins and history states.
8. Check that all states are reachable under some combination of events.
9. Check that no state is a dead from which no combination of events will
transition the object out of that state.
10. Trace through the state machine, either manually or by using tools, to
check it against expected sequence of events & their responses.
Modeling steps for Class Diagram:
1. Identity the things that are interacting with class diagram.
2. Set the attributes and operations.
3. Set the responsibilities.
4. Identify the generalization and specification classes.
5. Set the relationship among all the things.
6. Adorn with tagged values, constraints and notes.
Modeling steps for Object Diagram:
1. Identify the mechanisms which you would like to model.
2. Identify the classes, use cases, interface, subsystem which are collaborated
with mechanisms.
3. Identify the relationship among all objects.
4. Walk through the scenario until to reach the certain point and identify the
objects at that point.
5. Render all these classes as objects in diagram.
6. Specify the links among all these objects.
7. Set the values of attributes and states of objects.
UNIFIED MODELING LANGUAGE Page | 37
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Modeling steps for Component Diagram:
1. Identify the component libraries and executable files which are interacting
with the system.
2. Represent this executables and libraries as components.
3. Show the relationships among all the components.
4. Identify the files, tables, documents which are interacting with the system.
5. Represent files, tables, documents as components.
6. Show the existing relationships among them generally dependency.
7. Identify the seams in the model.
8. Identify the interfaces which are interacting with the system.
9. Set attributes and operation signatures for interfaces.
10. Use either import or export relationship in b/w interfaces & components.
11. Identify the source code which is interacting with the system.
12. Set the version of the source code as a constraint to each source code.
13. Represent source code as components.
14. Show the relationships among components.
15. Adorn with nodes, constraints and tag values.
Modeling steps for Deployment Diagram:
1. Identify the processors which represent client & server.
2. Provide the visual cue via stereotype classes.
3. Group all the similar clients into one package.
4. Provide the links among clients & servers.
5. Provide the attributes & operations.
6. Specify the components which are living on nodes.
7. Adorn with nodes & constraints & draw the deployment diagram.
CLASS DIAGRAM:
UNIFIED MODELING LANGUAGE Page | 38
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
A Class is a standard UML construct used to detail the pattern from which
objects will be produced at run time. A class is a specification- an object is an instance
of a class. Classes may be inherited from other classes, have other classes as attributes,
delegate responsibilities to other classes and implement abstract interfaces.
The class diagram for the proposed system has several classes. These classes
have attributes and operations. The description for each of them is described clearly.
The classes include
● Book shop staff
● Book
● Bookshop
● Item
● Customer
● Shopping cart
● Order
● Item order
● Shipping address and billing address.
PACKAGES:
The class diagram of the online book shop system is shown to be grouped into
three packages. The contents of the packages are as follows:
PACKAGE-1: BOOKSHOP This package consists of following classes:
1. Bookshop staff
2. Book
UNIFIED MODELING LANGUAGE Page | 39
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
3. Bookshop
4. Item
PACKAGE-2: CUSTOMER This package consists of following classes:
1. Customer
2. Address
3. Billing Address
4. Shipping Address
PACKAGE -3: ONLINE ORDERING This package consists of following classes:
1.Order
2.Item Order
3.Shopping Cart
CLASS DIAGRAM:
UNIFIED MODELING LANGUAGE Page | 40
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
USE CASE DIAGRAM FOR ONLINE BOOKSHOP SYSTEM:
SEQUENCE DIAGRAM:
UNIFIED MODELING LANGUAGE Page | 41
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
UML provides a graphical means of depicting object interactions over time in
sequence diagrams. These typically show a user or actor and the objects and
components they interact with in the execution of a use case.
COLLOBORATION DIAGRAM: Collaboration names a society of classes, interfaces and other elements that work
together to provide some cooperative behavior that is bigger than the sum of all its parts.
Collaboration diagram emphasis is based on structural organization of the objects that
send and receive messages.
STATE CHART DIAGRAM: Objects have behaviors and state. The state of an object depends
on its current activity or condition. A state chart diagram shows the possible states of the
object and the transitions that cause a change in state. The initial state (black circle) is a
dummy to start the action. Final states are also dummy states that terminate the action.
ACTIVITY DIAGRAM:
UNIFIED MODELING LANGUAGE Page | 42
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
An activity diagram is essentially a fancy flowchart. Activity diagrams and state
chart diagrams are related. While a state chart diagram focuses attention on an object
undergoing a process (or on a process as an object), an activity diagram focuses on the
flow of activities involved in a single process. The activity diagram shows the how those
activities depend on one another. Activity diagrams can be divided into object swim lanes
that determine which object is responsible for which activity. A single transaction comes
out of each activity, connecting it to the next activity.
COMPONENT DIAGRAM:
A component is a code module. Component diagrams are physical
analogs of class diagram. Each component belongs on a node. Components are shown as
rectangles with two tabs at the upper left.
UNIFIED MODELING LANGUAGE Page | 43
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
DEPLOYMENT DIAGRAM: Deployment diagram shows the physical configurations of software and
hardware.
RESULT:
Thus various UML Diagrams were generated for ONLINE BOOK SHOP and the
corresponding code was generated using Visual Basic.
UNIFIED MODELING LANGUAGE Page | 44
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
AN ONLINE AUCTION SALE
UNIFIED MODELING LANGUAGE Page | 45
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Aim:
To create a case study on ONLINE AUCTION
Overview:
The online auction system is a design about a website where sellers collect and prepare a
list of items they want to sell and place it on the website for visualizing. To accomplish
this purpose the user has to access the site. Incase it’s a new user he has to register.
Purchaser logs in and selects items they want to buy and keep bidding for it. Interacting
with the purchasers and sellers in the chat room does this. The purchaser making the
highest bid for the item before the close of the auction is declared as the owner of the
item. If the auctioneer or the purchaser does not want to bid for the product then there is
fixed cutoff price mentioned for every product. He can pay the amount directly and own
the product. The purchaser gets a confirmation of his purchase as an acknowledgement
from the website. After the transaction by going back to the main menu where he can
view other items.
As per case study, the following analysis diagrams will be created.
UNIFIED MODELING LANGUAGE Page | 46
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
1. Use cases for the system.
2. Class diagram for initially identified classes.
3. Activity diagram to show flow of each use case.
4. Sequence and collaboration diagrams.
5. State chart diagram shows states before and after each action.
Conceptualization:
Assumptions:
● The users are allowed to register and give user id’s to have identification.
● The users are allowed to bid for any price according to their wish provided it’s
more than the minimum price of auction.
● The fixed cut-off price is decided and confirmed for every product.
● The auctioneer requesting the product for the cut-off price is given priority.
● The auctioneer bidding the maximum price is given the product.
Inputs:
● The login details of the auctioneer.
● List of available products on the site.
● Details such as specifications and the price of each product.
● Bidding price of the auctioneer.
Outputs:
● The cut-off price for each product.
● Updated status of bid price.
● Status of each product if it is bid or sold for sale.
● Acknowledgement to whom the product is sold.
Key Terms:
UNIFIED MODELING LANGUAGE Page | 47
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
● Get details and bid the product.
● Deliver the product.
● Pay the price and log out.
An Auction Simulation:
● Bid for the product.
● Log on to the site.
● Fix or bid for the price.
● Function points
● Bidder request product details.
● Pay final price and bid the product.
● Loop
● Check any product details.
● Check for cutoff price.
Actors:
1. Purchaser
2. Seller
Use Cases in Auction System
1. Login
2. Seller
3. Purchaser
4. Chatting
5. Select Method of bidding
6. Select Method of Auction
7. Buy Goods
8. Register for goods
9. Select history of database
Use Cases In Purchaser’s Diagram:
UNIFIED MODELING LANGUAGE Page | 48
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
1. Validate User
2. Record chatting.
ALGORITHMIC PROCEDURE:
STEP 1: Start the application
STEP 2: Create the require actors and use cases in the browser window
STEP 3: Got new use case view and then click the use case view and
Open a new package
STEP 4: Rename the new package with the package with required
Names
STEP 5: Create two packages actor and use case
DIAGRAMS:
Modeling steps for Use case Diagram
1. Draw the lines around the system and actors lie outside the system.
2. Identify the actors which are interacting with the system.
3. Separate the generalized and specialized actors.
4. Identify the functionality the way of interacting actors with system and
specify the behavior of actor.
5. Functionality or behavior of actors is considered as use cases.
6. Specify the generalized and specialized use cases.
7. Se the relationship among the use cases and in between actor and use
cases.
8. Adorn with constraints and notes.
9. If necessary, use collaborations to realize use cases.
Modeling steps for Sequence Diagrams
1. Set the context for the interactions, system, subsystem, classes, object or
use cases.
UNIFIED MODELING LANGUAGE Page | 49
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
2. Set the stages for the interactions by identifying objects which are placed
as actions in interaction diagrams.
3. Lay them out along the X-axis by placing the important object at the left
side and others in the next subsequent.
4. Set the lifelines for each and every object by sending create and destroy
messages.
5. Start the message which is initiating interactions and place all other
messages in the increasing order of items.
6. Specify the time and space constraints.
7. Set the pre and post conditioned.
Modeling steps for Collaboration Diagrams
1. Set the context for interaction, whether it is system, subsystem, operation
or class or one scenario of use case or collaboration.
2. Identify the objects that play a role in the interaction. Lay them as vertices
in graph, placing important objects in centre and neighboring objects to
outside.
3. Set the initial properties of each of these objects. If the attributes or tagged
values of an object changes in significant ways over the interaction, place
a duplicate object, update with these new values and connect them by a
message stereotyped as become or copy.
4. Specify the links among these objects. Lay the association links first
represent structural connection. Lay out other links and adorn with
stereotypes.
5. Starting with the message that initiates this interaction, attach each
subsequent message to appropriate link, setting sequence number as
appropriate.
6. Adorn each message with time and space constraints if needed
7. Attach pre & post conditions to specify flow of control formally.
Modeling steps for Activity Diagrams
UNIFIED MODELING LANGUAGE Page | 50
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
1. Select the object that has high level responsibilities.
2. These objects may be real or abstract. In either case, create a swim lane for
each important object.
3. Identify the precondition of initial state and post conditions of final state.
4. Beginning at initial state, specify the activities and actions and render
them as activity states or action states.
5. For complicated actions, or for a set of actions that appear multiple times,
collapse these states and provide separate activity diagram.
6. Render the transitions that connect these activities and action states.
7. Start with sequential flows, consider branching, fork and joining.
8. Adorn with notes tagged values and so on
Modeling steps for State chart Diagram
1. Choose the context for state machine, whether it is a class, a use case, or
the system as a whole.
2. Choose the initial & final states of the objects.
3. Decide on the stable states of the object by considering the conditions
in which the object may exist for some identifiable period of time. Start
with the high-level states of the objects & only then consider its possible
substrates.
4. Decide on the meaningful partial ordering of stable states over the lifetime
of the object.
5. Decide on the events that may trigger a transition from state to state.
Model these events as triggers to transitions that move from one legal
ordering of states to another.
6. Attach actions to these transitions and/or to these states.
7. Consider ways to simplify your machine by using substates, branches,
forks, joins and history states.
8. Check that all states are reachable under some combination of events.
9. Check that no state is a dead from which no combination of events will
transition the object out of that state.
UNIFIED MODELING LANGUAGE Page | 51
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
10.Trace through the state machine, either manually or by using tools, to
check it against expected sequence of events & their responses.
Modeling steps for Class Diagrams
1. Identity the things that are interacting with class diagram.
2. Set the attributes and operations.
3. Set the responsibilities.
4. Identify the generalization and specification classes.
5. Set the relationship among all the things.
6. Adorn with tagged values, constraints and notes.
Modeling steps for Object Diagrams
1. Identify the mechanisms which you would like to model.
2. Identify the classes, use cases, interface, subsystem which are
collaborated with mechanisms.
3. Identify the relationship among all objects.
4. Walk through the scenario until to reach the certain point and
identify the objects at that point.
5. Render all these classes as objects in diagram.
6. Specify the links among all these objects.
7. Set the values of attributes and states of objects.
Modeling steps for Component Diagrams
1. Identify the component libraries and executable files which are
interacting with the system.
2. Represent this executables and libraries as components.
3. Show the relationships among all the components.
4. Identify the files, tables, documents which are interacting with the
system.
5. Represent files,tables,documents as components.
6. Show the existing relationships among them generally dependency.
UNIFIED MODELING LANGUAGE Page | 52
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
7. Identify the seams in the model.
8. Identify the interfaces which are interacting with the system.
9. Set attributes and operation signatures for interfaces.
10.Use either import or export relationship in b/w interfaces &
components.
11. Identify the source code which is interacting with the system.
12. Set the version of the source code as a constraint to each source
code.
13. Represent source code as components.
14. Show the relationships among components.
15. Adorn with nodes, constraints and tag values.
Modeling steps for Deployment Diagram
1. Identify the processors which represent client & server.
2. Provide the visual cue via stereotype classes.
3. Group all the similar clients into one package.
4. Provide the links among clients & servers.
5. Provide the attributes & operations.
6. Specify the components which are living on nodes.
7. Adorn with nodes & constraints & draw the deployment diagram.
UNIFIED MODELING LANGUAGE Page | 53
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Class Diagram: Use case Diagram: Sequence diagram:
UNIFIED MODELING LANGUAGE Page | 54
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Collaboration Diagram: ActivityDiagram:
State chart diagram: COMPONENT DIAGRAM: DEPLOYMENT DIAGRAM:
UNIFIED MODELING LANGUAGE Page | 55
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
AN AIRPORT SIMULATION
UNIFIED MODELING LANGUAGE Page | 56
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
A Multi- Threaded Airport Simulation Aim: To create a Multi- Threaded Airport Simulation
Actors: ● Actors
● Pilot
Use Cases:
1. Respond on Radar
2. Check Runway
3. Give Signal
4. Determine Priority
5. Send plane details
6. Land/take off
Algorithmic Procedure:
STEP 1: Start the application
STEP 2: Create the require actors and use cases in the browser window
STEP 3: Go to new use case view and then click the use case view and open a
new class.
STEP 4: Rename the new package with the package with required names
STEP 5: Create two packages actor and use case
Overview:
A critical step of the project is to design a modeling and simulation
infrastructure to experiment and validate the proposed solutions
UNIFIED MODELING LANGUAGE Page | 57
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
The ever growing demand of air transport shows the vulnerability of the current
air traffic management system: Congestion, time delays, etc., particularly in poor weather
conditions.
The project is focused on controller and pilot assistance systems for approach and
ground movements. The critical step of the project was to design an airport modeling
and simulation infrastructure to improve the safety and efficiency of ground movements
in all weather conditions. It simulates the arrivals and departures at an airport in a time
sequence. During every minute, planes may enter the systems, they may land, they
may take off, or they may crash. The project must keep track of planes, assign planes
to runways, execute the take offs and landings, and keep track of status of each plan,
runway and terminal.
So the finally made computer software should model various aspects of the
total airports operation-connecting airside and landside, literally from the airspace to the
curb.
As part of case study, following analysis diagrams will be created
1. Use cases for the system.
2. Class diagram for initially identified classes.
3. Activity diagram to show flow for each use case.
4. Sequence and Collaboration diagram.
5. State chart diagram shows states before and after each action.
Conceptualization
Assumptions:● All takeoffs take the same amount of time and all landings take the same amount
of time (through these two times may be different).
● Planes arrive for landing at random times, but with a specified probability of a
plane arriving during any given minute.
● Planes arrive for takeoff at random times, but with a specified probability of a
plane arriving during any given minute
UNIFIED MODELING LANGUAGE Page | 58
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
● Landings have priorities over takeoffs.
● Planes arriving for landing have a random amount of fuel and they will crash if
they do not land before they run out of fuel.
Input will be:● The amount of time needed for one plane to land.
● The amount of time needed for one plane to takeoff.
● The probability of a plane entering the landing queue in any given minute.
● The probability of a plane entering the takeoff queue in any given minute.
● The maximum minutes until a plane waiting to land will crash.
● The statues of each runway, plane and terminal.
The Output of the program will be:● Total simulation time.
● The number of planes that takeoff in the simulated time.
● The number of planes that landed in the simulated time.
● The average time a plane spent in the takeoff queue.
● The average time a plane spent in the landing queue.
● Updated status of each runway, plane, and terminal.
Key terms:Aircraft simulation.
Airport: runways, terminals, planes, control room.
Aircraft: passengers, model no. cockpit, pilots.
Function points:
1. Transmit/receive signals.
2. Pilot sends signals for takeoff/landing.
3. Loop
- Check status of each runway.
- Finalize a free runway.
- Assign the runway to the plan.
UNIFIED MODELING LANGUAGE Page | 59
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
4. Update status of runway and terminal.
5. Get the plane landed safely.
6. Check if time left for next departure.
7. Loop
- Check the status of each terminal.
- Validate if terminal suitable for particular aircraft.
- Assign terminal to aircraft.
8. Get the plane parked in the terminal.
9. Update status of terminal.
Requirement Analysis:
Textual Analysis:This covers the requirements and diagrams of the project. The complete
simulation of airport control system as follows
Actors:These are who are involved in interaction of the whole process.
1. Air traffic control (ATC) is a service provided by ground-based controllers who
direct aircraft on the ground and in the air. The primary purpose of ATC systems
worldwide is to separate aircraft to prevent collisions, to organize and expedite
the flow of traffic, and to provide information and other support for pilots when
able.
2. Pilot: He is the person who controls the aircraft. He transmits or receives signals
regarding the free runways, and terminal from the control room. He is responsible
for the safe landing or takeoffs the planes.
Use cases:The steps involved in the whole process are indicated as use cases.
UNIFIED MODELING LANGUAGE Page | 60
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
1. Respond on Radar
2. Check Runway
3. Give Signal
4. Determine Priority
5. Send plane details
6. Land/take off
1. Respond to Radar: The pilot in the aircraft transmits signals for requesting a
free runway to takeoff or land. The control room on the ground receives these
signals from the aircrafts.
2. Check runway: The status of each runway in the airport is checked if it’s free
and its going to be free until the particular aircraft is landed or takeoff. If this is
going to be free then runway number is transmitted to the pilot on aircraft.
3. Give Signal: The ATC will transmit signals to the pilots depending upon the
availability of the runway.
4. Determine Priority: The ATC should determine the priority of the flights and
should transmit signals for Landing/Takeoff.
5. Send Plane Details: After a particular signal is generated, the pilot of the flight
should send the details of the plane to the ATC.
6. Land/Takeoff: The pilot of the planes can now land/takeoff their planes.
Classes:The classes contain the attributes and operations related to them the main classes
classified in this solution are:
1. ATC
2. Pilot
Diagrams:
Class Diagram A Class is a standard UML construct used to detail the pattern
from which objects will be produced at run time. A class is a specification- an object is
an instance of a class. Classes may be inherited from other classes, have other classes as
UNIFIED MODELING LANGUAGE Page | 61
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
attributes, delegate responsibilities to other classes and implement abstract interfaces.
Classes of airport simulation are:
Class Attributes Operations
ATC -name
- eid
+Respond on radar
+Receive plane details
+Check runway
+determine priority
+give signal
Pilot -name
-pid
-planeno.
+Send plane details
+Receive signal
+Land/Takeoff
Use Case Diagram:
The use case model describes the proposed functionality of the system.
A use case represents a discrete unit of interaction between a user and the system. A use
case is a single unit of meaningful work. Each use case has a description which describes
the functionality that will be built in a proposed system. A use case may ‘include’ another
use case functionality or ‘extend’ another use case with its own behavior.
Sequence diagram:
UML provides a graphical means of depicting object interactions over time
in sequence diagrams. These typically show a user or actor and the objects and
components they interact with in the execution of a use case.
1. Technical head: He is the person who supervises the controls the ground
traffic on runway. He checks the status of runways and assigns free terminals
for takeoff and landing.
UNIFIED MODELING LANGUAGE Page | 62
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
2. Pilot: He is the person who controls the aircraft. He transmits or Receives
signals regarding the free runways and terminal from the control room. He is
responsible for the safe landing or takeoff the planes.
Objects:1. ATC
2. Radar
3. Runway
4. Pilot
Collaboration Diagram:
Collaboration names a society of classes, interfaces and other
elements that work together to provide some cooperative behavior that is bigger than
the sum of all its parts. Collaboration diagram emphasis is based on structural
organization of the objects that send and receive messages.
Activity Diagram:
An activity diagram is essentially a fancy flowchart. Activity diagrams
and state chart diagrams are related. While a state chart diagram focuses attention on an
object undergoing a process (or on a process as an object), an activity diagram focuses on
the flow of activities involved in a single process.
The activity diagram shows the how those activities depend on
one another. Activity diagrams can be divided into object swim lanes that determine
which object is responsible for which activity. A single transaction comes out of each
activity, connecting it to the next activity.
State Chart Diagram:
UNIFIED MODELING LANGUAGE Page | 63
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Objects have behaviors and state. The state of an object depends on its
current activity or condition. A state chart diagram shows the possible states of the object
and the transitions that cause a change in state. The initial state (black circle) is a dummy
to start the action. Final states are also dummy states that terminate the action.
Component Diagram:
A component is a code module. Component diagrams are physical analogs
of class diagram. Each component belongs on a node. Components are shown as
rectangles with two tabs at the upper left.
Deployment Diagram:
Deployment diagram shows the physical configurations of software and
hardware.
UNIFIED MODELING LANGUAGE Page | 64
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Class Diagram: Use Case Diagram: Sequence Diagram:
Collaboration Diagram:
UNIFIED MODELING LANGUAGE Page | 65
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Activity Diagram:
State Chart Diagram:
UNIFIED MODELING LANGUAGE Page | 66
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Component Diagram: Deployment Diagram:
UNIFIED MODELING LANGUAGE Page | 67
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Result: The various UML diagrams were drawn for AIRPORT SIMULATION SYSTEM
application and the corresponding code was generated.
UNIFIED MODELING LANGUAGE Page | 68
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
A SIMULATED COMPANY
UNIFIED MODELING LANGUAGE Page | 69
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
OVERVIEW:
A critical step of the project is to design a modeling and simulation infrastructure to
experiment and validate the proposed solutions.
Simulated company is an example that shows the documents produced when undertaking
the analysis and design of an application that simulates a small manufacturing company.
This application is called Simco: Simulated Company.
The project if focused on the user to take lend, purchase a machine and over a
series of monthly and yearly production runs follows the concept of the company. The
company has to see all the takings and the losses. They have to see all dealings of the
company and see the additional features of the machine for better development.
The company accounts are updated for a given month. The accounts take into the
gross profits from the sales. General expenses such as salary and rent are taken into
account to calculate the net profit for the company. In addition details such as inventory
and sales are updated.
As part of the case study, following analysis diagrams will be updated.
○ Use case for the system○ Class diagram for initially identified classes.○ Activity diagram to show flow for each use case.○ Sequence and collaboration diagrams.○ State chart diagram shows states before and after each action.
UNIFIED MODELING LANGUAGE Page | 70
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Conceptualization:
Assumptions:
● The company has to take the loan and repay the loan.
● It has to purchase machinery and start the production.
● The sales person has to sell the foods and update the details in the record.
● The sales department has to submit the record and stock details required.
● The performance department has to prepare record statistics as given by marketing
department.
● The performance department has to get collected details from all the departments and
submit to the company.
Inputs:
● The amount of time required for sanctioning the loan.
● The amount of time needed for the production.
● The probability for estimating the machinery cost and raw materials.
● The probability of estimating profit and loss.
Outputs:
● Total time required in completing a project.
● The number of goods manufactured in a simulated time.
● Number of sales done in a project.
● Getting profit and loss for every month.
● Case study of the project.
Key Terms:Pay loan/repay loan
Purchase machinery and start production.
Sell the products and updated the records.
The performance department has to update the statistics and to the company.
UNIFIED MODELING LANGUAGE Page | 71
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Modeling steps for Use case Diagram:
1. Draw the lines around the system and actors lie outside the system.
2. Identify the actors which are interacting with the system.
3. Separate the generalized and specialized actors.
4. Identify the functionality the way of interacting actors with system and
specify the behavior of actor.
5. Functionality or behavior of actors is considered as use cases.
6. Specify the generalized and specialized use cases.
7. Se the relationship among the use cases and in between actor and use
cases.
8. Adorn with constraints and notes.
9. If necessary, use collaborations to realize use cases.
Modeling steps for Sequence Diagram:1. Set the context for the interactions, system, subsystem, classes, object or
use cases.
2. Set the stages for the interactions by identifying objects which are placed
as actions in interaction diagrams.
3. Lay them out along the X-axis by placing the important object at the left
side and others in the next subsequent.
4. Set the lifelines for each and every object by sending create and destroy
messages.
5. Start the message which is initiating interactions and place all other
messages in the increasing order of items.
6. Specify the time and space constraints. Set the pre and post conditioned.
Modeling steps for Collaboration Diagram:
UNIFIED MODELING LANGUAGE Page | 72
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
1. Set the context for interaction, whether it is system, subsystem, operation
or class or one scenario of use case or collaboration.
2. Identify the objects that play a role in the interaction. Lay them as vertices
in graph, placing important objects in centre and neighboring objects to
outside.
3. Set the initial properties of each of these objects. If the attributes or tagged
values of an object changes in significant ways over the interaction, place
a duplicate object, update with these new values and connect them by a
message stereotyped as become or copy.
4. Specify the links among these objects. Lay the association links first
represent structural connection. Lay out other links and adorn with
stereotypes.
5. Starting with the message that initiates this interaction, attach each
subsequent message to appropriate link, setting sequence number as
appropriate.
6. Adorn each message with time and space constraints if needed
7. Attach pre & post conditions to specify flow of control formally.
Modeling steps for Activity Diagram:
1. Select the object that has high level responsibilities.
2. These objects may be real or abstract. In either case, create a swim lane for
each important object.
3. Identify the precondition of initial state and post conditions of final state.
4. Beginning at initial state, specify the activities and actions and render
them as activity states or action states.
5. For complicated actions, or for a set of actions that appear multiple times,
collapse these states and provide separate activity diagram.
6. Render the transitions that connect these activities and action states.
7. Start with sequential flows. Consider branching, fork and joining.
UNIFIED MODELING LANGUAGE Page | 73
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
8. Adorn with notes tagged values and so on.
Modeling steps for State chart Diagram:1. Choose the context for state machine, whether it is a class, a use case, or
the system as a whole.
2. Choose the initial & final states of the objects.
3. Decide on the stable states of the object by considering the conditions
in which the object may exist for some identifiable period of time. Start
with the high-level states of the objects & only then consider its possible
substrates.
4. Decide on the meaningful partial ordering of stable states over the lifetime
of the object.
5. Decide on the events that may trigger a transition from state to state.
Model these events as triggers to transitions that move from one legal
ordering of states to another.
6. Attach actions to these transitions and/or to these states.
7. Consider ways to simplify your machine by using sub states, branches,
forks, joins and history states.
8. Check that all states are reachable under some combination of events.
9. Check that no state is a dead from which no combination of events will
transition the object out of that state.
10. Trace through the state machine, either manually or by using tools, to
check it against expected sequence of events & their responses.
Modeling steps for Class Diagram:
1. Identity the things that are interacting with class diagram.
2. Set the attributes and operations.
3. Set the responsibilities.
4. Identify the generalization and specification classes.
5. Set the relationship among all the things.
UNIFIED MODELING LANGUAGE Page | 74
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
6. Adorn with tagged values, constraints and notes.
Modeling steps for Object Diagram:1. Identify the mechanisms which you would like to model.
2. Identify the classes, use cases, interface, subsystem which are collaborated
with mechanisms.
3. Identify the relationship among all objects.
4. Walk through the scenario until to reach the certain point and identify the
objects at that point.
5. Render all these classes as objects in diagram.
6. Specify the links among all these objects.
7. Set the values of attributes and states of objects.
Modeling steps for Component Diagram:
1. Identify the component libraries and executable files which are interacting
with the system.
2. Represent this executables and libraries as components.
3. Show the relationships among all the components.
4. Identify the files, tables, documents which are interacting with the system.
5. Represent files, tables, documents as components.
6. Show the existing relationships among them generally dependency.
7. Identify the seams in the model.
8. Identify the interfaces which are interacting with the system.
9. Set attributes and operation signatures for interfaces.
10. Use either import or export relationship in b/w interfaces & components.
11. Identify the source code which is interacting with the system.
12. Set the version of the source code as a constraint to each source code.
13. Represent source code as components.
UNIFIED MODELING LANGUAGE Page | 75
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
14. Show the relationships among components.
15. Adorn with nodes, constraints and tag values.
Modeling steps for Deployment Diagram:1. Identify the processors which represent client & server.
2. Provide the visual cue via stereotype classes.
3. Group all the similar clients into one package.
4. Provide the links among clients & servers.
5. Provide the attributes & operations.
6. Specify the components which are living on nodes.
7. Adorn with nodes & constraints & draw the deployment diagram.
Class Diagram:
UNIFIED MODELING LANGUAGE Page | 76
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Use Case Diagram:
UNIFIED MODELING LANGUAGE Page | 77
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
UNIFIED MODELING LANGUAGE Page | 78
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Sequence Diagram:
UNIFIED MODELING LANGUAGE Page | 79
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Collaboration Diagram: Activity Diagram:
UNIFIED MODELING LANGUAGE Page | 80
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
State Chart Diagram:
UNIFIED MODELING LANGUAGE Page | 81
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Deployment Diagram: RESULT:
UNIFIED MODELING LANGUAGE Page | 82
GITAM INSTITUTE OF TECHNOLOGY UML LAB MANUAL
Thus various UML Diagrams were generated for SIMULATED COMPANY and the corresponding code was generated using Visual Basic.
UNIFIED MODELING LANGUAGE Page | 83