Uml Lab

UML INTRODUCTION
UNIFIED MODELING LANGUAGE
Page no:
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
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
Page no:
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.
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
Page no:
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:
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 typespecific 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:
Page no:
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 inherits all the (multiple) behavior of cats and dogs.
This is not always supported, as it can be hard to implement
Page no:
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
Page no:
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.
"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
Page no:
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 with four
actors and four use cases. Notice that a single use case can have multiple actors.
Page no:
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.
Page no:
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.
Page no:
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 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 indicates n to m
0..1
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.
Page no:
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.
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.
Page no:
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.
Sequence diagrams
Class and object diagrams are static model views. Interaction diagrams
are dynamic. They describe how objects collaborate.
Page no:
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
Reservation
and
Confirmation.
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
Page no:
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.
Page no:
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 toplevel 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.
Page no:
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.
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
Page no:
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.
Page no:
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.
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.
Page no:
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.
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.
Page no:
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.
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.
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.
Page no:
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

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.
Page no:
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.
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.
Page no:
8.
Consider
ways
to
simplify
your
machine
by
using
under
some
substates, branches, forks, joins and history states.

9.
Check
that
all
states
are
reachable
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 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

Page no:
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.
Page no:
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 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
Page no:
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 models 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 models 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
Page no:
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.
Point of Sale System
Page no:
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
Page no:
Class diagram:
Page no:
Page no:
Use Case Diagram :
Buy product
Barcode scanning
Pay bill
Customer
Cashier
Process sale
Close sale
Update Inventory
Tax calculation
Page no:
POS system sequence diagram
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
Page no:
Process sale sequence diagram
Cashier
POS System
Codescanne
r
Card reader
Bank
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
Process sale collaboration diagram

Page no:
1: Enter no of items
5: bill payment
Cashier
2: get item id
POS
System
4: calculate bill
10: generate report
Codescan
ner
3: show item details
6: get credit card number
9: validation ok
7: verify validation
Card
reader
Bank
8: valid
Page no:
POS system activity diagram
Customer
Cashier
Barcode reader
pos system
select
product
prepare item
list
scan items
bill
generation
pay the bill
process bill
enters the
shop
Page no:
Component Diagram
Point of
scale
Component diagram represents a software module with a well defined interface.
The interface of a component is represented by one or several interface
components or elements that the component provides.
DEPLOYMENT DIAGRAM:
<<server>>
POSSystem
<<database>>
POSDB
<<device>>
Customers
RESULT:
Thus various UML Diagrams were generated for POINT OF SALE SYSTEM and the
corresponding code was generated.
Forward and Reverse engineering can also be performed.
Page no:
ONLINE BOOK SHOP SYSTEM
Page no:
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:
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
Page no:
Brief Description of the Project:

The current project emphasizes on analysis and design of an online
bookshop system. That serves the customers needs. The customers 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 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.
Page no:
ACTORS: Customer and Book shop staff

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.
2. Separate the generalized and specialized actors.
3. Identify the functionality the way of interacting actors with system and
specify the behavior of actor.
6. Se the relatonship among the use cases and in between actor and use
cases.
Adorn with constraints and notes.
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.
Page no:
7. Set the pre and post conditioned.

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

1. Choose the context for state machine,whether it is a class, a use case,
or the system as a whole.
Page no:
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.
10.Trace through the state machine, either manually or by using tools, to
check it against expected sequence of events & their responses.
1.
2.
3.
4.
5.
6.
Identity the things that are interacting with class diagram.

Set the attributes and operations.
Set the responsibilities.
Identify the generalization and specification classes.
Set the relationship among all the things.
Adorn with tagged values, constraints and notes.

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.
Page no:
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.
1.
2.
3.
4.
5.
6.
7.
Identify the processors which represent client & server.

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 specificationan 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
Page no:
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
3. Billing Address
4. Shipping Address
PACKAGE -3:ONLINE ORDERING

1. Order
2. Item Order
3. Shopping Cart
Page no:
CLASS DIAGRAM:
Page no:
USE CASE DIAGRAM FOR ONLINE BOOKSHOP SYSTEM:
Page no:
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.
customer
registration
login
create order
book catalog
inventory
bookshop
staff
cart
shippment
details
payment
consortinum
1: login request
2: manages
3: updates
4: update
5: verify
6: register first
7: registered logon request
8: verify
9: logon successful
10: create order
11: select books
12: verify
13: stock ok
14: confirm selection
15: add to cart
16: shippment details
17: payment
18: delivered successfully
Page no:
database
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.
registrat
ion
login
5: verify
create
order
10: create order
11: select books

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

2: manages
invent
ory
Page no:
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.
selections
select
valid login
mainscreen
choose
create
order
browse
screen
transaction success display thank u screen

search by author,title,isbn
return to
listed books
in catalog
add to
cancel
wait for
view details
not satisfied
invalid transaction
can't find
cart
wait for
result
cancels
confirm
view shipping details
wait for
transaction details
Page no:
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.
display
welcome msg
get login
get pwd
and validate
accepted
rejected
display item
info
accept
selection
more selections
completed
display
order
acceptance
create order
for cart
rejected
ship to
customer
Page no:
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.
order.java
address.ja
va
book.java
central server.java
address.cl
ass
central
server.class/.dll
item.class
central
database
address.db
order.db
bokshop.java
bookstaff.java
item.java
order.class
book.class
bookshop.
class
bookstaff.c
lass
books.db
items.db
Page no:
DEPLOYMENT DIAGRAM:
Deployment diagram shows the physical configurations of software and
hardware.
Page no:
RESULT:
Thus various UML Diagrams were generated for ONLINE BOOK SHOP and the
corresponding code was generated.
Page no:
AN ONLINE AUCTION SALE
Page no:
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 its 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.
1.
2.
3.
4.
5.
Use cases for the system.

Class diagram for initially identified classes.
Activity diagram to show flow of each use case.
Sequence and collaboration diagrams.
State chart diagram shows states before and after
each action.
Conceptualization:
Assumptions:
The users are allowed to register and give user ids to have identification.
The users are allowed to bid for any price according to their wish provided
its 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.
Page no:
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:
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
Page no:
Use Cases in Auction System

1.
2.
3.
4.
5.
6.
7.
8.
9.
Login
Seller
Purchaser
Chatting
Select Method of bidding
Select Method of Auction
Buy Goods
Register for goods
Select history of database
Use Cases In Purchasers Diagram:

1. Validate User
2. Record chatting.
ALGORITHMIC PROCEDURE:
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:
1.
2.
3.
4.
Draw the lines around the system and actors lie outside the system.
Separate the generalized and specialized actors.
Identify the functionality the way of interacting actors with system and
Page no:

7. Se the relationship among the use cases and in between actor and use
cases.
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.
7. Set the pre and post conditioned.

objects to outside.
stereotypes.
appropriate.
Page no:

state.
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,
7. Consider ways to simplify your machine by using substates, branches,

1. Identity the things that are interacting with class diagram.
Page no:
2.
3.
4.
5.
6.


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.

4. Identify the files, tables, documents which are interacting with
the system.
6. Show the existing relationships among them generally
dependency.
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.
Page no:

1.
2.
3.
4.
5.
6.
7.

Class Diagram:
Page no:
customer(bidder)
site
name
listOfAvailableProducts
listOfPrices
webHost
update the site with products()
sell the products()
name
contact info
address
logon to the site()
search for the required product()
bid forproduct()
pay the price()
product
id
name
type
currentBiddingPrice
finalCutOffPrice()
product()
auctioner
id
sendTheDetalisOfProductsToBidder()
updateTheBiddingPrice()
sellTheProduct()
getThePricepaid()
auctioner()
Use case Diagram:

Page no:
login
search for product
request/send details
BIdder
Auctioner
bid the product
buy/sell the product
pay the price
deliver the product
Sequence diagram:
Page no:
s:site
a:auctioner
p:product
: BIdder
login
search
request product details

get details
display details
pay final price or bid for product
update bid price
check for product
give ackn if suitable for selling

buy the product
pay price
logout
Collaboration Diagram:
Page no:
s:site
1: login
12: logout
8: check for product
2: search
p:product
5: display details
9: give ackn if suitable for selling
: BIdder
4: get details
3: request product details
6: pay final price or bid for product
7: update bid price
10: buy the product
11: pay price
a:auctione
r
Page no:
ActivityDiagram:
log on to the
site
search for the

product
request details
bid the final price and

buy the product
yes
if final fixed price

suitable
no
bid for the

product
check for the

cutoff price
wait for the
next bid
no
if suitable for
selling
sell/buy the
product
pay the price
State chart diagram:

Page no:
wait for
request
requested product details
wait for the

desicion
Bid the price
wait to update
bid price
bid for a higher price
wait for bid price

to meet cut off
compare the bidding price with cutoff
wait until next

bid comes
sell / but the product

wait for
payment
Page no:
COMPONENT DIAGRAM:
name
list of prices
central
server java
web host
central server
class
site
customer
Central
database
product.db
Page no:
Deployment diagram:
A deployment diagram shows the physical configurations of software and
hardware.
Dtabase
Server
<<device>>
Customer 1
<<device>>
Customer n
Result:
Thus various UML diagrams were generated for AN ONLINE AUCTION SALE and
corresponding code was generated .
.
Page no:
AN AIRPORT SIMULATION
Page no:
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:
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
Page no:
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;
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.
Page no:
The
The
The
The
The
probability of a plane entering the landing queue in any given minute.

probability of a plane entering the takeoff queue in any given minute.
maximum minutes until a plane waiting to land will crash.
statues of each runway, plane and terminal.
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.
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.
Page no:
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.
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 its 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:
Page no:
1. Control Room: he is the person who supervises the controls the ground
2.
3.
4.
5.
traffic on runway. He checks the status of runways and assigns the free
runways and terminals for takeoff and landing.
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.
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.
Terminal: This is the place where the planes are parked until the next
departure. The terminal is to be parked in it.
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 specificationan 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
Plane Cockpit
-No of pilots
+Send signal to ground
-Flight no
station()
-Destination
+Receive runway no()
-Timings
+Land on runway()
+Request terminal if
Page no:
time
left
for
next
departure()
+Receive terminal no()
+Get the plane parked
in the terminal()
Terminal
Runway
-No of runways
-Size of terminal
-Flight model which fits ------------------------in
-Status of terminal
-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
.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
Page no:
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.
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
Page no:
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
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.
Class Diagram:
Page no:
Airport Simulation
Control-Cockpit
ControlRoom
NoOfStaff : Integer
SystemsToControl : String
technicalHead : String
Check for free runway()

Check for free terminal()
Check for time for next depature()
Flight No : Integer
No of pilots : Integer
timings : Integer
if time left to wait sends message to control room()
lands on the runway()
plane is taken to free terminal()
recieves runway no to land()
sends signal for landing to ground control()
1..*
Terminal
FreeTimmings : Integer
modelNoOfAircraftWhichItSuitable : Integer
<<Interface>>
<<interface>>
landing
noOfFreeTerminal()
sizeOfTerminal()
TakeOff
attribute
attribute
changeStatusOfRunwayAfterLanding()
changeStatusOfRunwayAfterAlnding()
WeatherDept
Head : String
CheckWeatherConditions()
SendWeatherReport()
WeatherDept()
RunWay
FreeTimings : Integer
LengthOfRunway : Integer
noOfRunway : Integer
UpdateStatusAfterEachTakeOffOrLanding()
RunWay()
Use Case Diagram:
Page no:
send/receive signal
check availability of run awy
send/receive run way num
land / aircraft
send / receive terminals

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

numbers
park aircraft
update status of runway
Page no:
Sequence Diagram:
Airport Simulation
p:prane
Cockpit
: control room
T:terminal
R:runway
W:WeatherD
ept
1: request signal
2: send signal
3: Check Weather conditions
4: send acknowledgement
5: check avaliable for run way
6: wait signal
7: send signal
8: send ack
9: update runway status
10: if time is for next dep send req
11: if terminal is free send terminal no
12: send terminal
13: land aircraft
14: update status of terminal
Page no:
1: request signal
6: wait signal
7: send signal
8: send ack
12: send terminal
13: land aircraft
p:prane
Cockpit
10: if time is for next dep send req

11: if terminal is free send terminal no
14: update status of terminal
T:termin
al
: control room
5: check avaliable for run way
9: update runway status
2: send signal
4: send acknowledgement
R:runwa
y
3: Check Weather conditions

W:Weather
Dept
Page no:
Activity Diagram:
Runway allocation for takeoff Activity Diagram
landing
give aircraft
info to lock s/m
lock system
checking for ks
no
all locks are locked
acquire landing
area lock
acquire
runway lock
aircraft at
take off area
if the aircraft is at takeoff area then
release terminal and taxiing locks
while moving from takeoff area
release takeoff area lock and acquire
runway lock
yes
priority
landing on
another runway
acquire
terminal lock
acquire
taxiing lock
move to the terminal gate and
release terminal and taxiing
lock
Page no:
Runway allocation for takeoff Activity Diagram
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
takeoff area
if the aircraft is at the takeoff

area then release terminal and
taxiing lock while moving from
takeoff area release takeoff area
lock and acquire runway lock
acquire
runway lock
use the runway for takeoff and release

runway lock
State Chart Diagram:

Page no:
req runway status
wait for weather

conditions
wait for
running status
req runway no
wait for
runway no
avail
if time left
wait for terminal

status
not avail
land on
runway
avail
not avail
wait for
terminal no
not avail
avail
halt
Page no:
Component Diagram:
terminal
lock.java
central
server java
landing.jav
a
takeofflock
.java
central server
.class / .dll
taxiinglock.
java
terminalloc
k.class
landing.cla
ss
takeofflock
.class
taxiinglock.
class
central
database
airport.db
priority.db
Deployment Diagram:
Page no:
<<DATA BASE>>
central database
<<SERVER>>
central server
<<WIRELESS COMMUNICATION>>
<<DEVICE>>
<<DEVICE>>
aircarft controlor
<<DEVICE>>
lockmanager
<<DEVICE>>
control manager
taxiing
manager
Result:
Page no:
The various UML diagrams were drawn for AIRPORT SIMULATION SYSTEM
application and the corresponding code was generated.
Page no:
A SIMULATED COMPANY
A SIMULATED COMPANY
Page no:
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.
o
o
o
o
o
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.
Page no:
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.
1.
2.
3.
4.
Draw the lines around the system and actors lie outside the system.
Separate the generalized and specialized actors.
Identify the functionality the way of interacting actors with system and
7. Se the relationship among the use cases and in between actor and use
cases.

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.
Page no:
4. Set the lifelines for each and every object by sending create and
destroy messages.
Set the pre and post conditioned.
objects to outside.
stereotypes.
appropriate.

state.
7. Start with sequential flows, consider branching, fork and joining.
Page no:

1. Choose the context for state machine, whether it is a class, a use case,
7. Consider ways to simplify your machine by using sub states, branches,

1.
2.
3.
4.
5.
6.
Identity the things that are interacting with class diagram.


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.
Page no:

4. Identify the files, tables, documents which are interacting with the
system.
6. Show the existing relationships among them generally dependency.
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.

1.
2.
3.
4.
5.
6.
7.

Page no:
Class Diagram:
Page no:
Use Case Diagram:
Page no:
Sequence Diagram:
Page no:
Page no:
Activity Diagram:
Page no:
State Chart Diagram:
Page no:
Component Diagram
<<Application>>
Simulated
company
Page no:
Component diagram represents a software module with a well defined interface.

The interface of a component is represented by one or several interface
components or elements that the component provides
DEPLOYMENT DIAGRAM:
<<server>>
bank
<<Device>>
Company
Deployment diagram shows the physical configurations of software and hardware.
Result:
Thus various UML diagrams were generated for SIMULATED COMPANY and
corresponding code was generated .
Page no:
Page no:

Uml Lab

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Uml Lab

Загружено:

Авторское право:

Доступные форматы

UML INTRODUCTION

UNIFIED MODELING LANGUAGE

UNIFIED MODELING LANGUAGE

Subclasses are more specialized versions of a class, which inherit

Use case diagrams

Why is UML important?

problem solving -- it all begins with the construction of a model. A model is an

Use case diagrams:

UNIFIED MODELING LANGUAGE

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

UNIFIED MODELING LANGUAGE

Use case diagrams are helpful in three areas.

Determining features (requirements). New use cases often generate

Communicating with clients. Their notational simplicity makes use case

Association -- a relationship between instances of the two classes. There is

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

Aggregation -- an association in which one class belongs to a collection. An

UNIFIED MODELING LANGUAGE

Generalization -- an inheritance link indicating one class is a super class of

Associations with no navigability arrows are bi-directional. The multiplicity of an

Packages and object diagrams

UNIFIED MODELING LANGUAGE

Each rectangle in the object diagram corresponds to a single instance.

A sequence diagram is an interaction diagram that details how operations

The Reservation window sends a make Reservation () message to a Hotel

UNIFIED MODELING LANGUAGE

UNIFIED MODELING LANGUAGE

State chart diagrams:

UNIFIED MODELING LANGUAGE

an object undergoing a process (or on a process as an object), an activity diagram

UNIFIED MODELING LANGUAGE

Activity diagrams can be divided into object swimlanes that determine

A transition may branch into two or more mutually exclusive transitions.

Component and deployment diagrams:

The physical hardware is made up of nodes. Each component belongs on a node.

UNIFIED MODELING LANGUAGE

STEPS FOR MODELING UML DIAGRAMS

Set the context for the interactions, system, subsystem,

Set the stages for the interactions by identifying objects

Lay them out along the X-axis by placing the important

Start the message which is initiating interactions and place

Specify the time and space constraints.

UNIFIED MODELING LANGUAGE

Set the pre and post conditioned.

Modeling steps for Collaboration Diagrams

Set the context for interaction, whether it is system,

Identify the objects that play a role in the interaction. Lay

Set the initial properties of each of these objects. If the

Specify the links among these objects. Lay the association

Starting with the message that initiates this interaction,

Adorn each message with time and space constraints if

Attach pre & post conditions to specify flow of control

Modeling steps for Activity Diagrams

Select the object that has high level responsibilities.

These objects may be real or abstract. In either case, create a

UNIFIED MODELING LANGUAGE

Identify the precondition of initial state and post conditions of

Beginning at initial state, specify the activities and actions

For complicated actions, or for a set of actions that appear

Render the transitions that connect these activities and action

Start with sequential flows, consider branching, fork and

Adorn with notes tagged values and so on.