Uml Lab Manual

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI

ROLL NO: 1220609110

SNONAME OF THE EXPERIMENT PAG

E NOREMARK

S1 UML INTRODUCTION

2A POINT-OF-SALES

SYSTEM

ONLINE BOOKSHOP

AN AUCTION APPLICATION

5 A MULTI THREADED AIRPORT SIMULATION

6 A SIMULATED COMPANY

UNIFIED MODELING LANGUAGE Page no:

3

4


ROLL NO: 1220609110

UML INTRODUCTIONUML INTRODUCTION

STUDY OF UML



ROLL NO: 1220609110AIM:

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


http://java.sun.com/docs/books/tutorial/java/concepts/class.html


ROLL NO: 1220609110possible 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:


http://en.wikipedia.org/wiki/Object_composition

http://en.wikipedia.org/wiki/Inheritance_(computer_science)

http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

http://en.wikipedia.org/wiki/Module_(programming)

http://en.wikipedia.org/wiki/Encapsulation_(computer_science)

http://en.wikipedia.org/wiki/Data_abstraction

http://en.wikipedia.org/wiki/Data_abstraction

http://en.wikipedia.org/wiki/Method_(computer_science)

http://en.wikipedia.org/wiki/Field_(computer_science)

http://en.wikipedia.org/wiki/Data_structures

http://en.wikipedia.org/wiki/Object_(computer_science)

http://en.wikipedia.org/wiki/Programming_paradigm


ROLL NO: 1220609110 Encapsulation conceals the functional details of a class from

objects that send messages to it.

For example, the Dog class has a bark () method. The code for the

bark() method defines exactly how a bark happens (e.g., by inhale()

and then exhale(), at a particular pitch and volume). Timmy, Lassie's

friend, however, does not need to know exactly how she barks.

Encapsulation is achieved by specifying which classes may use the

members of an object. The result is that each object exposes to any

class a certain interface — those members accessible to that class.

The reason for encapsulation is to prevent clients of an interface

from depending on those parts of the implementation that are likely to

change in the future, thereby allowing those changes to be made more

easily, that is, without changes to clients. For example, an interface

can ensure that puppies can only be added to an object of the class

Dog by code in that class. Members are often specified as public,

protected or private, determining whether they are available to all

classes, sub-classes or only the defining class. Some languages go

further: Java uses the default access modifier to restrict access also to

classes in the same package, C# and VB.NET reserve some members

to classes in the same assembly using keywords internal (C#) or

Friend (VB.NET), and Eiffel and C++ allow one to specify which

classes may access any member.

POLYMORPHISM:


http://en.wikipedia.org/wiki/C%2B%2B

http://en.wikipedia.org/wiki/Eiffel_(programming_language)

http://en.wikipedia.org/wiki/Visual_Basic.NET

http://en.wikipedia.org/wiki/C_Sharp_(programming_language)

http://en.wikipedia.org/wiki/Java_(programming_language)

http://en.wikipedia.org/wiki/Interface_(computer_science)


ROLL NO: 1220609110 Polymorphism allows the programmer to treat derived class

members just like their parent class's members. More precisely,

Polymorphism in object-oriented programming is the ability of objects

belonging to different data types to respond to calls of methods of the

same name, each one according to an appropriate type-specific

behavior. One method, or an operator such as +, -, or *, can be

abstractly applied in many different situations. If a Dog is commanded

to speak(), this may elicit a bark(). However, if a Pig is commanded to

speak(), this may elicit an oink(). Each subclass overrides the speak()

method inherited from the parent class Animal.

INHERITANCE:

Subclasses are more specialized versions of a class, which

inherit attributes and behaviors from their parent classes, and can

introduce their own.

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

Chihuahua, and Golden Retriever. In this case, Lassie would be an

instance of the Collie subclass. Suppose the Dog class defines a

method called bark() and a property called fur Color. Each of its sub-

classes (Collie, Chihuahua, and Golden Retriever) will inherit these

members, meaning that the programmer only needs to write the code

for them once.

Each subclass can alter its inherited traits. For example, the

Collie subclass might specify that the default four-Color for a collie is

brown-and-white. The Chihuahua subclass might specify that the

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

add new members. The Chihuahua subclass could add a method called


http://en.wikipedia.org/wiki/Method_(computer_science)

http://en.wikipedia.org/wiki/Data_type

http://en.wikipedia.org/wiki/Object_(computer_science)

http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming


ROLL NO: 1220609110tremble (). 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

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?


http://bdn.borland.com/article/0,1410,31863,00.html#component-and-deployment-diagrans%23component-and-deployment-diagrans

http://bdn.borland.com/article/0,1410,31863,00.html#component-and-deployment-diagrans%23component-and-deployment-diagrans

http://bdn.borland.com/article/0,1410,31863,00.html#activity-diagrams%23activity-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#statechart-diagrams%23statechart-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#collaboration-diagrams%23collaboration-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#sequence-diagrams%23sequence-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#object-diagrams%23object-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#classdiagrams%23classdiagrams

http://bdn.borland.com/article/0,1410,31863,00.html#use-case-diagram%23use-case-diagram

http://en.wikipedia.org/wiki/Multiple_inheritance


ROLL NO: 1220609110Let's look at this question from the point of view of the

construction trade. Architects design buildings. Builders use the

designs to create buildings. The more complicated the building, the

more critical the communication between architect and builder.

Blueprints are the standard graphical language that both architects

and builders must learn as part of their trade.

Writing software is not unlike constructing a building. The more

complicated the underlying system, the more critical the

communication among everyone involved in creating and deploying

the software. In the past decade, the UML has emerged as the software

blueprint language for analysts, designers, and programmers alike. It is

now part of the software trade. The UML gives everyone from business

analyst to designer to programmer a common vocabulary to talk about

software design.

The UML is applicable to object-oriented problem solving. Anyone

interested in learning UML must be familiar with the underlying tenet

of object-oriented problem solving -- it all begins with the construction

of a model. A model is an abstraction of the underlying problem. The

domain is the actual world from which the problem comes. Models

consist of objects that interact by sending each other messages.

Think of an object as "alive." Objects have things they know

(attributes) and things they can do (behaviors or operations). The

values of an object's attributes determine its state.

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.



ROLL NO: 1220609110

Use case diagrams:

Use case diagrams describe what a system does from the

standpoint of an external observer. The emphasis is on what a system

does rather than how.

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

an example of what happens when someone interacts with the system.

Here is a scenario for a medical clinic.

"A patient calls the clinic to make an appointment for a yearly

checkup. The receptionist finds the nearest empty time slot in

the appointment book and schedules the appointment for that

time slot. "

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

An actor is who or what initiates the events involved in that task.

Actors are simply roles that people or objects play. The picture below is

a Make Appointment use case for the medical clinic. The actor is a

Patient. The connection between actor and use case is a

communication association (or communication for short).



ROLL NO: 1220609110

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.

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.



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

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.



ROLL NO: 1220609110Our class diagram has three kinds of relationships.

Association -- a relationship between instances of the two

classes. There is an association between two classes if an

instance of one class must know about the other in order to

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

connecting two classes.

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

collection. An aggregation has a diamond end pointing to the

part containing the whole. In our diagram, Order has a collection

of Order Details.

Generalization -- an inheritance link indicating one class is a

super class of the other. A generalization has a triangle pointing

to the super class. Payment is a super class of Cash, Check,

and Credit.

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

clarify the nature of the association. For example, an Order Detail is a

line item of each Order.

A navigability arrow on an association shows which direction the

association can be traversed or queried. An Order Detail can be

queried about its Item, but not the other 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



ROLL NO: 1220609110Order, but a Customer can have any number of Orders. This table

gives the most common multiplicities.

Multiplicitie

sMeaning

0..1zero or one instance. The notation n . . m

indicates n to m instances.

0..* or *no limit on the number of instances (including

none).

1 exactly one instance

1..* at least one instance

Every class diagram has classes, associations, and multiplicities.

Navigability and roles are optional items placed in a diagram to

provide clarity.

Packages and object diagrams

To simplify complex class diagrams, you can group classes into

packages. A package is a collection of logically related UML elements.

The diagram below is a business model in which the classes are

grouped into packages.



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.



ROLL NO: 1220609110The 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.

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.



ROLL NO: 1220609110Below 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.

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



ROLL NO: 1220609110sure there is available room for each day of the stay in the hotel). The

expression in square brackets, [ ], is a condition.

Collaboration diagrams:

Collaboration diagrams are also interaction diagrams. They

Convey the same information as sequence diagrams, but they

focus on object roles instead of the times that messages are sent. In a

sequence diagram, object roles are the vertices and messages are the

connecting links.

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

names (or both). Class names are preceded by colons (: ).

Each message in a collaboration diagram has a sequence

number. The top-level message is numbered 1. Messages at the same



ROLL NO: 1220609110level (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.



ROLL NO: 1220609110

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:



ROLL NO: 1220609110An 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.



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.

A transition may branch into two or more mutually exclusive

transitions. Guard expressions (inside [ ]) label the transitions



ROLL NO: 1220609110coming 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.



ROLL NO: 1220609110The 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.

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.



ROLL NO: 12206091102. Set the stages for the interactions by identifying

objects which are placed as actions in interaction

diagrams.

3. Lay them out along the X-axis by placing the

important object at the left side and others in the

next subsequent.

4. Set the lifelines for each and every object by sending

create and destroy messages.

5. Start the message which is initiating interactions and

place all other messages in the increasing order of

items.

6. Specify the time and space constraints.

7. Set the pre and post conditioned.

Modeling steps for Collaboration Diagrams

1. Set the context for interaction, whether it is system,

subsystem, operation or class or one scenario of use

case or collaboration.

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

Lay them as vertices in graph, placing important

objects in centre and neighboring objects to outside.

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

the attributes or tagged values of an object changes

in significant ways over the interaction, place a

duplicate object, update with these new values and

connect them by a message stereotyped as become

or copy.

4. Specify the links among these objects. Lay the

association links first represent structural connection.

Lay out other links and adorn with stereotypes.



ROLL NO: 12206091105. 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.

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



ROLL NO: 12206091101. 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.

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.



ROLL NO: 12206091103. Set the responsibilities.

4. Identify the generalization and specification

classes.

5. Set the relationship among all the things.

6. Adorn with tagged values, constraints and notes.

Modeling steps for Object Diagrams

1. Identify the mechanisms which you would like to

model.

2. Identify the classes, use cases, interface,

subsystem which are collaborated with

mechanisms.

3. Identify the relationship among all objects.

4. Walk through the scenario until to reach the

certain point and identify the objects at that point.

5. Render all these classes as objects in diagram.

6. Specify the links among all these objects.

7. Set the values of attributes and states of objects.

Modeling steps for Component Diagrams

1. Identify the component libraries and executable files

which are interacting with the system.

2. Represent this executables and libraries as

components.

3. Show the relationships among all the components.

4. Identify the files, tables, documents which are

interacting with the system.

5. Represent files, tables, documents as components.

6. Show the existing relationships among them

generally dependency.



ROLL NO: 12206091107. Identify the seams in the model.

8. Identify the interfaces which are interacting with the

system.

9. Set attributes and operation signatures for

interfaces.

10.Use either import or export relationship in b/w

interfaces & components.

11.Identify the source code which is interacting with the

system.

12.Set the version of the source code as a constraint to

each source code.

13.Represent source code as components.

14.Show the relationships among components.

15.Adorn with nodes, constraints and tag values.

Modeling steps for Deployment Diagram

1. Identify the processors which represent

client & server.

2. Provide the visual cue via stereotype

classes.

3. Group all the similar clients into one

package.

4. Provide the links among clients &

servers.

5. Provide the attributes & operations.

6. Specify the components which are living

on nodes.

7. Adorn with nodes & constraints & draw

the deployment diagram.



ROLL NO: 1220609110APPLICATION 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 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.



ROLL NO: 1220609110 The overall model contains classes, use cases, objects, packages,

operations, component packages, components, processors, devices

and the relationship between them. Each of these model elements

possess model properties that identify and characterize them.

A model also contains diagrams and specifications, which

provides a means of visualizing and manipulating the model’s

elements and their model properties. Since diagram is used to

illustrate multiple views of a model, icons representing a model

element can appear in none, or several of a model’s diagrams.

The application therefore enables you to control, which element,

relationship and property icons appear on each diagram, using

facilities provided by its application window. Within its application

window, it displays each diagram in a diagram window and each

specification in a specification window.

It provides a separate tool , called Model Integrator to compare

and merge models and their controlled units. It also enables teams to

reuse large- scale design assets developed in earlier modeling efforts

by providing the possibility to add frame works in Rational Rose.

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.



ROLL NO: 1220609110

Point of Sale System



ROLL NO: 1220609110

Point of Sale System

AIM: To create a Point of Sale System

ACTORS: 1. customer

2. cashier

USECASES:1. Bar code scanning2. Process sale3. Close sale 4. Pay Bill.5. Tax calculation 6. Buy product7. Update Inventory

ALGORITHMIC PROCEDURE:

STEP 1: Start the applicationSTEP 2: Create the require actors and use cases in the browser windowSTEP 3: Goto new use case view and then click the use case view and open a new packageSTEP 4: Rename the new package with the package with required namesSTEP 5: Create two packages actor and use case



ROLL NO: 1220609110Class diagram:



ROLL NO: 1220609110

Use Case Diagram :

Pay bill

Process sale

Close sale

Update Inventory

Barcode scanning

Tax calculation

CashierCustomer

Buy product



ROLL NO: 1220609110

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



ROLL NO: 1220609110

Process sale sequence diagram

Cashier POS System Codescanner

Card reader Bank

1: Enter no of items

2: get item id

3: show item details

4: calculate bill

5: bill payment6: get credit card number

7: verify validation

8: valid

9: validation ok

10: generate report

Process sale collaboration diagram



ROLL NO: 1220609110

Cashier POS System

Codescanner

Card reader

Bank

1: Enter no of items2: get item id

3: show item details4: calculate bill

5: bill payment

6: get credit card number

7: verify validation

8: valid

9: validation ok

10: generate report

POS system activity diagram



ROLL NO: 1220609110

enters the shop

select product

pay the bill

prepare item list

process bill

scan items bill generation

pos systemBarcode readerCashierCustomer



ROLL NO: 1220609110

RESULT:

Thus various UML Diagrams were generated for POINT OF SALE SYSTEM and the corresponding code was generated using Visual Basic.



ROLL NO: 1220609110

ONLINE BOOK SHOP SYSTEM



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



ROLL NO: 1220609110Brief Description of the Project: The current project emphasizes on analysis and design of an online bookshop system. That serves the customers needs. The customer’s available activities in the proposed system from logging on the browsing the book store, selecting items and making purchases are described.

PROBLEM STATEMENT FOR ONLINE BOOKSHOP SYSTEM

As a young promising student you are tasked with developing an online book shop system. The system should be competitive enough by providing the facilities/options that are currently provided by reputed systems like Amazon.com and BN.com. The proposed system should allow the customer with activities from logging on to the system, browsing the book store, selecting items and making purchases i.e., the 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



ROLL NO: 1220609110meaningful 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

USE CASES: Registration Login Create order Book catalog Manage cart and payments Order status Inventory

RELATIONSHIPS USED: Association Dependency Composition

Modeling steps for Use case Diagram

1. Draw the lines around the system and actors lie outside the system.

Identify the actors which are interacting with the system.

2. Separate the generalized and specialized actors.3. Identify the functionality the way of interacting actors with

system and specify the behavior of actor.4. Functionality or behavior of actors is considered as use

cases.5. Specify the generalized and specialized use cases.6. 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.2. Set the stages for the interactions by identifying objects which are placed as actions in interaction diagrams.



ROLL NO: 12206091103. Lay them out along the X-axis by placing the important object at the left side and others in the next subsequent.4. Set the lifelines for each and every object by sending create and destroy messages.5. Start the message which is initiating interactions and place all other messages in the increasing order of items.6. Specify the time and space constraints.7. Set the pre and post conditioned.


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.



ROLL NO: 12206091104. 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.

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



ROLL NO: 1220609110Modeling 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.


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



ROLL NO: 12206091107. 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.

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. Book3. Bookshop4. Item



ROLL NO: 1220609110

PACKAGE-2: CUSTOMER This package consists of following classes:1. Customer2. Address3. Billing Address4. Shipping Address

PACKAGE -3:ONLINE ORDERING This package consists of following classes:

1. Order2. Item Order3. Shopping Cart

CLASS DIAGRAM:



ROLL NO: 1220609110

USE CASE DIAGRAM FOR ONLINE BOOKSHOP SYSTEM:



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.



ROLL NO: 1220609110

customer registration login create order book catalog inventory bookshop staff

cart shippment details

payment consortinum database

2: manages

3: updates

1: login request

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

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



ROLL NO: 1220609110emphasis is based on structural organization of the objects that send and receive messages.

1: login request

login create order

book catalog

cart consortinum

database

customer

inventory

bookshop staff

shippment details

payment

11: select books

15: add to cart

17: payment

9: logon successful

4: update12: verify

14: confirm selection2: manages

3: updates

13: stock ok

18: delivered successfully

registration

6: register first7: registered logon request

10: create order

16: shippment details

5: verify

8: verify

STATE CHART DIAGRAM:

Objects have behaviors and state. The state of an object depends on its current activity or condition. A state chart



ROLL NO: 1220609110diagram 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.

browse screen

mainscreen

valid logincreate order listed books

in catalog

selections

selectconfirm

wait for result

choose

search by author,title,isbncancel

can't find

cancels

return to

wait for view details

wait for transaction details

not satisfied

cart

add to

view shipping details

invalid transaction

transaction success display thank u screen

ACTIVITY DIAGRAM:



ROLL NO: 1220609110An 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

display item info

accept selection

create order for cart

display order

acceptance

ship to customer

accepted

rejected

more selections

completed

rejected

COMPONENT DIAGRAM:

A component is a code module. Component diagrams are physical analogs of class diagram. Each component belongs on a



ROLL NO: 1220609110node. Components are shown as rectangles with two tabs at the upper left.

address.java

order.java

book.java

bokshop.java

bookstaff.java

item.java

order.class

book.class

bookshop.class

bookstaff.class

books.db

items.db

central server.java

central server.class/.dll

central database

address.class

item.class

address.db order.db

DEPLOYMENT DIAGRAM: Deployment diagram shows the physical configurations of

software and hardware.



ROLL NO: 1220609110



ROLL NO: 1220609110

RESULT :

Thus various UML Diagrams were generated for ONLINE BOOK SHOP and the corresponding code was generated using Visual Basic.



ROLL NO: 1220609110

AN ONLINE AUCTION SALE

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



ROLL NO: 1220609110website for visualizing. To accomplish this purpose the user has to access the site. Incase it’s a new user he has to register. Purchaser logs in and selects items they want to buy and keep bidding for it. Interacting with the purchasers and sellers in the chat room does this. The purchaser making the highest bid for the item before the close of the auction is declared as the owner of the item. If the auctioneer or the purchaser does not want to bid for the product then there is fixed cutoff price mentioned for every product. He can pay the amount directly and own the product. The purchaser gets a confirmation of his purchase as an acknowledgement from the website. After the transaction by going back to the main menu where he can view other items.

As per case study, the following analysis diagrams will be created.

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.



ROLL NO: 1220609110 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. Purchaser2. Seller

Use Cases in Auction System

1. Login2. Seller3. Purchaser 4. Chatting5. Select Method of bidding6. Select Method of Auction7. Buy Goods8. Register for goods9. Select history of database



ROLL NO: 1220609110Use Cases In Purchaser’s Diagram:

1. Validate User2. Record chatting.

ALGORITHMIC PROCEDURE:

STEP 1: Start the applicationSTEP 2: Create the require actors and use cases in the browser windowSTEP 3: Got new use case view and then click the use case view and

Open a new packageSTEP 4: Rename the new package with the package with required NamesSTEP 5: Create two packages actor and use case

DIAGRAMS:



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


cases.6. Specify the generalized and specialized use cases.



ROLL NO: 12206091107. 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.


1. Set the context for the interactions, system, subsystem, classes, object or use cases.

2. Set the stages for the interactions by identifying objects which are placed as actions in interaction diagrams.

3. Lay them out along the X-axis by placing the important object at the left side and others in the next subsequent.

4. Set the lifelines for each and every object by sending create and destroy messages.

5. Start the message which is initiating interactions and place all other messages in the increasing order of items.

6. Specify the time and space constraints.7. Set the pre and post conditioned.


1. Set the context for interaction, whether it is system, subsystem, operation or class or one scenario of use case or collaboration.





ROLL NO: 12206091104. Specify the links among these objects. Lay the association

links first represent structural connection. Lay out other links and adorn with stereotypes.







of final state.4. Beginning at initial state, specify the activities and actions



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.

2. Choose the initial & final states of the objects.3. Decide on the stable states of the object by considering the




6. Attach actions to these transitions and/or to these states.



ROLL NO: 12206091107. Consider ways to simplify your machine by using

substates, branches, forks, joins and history states.8. Check that all states are reachable under some




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.




ROLL NO: 12206091101. 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. 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.



ROLL NO: 1220609110

Class Diagram:



ROLL NO: 1220609110

product

idnametypecurrentBiddingPrice

finalCutOffPrice()product()

auctioner

id

sendTheDetalisOfProductsToBidder()updateTheBiddingPrice()sellTheProduct()getThePricepaid()auctioner()

customer(bidder)

namecontact infoaddress

logon to the site()search for the required product()bid forproduct()pay the price()

site

namelistOfAvailableProductslistOfPriceswebHost

update the site with products()sell the products()

Use case Diagram:



ROLL NO: 1220609110

login

search for product

bid the product

pay the price

BIdder

request/send details

buy/sell the product

Auctioner

deliver the product

Sequence diagram:



ROLL NO: 1220609110

: BIdder

s:site a:auctioner p:product

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:



ROLL NO: 1220609110

: BIdder

s:site

a:auctioner

p:product

8: check for product

1: login 12: logout

2: search

3: request product details

6: pay final price or bid for product

10: buy the product

11: pay price

4: get details

7: update bid price

5: display details9: give ackn if suitable for selling



ROLL NO: 1220609110ActivityDiagram:

log on to the site

search for the product

request details

if final fixed price suitable

bid the final price and buy the product

bid for the product

check for the cutoff price

sell/buy the product

if suitable for selling

wait for the next bid

pay the price

noyes

no

State chart diagram:



ROLL NO: 1220609110

wait for request

wait for the desicion

wait to update bid price

Bid the price

wait until next bid comes

bid for a higher price

wait for bid price to meet cut off compare the bidding price with cutoff

wait for payment

sell / but the product

requested product details



ROLL NO: 1220609110

COMPONENT DIAGRAM:

central server java

central server class

Central database

name

list of prices

web host

site

customer

product.db



ROLL NO: 1220609110

AN AIRPORT SIMULATION



ROLL NO: 1220609110 A Multi- Threaded Airport Simulation

Aim: to create a Multi- Threaded Airport Simulation

Actors:

ATC Controller

Use Cases

1. ATC Controller2. Decision Support System3. Planning4. Emergency5. Sensor6. Gateway7. Runway8. Terminal 9. Available10.Waiting Queue

Algorithmic Procedure:

STEP 1: Start the applicationSTEP 2: Create the require actors and use cases in the browser windowSTEP 3: Go to new use case view and then click the use case view and

Open a new packageSTEP 4: Rename the new package with the package with required NamesSTEP 5: Create two packages actor and use case

Overview



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



ROLL NO: 1220609110Input will be:

The amount of time needed for one plane to land. The amount of time needed for one plane to takeoff. The probability of a plane entering the landing queue in any

given minute. The probability of a plane entering the takeoff queue in any

given minute. The maximum minutes until a plane waiting to land will crash. The statues of each runway, plane and terminal.

The Output of the program will be: Total simulation time. The number of planes that takeoff in the simulated time. The number of planes that landed in the simulated time. The average time a plane spent in the takeoff queue. The average time a plane spent in the landing queue. Updated status of each runway, plane, and terminal.

Key terms: Aircraft simulation. Airport: runways, terminals, planes, control room. Aircraft: passengers, model no. cockpit, pilots. Function points:

1. Transmit/receive signals.2. Pilot sends signals for takeoff/landing.3. Loop - Check status of each runway. - Finalize a free runway. - Assign the runway to the plan.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:



ROLL NO: 1220609110Textual Analysis:

This covers the requirements and diagrams of the project. The complete simulation of airport control system as followsActors:

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



ROLL NO: 12206091106. 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.

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 OperationsControl Room -Technical head

-No of staff-systems to control

+Receive signals from planes()+Check for free runway()+Send runway no()+Check for next departure()+Look for free terminal()+Send terminal no to plane()



ROLL NO: 1220609110+Get plane parked()

Takeoff/Landing -Runway no-Flight no-Status-Time taken

+Update status of runway after each take of or landing()

Plane Cockpit -No of pilots-Flight no-Destination-Timings

+Send signal to ground station()+Receive runway no()+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-Length of runwayStatus of runway-Free timings-Runway no

+Update status of runway after each takeoff/landing()

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 casesTechnical head .Transmit/Receive signals

.Look for free runway

.Check whether conditions

.Give directions to aircraft



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

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



ROLL NO: 1220609110The 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

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.



ROLL NO: 1220609110Deployment Diagram

Deployment diagram shows the physical configurations of software and hardware.

Class Diagram:



ROLL NO: 1220609110

ControlRoomNoOfStaff : IntegerSystemsToControl : StringtechnicalHead : String

Check for free runway()Check for free terminal()Check for time for next depature()

WeatherDeptHead : String

CheckWeatherConditions()SendWeatherReport()WeatherDept()

Control-CockpitFlight No : IntegerNo of pilots : Integertimings : 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()

TerminalFreeTimmings : IntegermodelNoOfAircraftWhichItSuitable : Integer

noOfFreeTerminal()sizeOfTerminal()

11

1

1..*

1

1..*

TakeOffattribute

changeStatusOfRunwayAfterAlnding()

<<interface>>

RunWayFreeTimings : IntegerLengthOfRunway : IntegernoOfRunway : Integer

UpdateStatusAfterEachTakeOffOrLanding()RunWay()

1

1

1

1

landingattribute

changeStatusOfRunwayAfterLanding()

<<Interface>>

1

1

1

1

Airport Simulation

Use Case Diagram:



ROLL NO: 1220609110

send / receive terminals numbers

check availability of run awy

send/receive signal

send/receive run way num

land / aircraft

check free terminals

Control room

update status of runway

park aircraft

Plane cockpit

send / receive terminal numbers

Sequence Diagram:



ROLL NO: 1220609110

: control roomp:prane Cockpit

T:terminal R:runway W:WeatherDept

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

Airport Simulation




ROLL NO: 1220609110

: control room

p:prane Cockpit

T:terminal

R:runway

W:WeatherDept

3: Check Weather conditions

1: request signal6: wait signal7: send signal8: send ack

12: send terminal13: land aircraft

2: send signal

4: send acknowledgement

5: check avaliable for run way9: update runway status

10: if time is for next dep send req11: if terminal is free send terminal no

14: update status of terminal

Activity Diagram:

Runway allocation for takeoff Activity Diagram



ROLL NO: 1220609110

landing

give aircraft info to lock s/m

lock system checking for ks

acquire landing area lock

priority

acquire runway lock

aircraft at take off area

landing on another runway

acquire terminal lock

all locks are lockednoyes

acquire taxiing lock

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

move to the terminal gate and release terminal and taxiing lock

Runway allocation for takeoff Activity Diagram



ROLL NO: 1220609110

give aircraft info to lock s/m

acquire terminal lock

checks for locks

acquire takeoff area lock

if locks are available

acquire taxiing lock

aircraft at takeoff area

acquire runway lock

use the runway for takeoff and release runway lockif 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

takeoff

State Chart Diagram:



ROLL NO: 1220609110

wait for weather conditions

wait for running status

req runway status

wait for runway no

req runway no

land on runway

wait for terminal status

wait for terminal no

halt

availnot avail

avail

not avail

if time left

avail not avail

Component Diagram:



ROLL NO: 1220609110

central server java

central server .class / .dll

central database

terminal lock.java

landing.java

takeofflock.java

taxiinglock.java

terminallock.class

landing.class

takeofflock.class

taxiinglock.class

airport.db

priority.db

Deployment Diagram:



ROLL NO: 1220609110

central database<<DATA BASE>>

central server<<SERVER>>

<<WIRELESS COMMUNICATION>>

aircarft controlor<<DEVICE>>

lockmanager<<DEVICE>>

taxiing manager

<<DEVICE>> control manager<<DEVICE>>



ROLL NO: 1220609110

Result: The various UML diagrams were drawn for AIRPORT SIMULATION SYSTEM application and the corresponding code was generated.



ROLL NO: 1220609110

A SIMULATED COMPANY

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



ROLL NO: 1220609110simulates 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 Usecase for the systemo Class diagram for initially identified classes.o Activity diagram to show flow for each use case.o Sequence and collaboration diagrams.o 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:



ROLL NO: 1220609110

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 loanPurchase machinery and start production.Sell the products and updated the records.The performance department has to update the statistics and to the company.



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


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



ROLL NO: 12206091106. Specify the time and space constraints.Set the pre and post conditioned.

Modeling steps for Collaboration Diagrams1. Set the context for interaction, whether it is system,

subsystem, operation or class or one scenario of use case or collaboration.



4. Specify the links among these objects. Lay the association links first represent structural connection. Lay out other links and adorn with stereotypes.







of final state.4. Beginning at initial state, specify the activities and actions





ROLL NO: 12206091106. 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 Diagram1. 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




6. Attach actions to these transitions and/or to these states.7. Consider ways to simplify your machine by using sub

states, branches, forks, joins and history states.8. Check that all states are reachable under some




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 Diagrams1. Identify the mechanisms which you would like to model.2. Identify the classes, use cases, interface, subsystem which

are collaborated with mechanisms.



ROLL NO: 12206091103. 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.


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



ROLL NO: 1220609110

Class Diagram:



ROLL NO: 1220609110

Use Case Diagram:



ROLL NO: 1220609110



ROLL NO: 1220609110Sequence Diagram:




ROLL NO: 1220609110

Activity Diagram:



ROLL NO: 1220609110

State Chart Diagram:



ROLL NO: 1220609110



ROLL NO: 1220609110

RESULT: Thus various UML Diagrams were generated for SIMULATED COMPANY and the corresponding code was generated using Visual Basic.


Date post:	28-Nov-2014
Category:	Documents
Upload:	girish-kumar-nistala
View:	14,635 times
Download:	0 times

Uml Lab Manual

Documents