Uml Lab Manual

GITAM INSTITUTE OF TECHNOLOGY
NAME: T. JAHNAVI
ROLL NO: 1220609110
NAME OF THE
SNO EXPERIMENT PAGE REMARKS
NO
1 UML
INTRODUCTION
A POINT-OF-SALES
2 SYSTEM
ONLINE
3 BOOKSHOP
AN AUCTION
4 APPLICATION
A MULTI THREADED
5 AIRPORT SIMULATION
6 A SIMULATED
COMPANY
UNIFIED MODELING LANGUAGE Page no:

NAME: T. JAHNAVI
ROLL NO: 1220609110
UML INTRODUCTION

NAME: T. JAHNAVI
ROLL NO: 1220609110
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 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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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
NAME: T. JAHNAVI
ROLL NO: 1220609110
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:
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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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 inherits
all the (multiple) behavior of cats and dogs. This is not always
supported, as it can be hard to implement

NAME: T. JAHNAVI
ROLL NO: 1220609110
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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
"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.
A use case diagram is a collection of actors, use cases, and their

communications. We've put Make Appointment as part of a diagram

NAME: T. JAHNAVI
ROLL NO: 1220609110
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 --

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
• 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 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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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
zero or one instance. The notation n . . m
0..1
indicates n to m instances.
no limit on the number of instances (including
0..* or *
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
Sequence diagrams
Class and object diagrams are static model views. Interaction

diagrams are dynamic. They describe how objects collaborate.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
The object-role rectangles are labeled with either class or object

names (or both). Class names are preceded by colons (: ).
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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-transition, one on
Getting SSN and another on Getting PIN.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
Activity diagrams can be divided into object swimlanes that

determine which object is responsible for which activity. A single
transition comes out of each activity, connecting it to the next
activity.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
2. Identify the actors which are interacting with the
system.
3. Separate the generalized and specialized actors.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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
substates, 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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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 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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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 RATION 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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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
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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
HISTORY
ROSE = Rational Object Oriented Software Engineering
Rational Rose is a set of visual modeling tools for development of

object-oriented software. Roses uses the UML to provide graphical
method for non-programmers wanting to model business process as
well as programmers modeling application logic.

NAME: T. JAHNAVI
ROLL NO: 1220609110
Point of Sale System

NAME: T. JAHNAVI
ROLL NO: 1220609110
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: Goto 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

NAME: T. JAHNAVI
ROLL NO: 1220609110
Class diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
Use Case Diagram :
Buy product
Barcode scanning
Pay bill
Customer
Cashier
Process sale
Close sale
Update Inventory
Tax calculation

NAME: T. JAHNAVI
ROLL NO: 1220609110
POS system sequence diagram

NAME: T. JAHNAVI
ROLL NO: 1220609110
Cashier POS System
1: process sale
2: enter item
3: scan item
4: total cost
5: close sale
6: total cost with tax
7: bill generation
8: generate reoprt

NAME: T. JAHNAVI
ROLL NO: 1220609110
Process sale sequence diagram
Cashier POS System Codescanne Card reader Bank

r
1: Enter no of items
2: get item id
3: show item details
4: calculate bill
5: bill payment
6: get credit card number
7: verify validation
8: valid
9: validation ok
10: generate report

NAME: T. JAHNAVI
ROLL NO: 1220609110
Process sale collaboration diagram
1 : E n te r n o o f i te m s
5 : b i ll p a y m e n t 2 : g e t ite m id
C a s h ie r PO S C odescan
S y s te m ner
4 : c a lc u la t e b i ll 3 : s h o w i t e m d e t a i ls
1 0 : g e n e r a te r e p o r t
6 : g e t c re d it c a rd n u m b e r
9 : v a li d a t i o n o k
7 : v e r i f y v a li d a t i o n
C a rd B a nk
re a d e r
8 : v a li d

NAME: T. JAHNAVI
ROLL NO: 1220609110
POS system activity diagram

NAME: T. JAHNAVI
ROLL NO: 1220609110
C u s to m e r C a s h ie r B a rc o d e re a d e r p o s s y s te m
e n te rs th e
shop
s e le c t p r e p a r e i t e m s c a n i t e m s b i ll
p ro d u c t li s t g e n e ra tio n
p a y t h e b i ll p r o c e s s b i ll

NAME: T. JAHNAVI
ROLL NO: 1220609110
Component Diagram
Point of
scale
RESULT:
Thus various UML Diagrams were generated for POINT OF SALE

SYSTEM and the corresponding code was generated using Visual Basic.

NAME: T. JAHNAVI
ROLL NO: 1220609110
ONLINE BOOK SHOP SYSTEM

NAME: T. JAHNAVI
ROLL NO: 1220609110
ONLINE BOOK SHOP SYSTEM
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
Functionality:

NAME: T. JAHNAVI
ROLL NO: 1220609110
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

NAME: T. JAHNAVI
ROLL NO: 1220609110
logging on to the system, browsing the book store, selecting items and
making purchases i.e., the 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 and Book shop staff

NAME: T. JAHNAVI
ROLL NO: 1220609110
USE CASES:
• Registration
• Login
• Create order
• Book catalog
• Manage cart and payments
• Order status
• Inventory
RELATIONSHIPS USED:
• Association
• Dependency
• Composition
1. Draw the lines around the system and actors lie outside
the system.
Identify the actors which are interacting with the
system.
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.
6. Se the relatonship 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.
1. Set the context for the interactions, system, subsystem,

classes, object or use cases.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.

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

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
1. Choose the context for state machine,whether it is a class,

a use case, or the system as a whole.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
1. Identity the things that are interacting with class diagram.

4. Identify the generalization and specification classes.
1. Identify the mechanisms which you would like to model.

2. Identify the classes, use cases, interface, subsystem which
are collaborated with mechanisms.
4. Walk through the scenario until to reach the certain point
and identify the objects at that point.
1. Identify the component libraries and executable files which

are interacting with the system.
2. Represent this executables and libraries as components.
4. Identify the files, tables, documents which are interacting
with the system.

NAME: T. JAHNAVI
ROLL NO: 1220609110
5. Represent files,tables,documents as components.
6. Show the existing relationships among them generally
dependency.
system.
9. Set attributes and operation signatures for interfaces.
10.Use either import or export relationship in b/w interfaces &
components.
system.
12.Set the version of the source code as a constraint to each
source code.
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.
6. Specify the components which are living on nodes.
7. Adorn with nodes & constraints & draw the deployment
diagram.
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 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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
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
3. Bookshop
4. Item
PACKAGE-2: CUSTOMER
1. Customer
2. Address

NAME: T. JAHNAVI
ROLL NO: 1220609110
3. Billing Address
4. Shipping Address
PACKAGE -3:ONLINE ORDERING

1. Order
2. Item Order
3. Shopping Cart
CLASS DIAGRAM:

NAME: T. JAHNAVI
ROLL NO: 1220609110
USE CASE DIAGRAM FOR ONLINE BOOKSHOP SYSTEM:

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
c u s to m e r r e g i s tr a ti o n lo g i n c r e a te o r d eb ro o k c a t a lo gin v e n to r y b o o k s h o p c a rt s h i p p m e n t p a y m e n t c o n s o r ti n u md a ta b a s e
s t a ff d e t a i ls
1 : lo g i n r e q u e s t
2: m anag es
3 : u p d a te s
4 : u p d a te
5 : v e r i fy
6 : r e g i s te r f i r s t
7 : r e g i s te r e d lo g o n r e q u e s t
8 : v e r i fy
9 : lo g o n s u c c e s s fu l
1 0 : c re a t e o r d e r
1 1 : s e le c t b o o k s
1 2 : v e r if y
1 3 : s to c k o k
1 4 : c o n f i r m s e le c ti o n
1 5 : a d d t o c a rt
1 6 : s h i p p m e n t d e ta i ls
1 7 : p a ym e n t
1 8 : d e liv e r e d s u c c e s s f u lly
COLLOBORATION DIAGRAM:

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
5: verify 11: select books

login create book
registrat
order catalog
ion
10: create order 15: add to cart

1: login request
7: registered logon request payme
6: register first nt
4: update
12: verify
cart 8: verify shippment consorti
details num
16: shippment details
17: payment
bookshop
custom staff
er
18: delivered successfully
3: updates
9: logon successful
13: stock ok
databa 14: confirm selection

se 2: manages invent
ory

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
s e le c ti o n s
v a li d lo g i n s e le c t cho o se
c r e a te c o n fi r m
m a in s c re e n b ro w s e li s te d b o o k s
s c re e n o rd e r
i n c a ta lo g
tra n s a c ti o n s u c c e s s d i s p la y th a n k u s c r e e n
a d d to
s e a r c h b y a u th o r,ti tle ,i s b n
ca nce l
r e tu r n to c a n 't fi n d
w a i t fo r c a rt
r e s u lt
c a n c e ls w a i t fo r
v i e w d e ta i ls
v i e w s h i p p i n g d e ta i ls
n o t s a ti s fi e d
i n v a li d tr a n s a c ti o n
w a i t fo r
tra n s a c ti o n d e ta i ls
ACTIVITY DIAGRAM:
An activity diagram is essentially a fancy flowchart. Activity

diagrams and state chart diagrams are related. While a state chart

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
display
welcome msg
get login
get pwd rejected

and validate
accepted display item

info
accept
selection more selections
completed
display create order
order for cart
acceptance rejected
ship to
customer
COMPONENT DIAGRAM:

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
address.ja order.java
va
book.java
central server.java
bokshop.java
address.cl bookstaff.java
ass
central
server.class/.dll item.java
item.class order.class
book.class
central
database
bookshop.
class
address.db order.db
bookstaff.c
lass
books.db
items.db
DEPLOYMENT DIAGRAM:

NAME: T. JAHNAVI
ROLL NO: 1220609110
Deployment diagram shows the physical configurations of

software and hardware.

NAME: T. JAHNAVI
ROLL NO: 1220609110
RESULT:
Thus various UML Diagrams were generated for ONLINE BOOK SHOP
and the corresponding code was generated using Visual Basic.

NAME: T. JAHNAVI
ROLL NO: 1220609110
AN ONLINE AUCTION SALE

NAME: T. JAHNAVI
ROLL NO: 1220609110
AN ONLINE AUCTION SALE
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
As per case study, the 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 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:

NAME: T. JAHNAVI
ROLL NO: 1220609110
• 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

NAME: T. JAHNAVI
ROLL NO: 1220609110
8. Register for goods
9. Select history of database
Use Cases In Purchaser’s Diagram:
1. Validate User
2. Record chatting.
ALGORITHMIC PROCEDURE:

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
DIAGRAMS:

NAME: T. JAHNAVI
ROLL NO: 1220609110
the system.
2. Identify the actors which are interacting with the system.
cases.
7. Se the relationship among the use cases and in between

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.
5. Start the message which is initiating interactions and place
all other messages in the increasing order of items.

NAME: T. JAHNAVI
ROLL NO: 1220609110

or collaboration.
needed
formally.

of final state.
activity diagram.

NAME: T. JAHNAVI
ROLL NO: 1220609110
action states.
7. Start with sequential flows, consider branching, fork and
joining.

their responses.
1. Identity the things that are interacting with class

diagram.

NAME: T. JAHNAVI
ROLL NO: 1220609110
4. Identify the generalization and specification
classes.
1. Identify the mechanisms which you would like to

model.
2. Identify the classes, use cases, interface,
subsystem which are collaborated with
mechanisms.
4. Walk through the scenario until to reach the
certain point and identify the objects at that
point.
1. Identify the component libraries and executable files

which are interacting with the system.
2. Represent this executables and libraries as
components.
4. Identify the files, tables, documents which are
interacting with the system.

NAME: T. JAHNAVI
ROLL NO: 1220609110
6. Show the existing relationships among them
generally dependency.
system.
9. Set attributes and operation signatures for
interfaces.
10.Use either import or export relationship in b/w
interfaces & components.
system.
12.Set the version of the source code as a constraint to
each source code.

diagram.

NAME: T. JAHNAVI
ROLL NO: 1220609110
Class Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
c u s to m e r(b id d e r)
s it e nam e
nam e c o n t a c t i n fo
l i s t O fA v a i l a b l e P r o d u c t s a d d re s s
l i s t O fP r i c e s
webHost lo g o n t o t h e s ite ()
s e a r c h fo r t h e r e q u i r e d p r o d u c t ( )
u p d a t e t h e s it e w it h p ro d u c t s () b i d fo r p r o d u c t ( )
s e ll t h e p ro d u c t s ( ) p a y t h e p ric e ()
p ro d u c t
a u c tio n e r
id
nam e id
ty p e
c u rre n tB id d in g P ric e s e n d T h e D e t a l i s O fP r o d u c t s T o B i d d e r ( )
u p d a t e T h e B id d in g P r ic e ( )
fi n a l C u t O ff P r i c e ( ) s e llT h e P r o d u c t ()
p ro d u c t () g e t T h e P r ic e p a id ()
a u c tio n e r()

NAME: T. JAHNAVI
ROLL NO: 1220609110
Use case Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
login
s earc h for produc t
reques t/s end details
B Idder
A uc tioner
bid the produc t
buy/s ell the produc t
pay the pric e
deliver the produc t

NAME: T. JAHNAVI
ROLL NO: 1220609110
Sequence diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
s :s ite a:auc tioner p:produc t
: B Idder
login
s earc h
reques t produc t details
get details
dis play details
pay final pric e or bid for produc t
update bid pric e
c hec k for produc t
give ac k n if s uitable for s elling
buy the produc t
pay pric e
logout

NAME: T. JAHNAVI
ROLL NO: 1220609110
Collaboration Diagram:
s :s ite
1 : lo g in
1 2 : lo g o u t
8 : c h e c k fo r p ro d u c t
2 : s e a rc h
p :p ro d u c t
5 : d is p la y d e t a ils
: B Id d e r 9 : g ive a c k n i f s u i t a b le fo r s e lli n g
4 : g e t d e t a il s
3 : re q u e s t p ro d u c t d e t a il s
6 : p a y fi n a l p r ic e o r b i d fo r p r o d u c t
7 : u p d a t e b i d p ri c e
1 0 : b u y t h e p ro d u c t
1 1 : p a y p ri c e
a : a u c t io n e
r

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
ActivityDiagram:
log on to the
site
search for the

product
request details
bid the final price and if final fixed price bid for the
buy the product yes suitable no product
check for the

cutoff price
wait for the if suitable for

next bid no selling
sell/buy the
product
pay the price

NAME: T. JAHNAVI
ROLL NO: 1220609110
State chart diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
requested product details

wait for wait for the
request desicion
Bid the price
wait to update
bid price
bid for a higher price
wait for bid price wait until next

to meet cut off compare the bidding price with cutoff bid comes
sell / but the product
wait for
payment

NAME: T. JAHNAVI
ROLL NO: 1220609110
COMPONENT DIAGRAM:

NAME: T. JAHNAVI
ROLL NO: 1220609110
nam e
lis t o f p ric e s
c e n tra l
s e rve r ja va
web hos t
c e n tra l s e rve r s it e
c la s s
c u s to m e r
C e n tra l
d a ta b a s e
p ro d u c t. d b

NAME: T. JAHNAVI
ROLL NO: 1220609110
AN AIRPORT SIMULATION

NAME: T. JAHNAVI
ROLL NO: 1220609110
A Multi- Threaded Airport Simulation
Aim: to create a Multi- Threaded Airport Simulation
Actors:
ATC Controller
Use Cases
1. ATC Controller
2. Decision Support System
3. Planning
4. Emergency
5. Sensor
6. Gateway
7. Runway
8. Terminal
9. Available
10.Waiting Queue
Algorithmic Procedure:

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

NAME: T. JAHNAVI
ROLL NO: 1220609110
Overview
A critical step of the project is to design a modeling and

simulation infrastructure to experiment and validate the proposed
solutions
The ever growing demand of air transport shows the
vulnerability of the current air traffic management system:
Congestion, time delays, etc.particularly in poor whether 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
whether 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;

NAME: T. JAHNAVI
ROLL NO: 1220609110
• All take offs 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 take off at random times, but with a specified
probability of a plane arriving during any given minute
• 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:

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
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. Technical head: He is the person who supervises the controls
the ground traffic on runway. He checks the status of runways
and assigns the free runways and terminals for takeoff and
landing.
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.
• Transmit/receive signals.
• Check availability of runways.

NAME: T. JAHNAVI
ROLL NO: 1220609110
• Land the plane.
• Check if time left for next departure.
• Check for free terminal.
• Update status of runway, terminal.
1. Transmit/receive signals: 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 availability of 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. Land the plane: The plane is landed safely on the airport as per
directions given by the control room regarding runway and
timings.
4. Check if time left for next departure: If the plane leaves
immediately after landing then assign again a runway for
takeoff. If there is still time then the plane has to be parked in a
terminal.
5. Check availability of terminals: the status of each terminal is
to be checked to find a free terminal. It should be checked
whether that particular model of plane fits into that terminal.
Then that particular terminal has to be assigned to the plane.
6. Update Status: the status of runway and terminal are to be set
to be using while using them. The status has to be immediately
changed as soon as the work is complete. This should be
supervised carefully to avoid collisions and crashes of aircrafts.
Classes:
The classes contain the attributes and operations related to them
the main classes classified in this solution are:
1. Control Room: he is the person who supervises the controls the
ground traffic on runway. He checks the status of runways and
assigns the free runways and terminals for takeoff and landing.

NAME: T. JAHNAVI
ROLL NO: 1220609110
2. Plane Cockpit: He is the person who controls the aircraft. He
transmits or receives signals regarding the free runways and
terminals from the control room. He is responsible for the safe
landing or takeoff of the plane.
3. Runway: This is the part the planes use to land or takeoff only
one plane can use runway at a time to takeoff or land.
4. Terminal: This is the place where the planes are parked until
the next departure. The terminal is to be parked in it.
5. Takeoff/land: The leaving of planes is called takeoff and
coming back to runway is called landing. The runway is used for
either purpose.
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 attributes,
delegate responsibilities to other classes and implement abstract
interfaces.
Classes of airport simulation are:
Class Attributes Operations
Control Room -Technical head +Receive signals from
-No of staff planes()
-systems to control +Check for free
runway()
+Send runway no()
+Check for next
departure()
+Look for free
terminal()
+Send terminal no to
plane()
+Get plane parked()
Takeoff/Landing -Runway no +Update status of
-Flight no runway after each take
-Status of or landing()
-Time taken

NAME: T. JAHNAVI
ROLL NO: 1220609110
Plane Cockpit -No of pilots +Send signal to ground
-Flight no station()
-Destination +Receive runway no()
-Timings +Land on runway()
+Request terminal if
time left for next
departure()
+Receive terminal no()
+Get the plane parked
in the terminal()
Terminal -No of runways
-Size of terminal -------------------
-Flight model which ------
fits in
-Status of terminal
Runway -No of runways +Update status of
-Length of runway runway after each
Status of runway takeoff/landing()
-Free timings
-Runway no
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.
Actors Use cases
Technical head .Transmit/Receive signals
.Look for free runway

NAME: T. JAHNAVI
ROLL NO: 1220609110
.Check whether conditions
.Give directions to aircraft
.Look for free terminal
.Get the plane parked in the free
Terminal pilot .Transmit/Receive signals
.Land or takeoff the plane
Safely .Give acknowledgment about
the timings to control
Terminal .Get the plane into the free
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.
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. Runway: This is the path the plane uses to land or takeoff.
Only one plane can use a runway at a time takeoff or
landing.

NAME: T. JAHNAVI
ROLL NO: 1220609110
2. Takeoff/Landing: The leaving of plane is called takeoff and
coming back to runway is called landing. The runway is used
for either purpose.
3. Whether Conditions: The whether department decodes the
atmospheric data files from the current whether conditions
and sends them to the control room. The systems in the
control room checks whether the condition is suitable for
landing the planes.
4. Terminal: This is the place where the planes are parked until
the next departure. The terminal differs in size and shape.
The plane suitable for that particular terminal is to be parked
in it.
5. Cockpit: He is the person who controls the aircraft. He
transmits or receives signals regarding the free runways and
terminal fro the control room. He is responsible for the safe
landing or takeoff of the planes.
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

NAME: T. JAHNAVI
ROLL NO: 1220609110
activity. A single transaction comes out of each activity, connecting it
to the next activity.
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.
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
Class Diagram:
A i r p o rt S i m u la ti o n
C o n tr o l- C o c k p i t
C o n tr o lR o o m F lig h t N o : In t e g e r
N o O fS t a ff : In t e g e r N o o f p ilo t s : In t e g e r
S y s t e m s T o C o n t ro l : S t ri n g 1 t im in g s : In t e g e r
t e c h n ic a l H e a d : S t r in g
if t im e le ft t o w a i t s e n d s m e s s a g e t o c o n t r o l r o o m ()
C h e c k fo r fre e ru n w a y () la n d s o n t h e r u n w a y ()
C h e c k fo r fre e t e rm in a l() p la n e is t a k e n t o fre e t e r m in a l ()
C h e c k fo r t im e fo r n e x t d e p a t u re ( ) r e c ie ve s r u n w a y n o t o la n d ( )
s e n d s s ig n a l fo r la n d in g t o g ro u n d c o n t r o l()
1 ..*
1
T e rm in a l
F r e e T im m in g s : In t e g e r
m o d e lN o O fA irc ra ft W h ic h It S u it a b le : In t e g e r < < In t e rfa c e > > < < in t e rfa c e > >
la n d i n g T a k e O ff
n o O fF r e e T e r m in a l()
a t t ri b u t e a t t ri b u t e
s iz e O fT e r m i n a l ()
c h a n g e S t a t u s O fR u n w a y A ft e r L a n dcinh ga ()
n g e S t a tu s O fR u n w a y A ft e rA ln d in g ( )
1 1
W e a th e r D e p t 1
H e a d : S t rin g R unW a y
F re e T i m in g s : In t e g e r
C h e c k W e a t h e rC o n d it io n s () L e n g t h O fR u n w a y : In t e g e r
S e n d W e a t h e rR e p o rt () n o O fR u n w a y : In t e g e r
W e a t h e rD e p t ()
U p d a t e S t a t u s A ft e rE a c h T a k e O ffO rL a n d in g ( )
R u n W a y ()

NAME: T. JAHNAVI
ROLL NO: 1220609110
Use Case Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
send/receive signal
check availability of run awy
send/receive run way num
land / aircraft
send / receive terminals

numbers Plane cockpit
Control room
check free terminals
send / receive terminal

numbers
park aircraft
update status of runway

NAME: T. JAHNAVI
ROLL NO: 1220609110
Sequence Diagram:
A i rp o rt S im u la ti o n
p :p ra n e T :te rm in a l R :ru n w a y W :W e a th e rD
: c o n tro l ro o m
C o c k p it ept
1 : re q u e s t s i g n a l
2 : s e n d s ig n a l
3 : C h e c k W e a th e r c o n d itio n s
4 : s e n d a c k n o w le d g e m e n t
5 : c h e c k a va li a b le fo r r u n w a y
6 : w a it s i g n a l
8 : s e nd a ck
9 : u p d a te ru n w a y s ta tu s
1 0 : i f ti m e i s fo r n e x t d e p s e n d re q
1 1 : i f te r m in a l i s fre e s e n d te rm in a l n o
1 2 : s e n d te rm i n a l
1 3 : la n d a irc ra ft
1 4 : u p d a te s ta tu s o f te r m in a l

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
p :p ra n e
C o c k p it 1 0 : i f ti m e i s fo r n e x t d e p s e n d re q
1 : re q u e s t s i g n a l
1 1 : i f te r m in a l i s fre e s e n d te rm in a l n o
6 : w a it s i g n a l
7 : s e n d s ig n a l 1 4 : u p d a te s ta tu s o f te rm in a l
8 : se nd a ck
1 2 : s e n d te rm in a l
1 3 : la n d a irc ra ft
: c o n tr o l ro o m T :te r m in
al
5 : c h e c k a v a li a b le fo r ru n w a y
9 : u p d a te ru n w a y s ta tu s
4 : s e n d a c k n o w le d g e m e n t
R :r u n w a
y 3 : C h e c k W e a th e r c o n d itio n s
W :W e a th e r
D ept

NAME: T. JAHNAVI
ROLL NO: 1220609110
Activity Diagram:
Runway allocation for takeoff Activity Diagram

NAME: T. JAHNAVI
ROLL NO: 1220609110
la nding
give aircraft
info to lock s/m
lock syste m
checking for ks
no all locks a re locked

yes
acquire la nding prio rity
area lock
acquire
runway lock la nding on
another runway
aircraft at acquire
take off area termina l lock
if the aircraft is at takeoff area then

release termina l a nd taxiing locks acquire
while moving from takeoff a rea taxiing lock
release takeoff a rea lock and acquire
runway lock
move to the terminal gate and
release term inal and taxiing
lo ck
Runway allocation for takeoff Activity Diagram

NAME: T. JAHNAVI
ROLL NO: 1220609110
takeoff
acquire terminal lock
give aircraft
info to lock s/m
checks
for locks
if locks are available
acquire takeoff
area lock
acquire
taxiing lock
aircraft at acquire
takeoff area runway lock
use the runway for takeoff and release

if the aircraft is at the takeoff runway lock
area then release terminal and
taxiing lock while moving from
takeoff area release takeoff area
lock and acquire runway lock

NAME: T. JAHNAVI
ROLL NO: 1220609110
State Chart Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
w a it fo r w e a the r re q runw a y s ta tus w a it fo r

c o nd itio ns run nin g s ta tu s
re q ru nw a y n o
w a it fo r
ru nw a y n o
a va il n o t a va il
w a it fo r te rm ina l if tim e le ft la nd o n
s ta tus ru n w a y
a va il
no t a va il
w a it fo r
te rm ina l n o
n o t a va il
a va il
h a lt

NAME: T. JAHNAVI
ROLL NO: 1220609110
Component Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
terminal
lock.java
central
landing.jav
server java
a
takeofflock
.java
taxiinglock.
central server java
.class / .dll
terminalloc
k.class
landing.cla
ss
takeofflock
.class
taxiinglock.
class
airport.db
central
database
priority.db

NAME: T. JAHNAVI
ROLL NO: 1220609110
Deployment Diagram:
<<DATA BASE>>
central database
<<SERVER>>
central server
<<WIRELESS COMMUNICATION>>
<<DEVICE>>
<<DEVICE>> <<DEVICE>> <<DEVICE>> control manager
aircarft controlor lockmanager taxiing
manager

NAME: T. JAHNAVI
ROLL NO: 1220609110
Result:
The various UML diagrams were drawn for AIRPORT
SIMULATION SYSTEM application and the corresponding code was
generated.

NAME: T. JAHNAVI
ROLL NO: 1220609110
A SIMULATED COMPANY

NAME: T. JAHNAVI
ROLL NO: 1220609110
A SIMULATED COMPANY
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.

NAME: T. JAHNAVI
ROLL NO: 1220609110
○ Usecase for the system
○ Class diagram for initially identified classes.
○ Activity diagram to show flow for each use case.
○ Sequence and collaboration diagrams.
○ Statechart diagram shows states before and after each action.
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 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:

NAME: T. JAHNAVI
ROLL NO: 1220609110
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.
the system.
2. Identify the actors which are interacting with the system.
cases.
7. Se the relationship among the use cases and in between


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.
5. Start the message which is initiating interactions and place
all other messages in the increasing order of items.

NAME: T. JAHNAVI
ROLL NO: 1220609110
Set the pre and post conditioned.

or collaboration.
needed
formally.


NAME: T. JAHNAVI
ROLL NO: 1220609110
of final state.
activity diagram.
action states.
7. Start with sequential flows, consider branching, fork and
joining.

7. Consider ways to simplify your machine by using sub
states, branches, forks, joins and history states.
their responses.

NAME: T. JAHNAVI
ROLL NO: 1220609110
1. Identity the things that are interacting with class diagram.

4. Identify the generalization and specification classes.

1. Identify the mechanisms which you would like to model.
2. Identify the classes, use cases, interface, subsystem which
are collaborated with mechanisms.
4. Walk through the scenario until to reach the certain point
and identify the objects at that point.
1. Identify the component libraries and executable files which

are interacting with the system.
2. Represent this executables and libraries as components.
4. Identify the files, tables, documents which are interacting
with the system.
6. Show the existing relationships among them generally
dependency.
system.
9. Set attributes and operation signatures for interfaces.
10.Use either import or export relationship in b/w interfaces &
components.

NAME: T. JAHNAVI
ROLL NO: 1220609110
system.
12.Set the version of the source code as a constraint to each
source code.

diagram.

NAME: T. JAHNAVI
ROLL NO: 1220609110
Class Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
Use Case Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
Sequence Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
Activity Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110

NAME: T. JAHNAVI
ROLL NO: 1220609110
State Chart Diagram:

NAME: T. JAHNAVI
ROLL NO: 1220609110
Component Diagram
<<Application>>
Simulated
company
RESULT:
Thus various UML Diagrams were generated for SIMULATED
COMPANY and the corresponding code was generated using Visual
Basic.

NAME: T. JAHNAVI
ROLL NO: 1220609110

Uml Lab Manual

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Uml Lab Manual

Diunggah oleh

Hak Cipta:

Format Tersedia

GITAM INSTITUTE OF TECHNOLOGY

UNIFIED MODELING LANGUAGE Page no:

UNIFIED MODELING LANGUAGE Page no:

A class is a blueprint or prototype from which objects are

UNIFIED MODELING LANGUAGE Page no:

possible dogs by listing the characteristics and behaviors they can

OBJECT ORIENTATION CONCEPTS:

UNIFIED MODELING LANGUAGE Page no:

The reason for encapsulation is to prevent clients of an interface

For example, the class Dog might have sub-classes called

UNIFIED MODELING LANGUAGE Page no:

bark () method produces a high pitch by default. Subclasses can also

Multiple inheritances are inheritance from more than one

UNIFIED MODELING LANGUAGE Page no:

Why is UML important?

Writing software is not unlike constructing a building. The more

UNIFIED MODELING LANGUAGE Page no:

The UML is applicable to object-oriented problem solving.

Classes are the "blueprints" for objects. A class wraps attributes

Use case diagrams:

Use case diagrams describe what a system does from the

Use case diagrams are closely connected to scenarios. A scenario is

UNIFIED MODELING LANGUAGE Page no:

A use case is a summary of scenarios for a single task or goal.

Actors are stick figures. Use cases are ovals. Communications

A use case diagram is a collection of actors, use cases, and their

UNIFIED MODELING LANGUAGE Page no:

Use case diagrams are helpful in three areas.

• Determining features (requirements). New use cases often

• Communicating with clients. Their notational simplicity makes

• Generating test cases. The collection of scenarios for a use

A Class diagram gives an overview of a system by showing its

UNIFIED MODELING LANGUAGE Page no:

The class diagrams below models a customer order from a retail

Our class diagram has three kinds of relationships.

UNIFIED MODELING LANGUAGE Page no:

• Perform its work. In a diagram, an association is a link

• Aggregation -- an association in which one class belongs to a

• Generalization -- an inheritance link indicating one class is a

An association has two ends. An end may have a role name to

A navigability arrow on an association shows which direction the

UNIFIED MODELING LANGUAGE Page no:

Every class diagram has classes, associations, and multiplicities.

Packages and object diagrams

To simplify complex class diagrams, you can group classes into

UNIFIED MODELING LANGUAGE Page no:

Packages appear as rectangles with small tabs at the top. The

Object diagrams show instances instead of classes. They are

This small class diagram shows that a university Department can

UNIFIED MODELING LANGUAGE Page no:

The object diagram below instantiates the class diagram, replacing it

Each rectangle in the object diagram corresponds to a single

Class and object diagrams are static model views. Interaction

UNIFIED MODELING LANGUAGE Page no:

Below is a sequence diagram for making a hotel reservation. The

The Reservation window sends a make Reservation ()

UNIFIED MODELING LANGUAGE Page no:

In our diagram, the Hotel issues a self call to determine if a

Collaboration diagrams are also interaction diagrams. They

Convey the same information as sequence diagrams, but they

UNIFIED MODELING LANGUAGE Page no:

The object-role rectangles are labeled with either class or object

Each message in a collaboration diagram has a sequence