UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

UML INTRODUCTION

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

STUDY OF UMLAIM: General study of UMLDESCRIPTION: The heart of object-oriented problem solving is theconstruction of a model. The model abstracts the essential details ofthe 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 thiscourse 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 andbehavior of a real-world object. It intentionally focuses on the basics,showing how even simple classes can cleanly model state andbehavior. For example, the class Dog would consist of traits shared byall dogs, such as breed and fur color (characteristics), and the abilityto bark and sit (behaviors).

OBJECT

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 An object is a software bundle of related state and behavior.Software objects are often used to model the real-world objects thatyou find in everyday life. This lesson explains how state and behaviorare represented within an object, introduces the concept of dataencapsulation, and explains the benefits of designing your software inthis manner. A pattern(exemplar) of a class. The class Dog defines all

possible dogs by listing the characteristics and behaviors they can

have; the object Lassie is one particular dog, with particular versionsof the characteristics. A Dog has fur; Lassie has brown-and-white fur.

OBJECT ORIENTATION CONCEPTS:

Object-Orientation goes beyond just modeling attributes andbehavior. 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 methodstogether with their interactions – to design applications and computerprograms. Programming techniques may include features such as dataabstraction, encapsulation, modularity, polymorphism, andinheritance. These aspects are called abstraction, Inheritance,polymorphism and encapsulation.

ABSTRACTION Abstraction is simplifying complex reality by modeling classesappropriate to the problem, and working at the most appropriate levelof inheritance for a given aspect of the problem.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 For example, Lassie the Dog may be treated as a Dog much ofthe time, a Collie when necessary to access Collie-specific attributes orbehaviors, and as an Animal (perhaps the parent class of Dog) whencounting Timmy's pets. Abstraction is also achieved throughComposition. For example, a class

ENCAPSULATION: Encapsulation conceals the functional details of a class fromobjects that send messages to it.

For example, the Dog class has a bark () method. The code for thebark() method defines exactly how a bark happens (e.g., by inhale()and then exhale(), at a particular pitch and volume). Timmy, Lassie'sfriend, however, does not need to know exactly how she barks.Encapsulation is achieved by specifying which classes may use themembers of an object. The result is that each object exposes to anyclass 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 tochange in the future, thereby allowing those changes to be made moreeasily, that is, without changes to clients. For example, an interfacecan ensure that puppies can only be added to an object of the classDog by code in that class. Members are often specified as public,protected or private, determining whether they are available to allclasses, sub-classes or only the defining class. Some languages goUNIFIED MODELING LANGUAGE Page no: GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110further: Java uses the default access modifier to restrict access alsoto classes in the same package, C# and VB.NET reserve somemembers to classes in the same assembly using keywords internal(C#) or Friend (VB.NET), and Eiffel and C++ allow one to specifywhich classes may access any member.

POLYMORPHISM: Polymorphism allows the programmer to treat derived classmembers just like their parent class's members. More precisely,Polymorphism in object-oriented programming is the ability of objectsbelonging to different data types to respond to calls of methods of thesame name, each one according to an appropriate type-specificbehavior. One method, or an operator such as +, -, or *, can beabstractly applied in many different situations. If a Dog is commandedto speak(), this may elicit a bark(). However, if a Pig is commanded tospeak(), 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, whichinherit attributes and behaviors from their parent classes, and canintroduce their own.

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

Collie, Chihuahua, and Golden Retriever. In this case, Lassie would bean instance of the Collie subclass. Suppose the Dog class defines a

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110method called bark() and a property called fur Color. Each of its sub-classes (Collie, Chihuahua, and Golden Retriever) will inherit thesemembers, meaning that the programmer only needs to write the codefor them once.

Each subclass can alter its inherited traits. For example, theCollie subclass might specify that the default four-Color for a collie isbrown-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 calledtremble (). So an individual Chihuahua instance would use a high-pitched bark () from the Chihuahua subclass, which in turn inheritedthe usual bark () from Dog. The Chihuahua object would also have thetremble () method, but Lassie would not, because she is a Collie, not aChihuahua. In fact, inheritance is an "a... is a" relationship betweenclasses, while instantiation is an "is a" relationship between an objectand 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 classesCollie and Dog.

Multiple inheritances are inheritance from more than one

ancestor class, neither of these ancestors being an ancestor of theother. For example, independent classes could define Dogs and Cats,and a Chimera object could be created from these two which inheritsall the (multiple) behavior of cats and dogs. This is not alwayssupported, as it can be hard to implement

Why is UML important?

Let's look at this question from the point of view of theconstruction trade. Architects design buildings. Builders use thedesigns to create buildings. The more complicated the building, themore critical the communication between architect and builder.Blueprints are the standard graphical language that both architectsand 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 thecommunication among everyone involved in creating and deployingthe software. In the past decade, the UML has emerged as thesoftware blueprint language for analysts, designers, and programmersalike. It is now part of the software trade. The UML gives everyone

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110from business analyst to designer to programmer a commonvocabulary to talk about software design.

The UML is applicable to object-oriented problem solving.

Anyone interested in learning UML must be familiar with theunderlying tenet of object-oriented problem solving -- it all begins withthe construction of a model. A model is an abstraction of theunderlying problem. The domain is the actual world from which theproblem comes. Models consist of objects that interact by sendingeach other messages. Think of an object as "alive." Objects havethings they know (attributes) and things they can do (behaviors oroperations). 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 distinctentity. 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 systemdoes 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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 "A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "

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

An actor is who or what initiates the events involved in that task.Actors are simply roles that people or objects play. The picture belowis a Make Appointment use case for the medical clinic. The actor is aPatient. The connection between actor and use case is acommunication 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

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110with four actors and four use cases. Notice that a single use case canhave multiple actors.

Use case diagrams are helpful in three areas.

• Determining features (requirements). New use cases often

generate new requirements as the system is analyzed and the design takes shape.

• Communicating with clients. Their notational simplicity makes

use case diagrams a good way for developers to communicate with clients.

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

case may suggest a suite of test cases for those scenarios.

Class diagrams:

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

classes and the relationships among them. Class diagrams are static --

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110they display what interacts but not what happens when they dointeract.

The class diagrams below models a customer order from a retail

catalog. The central class is the Order. Associated with it is theCustomer making the purchase and the Payment? A Payment isone of three kinds: Cash, Check, or Credit. The order contains OrderDetails (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 asPayment, are in italics. Relationships between classes are theconnecting links.

Our class diagram has three kinds of relationships.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 • Association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to

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

connecting two classes.

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

collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of Order Details.

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

super class of the other. A generalization has a triangle pointing to the super class. Payment is a super class of Cash, Check, and Credit.

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

clarify the nature of the association. For example, an Order Detail isa 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 bequeried about its Item, but not the other way around. The arrow alsolets you know who "owns" the association's implementation; in thiscase, Order Detail has an Item. Associations with no navigabilityarrows are bi-directional. The multiplicity of an association end is thenumber of possible instances of the class associated with a single

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110instance of the other end. Multiplicities are single numbers or rangesof numbers. In our example, there can be only one Customer foreach Order, but a Customer can have any number of Orders. Thistable gives the most common multiplicities.

Multiplicities Meaning zero or one instance. The notation n . . m 0..1 indicates n to m instances. no limit on the number of instances (including 0..* or * none). 1 exactly one instance 1..* at least one instance

Every class diagram has classes, associations, and multiplicities.

Navigability and roles are optional items placed in a diagram toprovide 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 aregrouped into packages.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

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

package name is on the tab or inside the rectangle. The dotted arrowsare dependencies. One package depends on another if changes inthe 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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

The object diagram below instantiates the class diagram, replacing it

by a concrete example.

Each rectangle in the object diagram corresponds to a single

instance. Instance names are underlined in UML diagrams. Class orinstance names may be omitted from object diagrams as long as thediagram meaning is still clear.

Sequence diagrams

Class and object diagrams are static model views. Interaction

diagrams are dynamic. They describe how objects collaborate.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 A sequence diagram is an interaction diagram that details howoperations are carried out -- what messages are sent and when.Sequence diagrams are organized according to time. The timeprogresses as you go down the page. The objects involved in theoperation are listed from left to right according to when they take partin 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 makeReservation () message to a Hotel. If the Hotel has available rooms,then it makes a Reservation and a Confirmation.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 Each vertical dotted line is a lifeline, representing the time thatan object exists. Each arrow is a message call. An arrow goes from thesender to the top of the activation bar of the message on thereceiver's lifeline. The activation bar represents the duration ofexecution 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 aConfirmation. The asterisk on the self call means iteration (to makesure there is available room for each day of the stay in the hotel). Theexpression 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 asequence diagram, object roles are the vertices and messages are theconnecting links.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

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

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

Each message in a collaboration diagram has a sequence

number. The top-level message is numbered 1. Messages at the samelevel (sent during the same call) have the same decimal prefix butsuffixes 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 diagramshows the possible states of the object and the transitions that cause achange in state.

Logging in can be factored into four non-overlapping states:

Getting SSN, Getting PIN, Validating, and Rejecting. From eachstate comes a complete set of transitions that determine thesubsequent state.

States are rounded rectangles. Transitions are arrows from one

state to another. Events or conditions that trigger transitions arewritten beside the arrows. Our diagram has two self-transition, one onGetting SSN and another on Getting PIN.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 The initial state (black circle) is a dummy to start the action.Final states are also dummy states that terminate the action.

The action that occurs as a result of an event or condition is

expressed in the form /action. While in its Validating state, the objectdoes not wait for an outside event to trigger a transition. Instead, itperforms an activity. The result of that activity determines itssubsequent state.

Activity diagrams:

An activity diagram is essentially a fancy flowchart. Activity

diagrams and state chart diagrams are related. While a state chartdiagram focuses attention on an object undergoing a process (or on aprocess as an object), an activity diagram focuses on the flow ofactivities involved in a single process. The activity diagram shows thehow those activities depend on one another.

For our example, we used the following process.

"Withdraw money from a bank account through an ATM."

The three involved classes (people, etc.) of the activity are

Customer, ATM, and Bank. The process begins at the black start

Circle at the top and ends at the concentric white/black stop

circles at the bottom. The activities are rounded rectangles.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

Activity diagrams can be divided into object swimlanes that

determine which object is responsible for which activity. A singletransition comes out of each activity, connecting it to the nextactivity.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 A transition may branch into two or more mutually exclusivetransitions. Guard expressions (inside [ ]) label the transitionscoming out of a branch. A branch and its subsequent merge markingthe end of the branch appear in the diagram as hollow diamonds.

A transition may fork into two or more parallel activities. The fork andthe subsequent join of the threads coming out of the fork appear inthe diagram as solid bars.

A component is a code module. Component diagrams are

The following deployment diagram shows the relationships

among software and hardware components involved in real estatetransactions.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

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

on a node. Components are shown as rectangles with two tabs at theupper 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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 4. Identify the functionality the way of interacting actors with system and specify the behavior of actor.

5. Functionality or behavior of actors is considered

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

7. Se the relationship among the use cases and in

between actor and use cases. 8. Adorn with constraints and notes. 9. If necessary, use collaborations to realize use cases.

Modeling steps for Sequence Diagrams

1. Set the context for the interactions, system,

subsystem, classes, object or use cases. 2. Set the stages for the interactions by identifying objects which are placed as actions in interaction diagrams. 3. Lay them out along the X-axis by placing the important object at the left side and others in the next subsequent. 4. Set the lifelines for each and every object by sending create and destroy messages.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 5. Start the message which is initiating interactions and place all other messages in the increasing order of items. 6. Specify the time and space constraints. 7. Set the pre and post conditioned.

Modeling steps for Collaboration Diagrams

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

subsystem, operation or class or one scenario of use case or collaboration. 2. Identify the objects that play a role in the interaction. Lay them as vertices in graph, placing important objects in centre and neighboring objects to outside. 3. Set the initial properties of each of these objects. If the attributes or tagged values of an object changes in significant ways over the interaction, place a duplicate object, update with these new values and connect them by a message stereotyped as become or copy. 4. Specify the links among these objects. Lay the association links first represent structural connection. Lay out other links and adorn with stereotypes. 5. Starting with the message that initiates this interaction, attach each subsequent message to

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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

Modeling steps for State chart Diagram

1. Choose the context for state machine, whether it is a

class, a use case, or the system as a whole. 2. Choose the initial & final states of the objects. 3. Decide on the stable states of the object by considering the conditions in which the object may exist for some identifiable period of time. 4. The high-level states of the objects & only then consider its possible sub-states. 5. Decide on the meaningful partial ordering of stable states over the lifetime of the object. 6. Decide on the events that may trigger a transition from state to state. Model these events as triggers to transitions that move from one legal ordering of states to another. 7. Attach actions to these transitions and/or to these states. 8. Consider ways to simplify your machine by using substates, branches, forks, joins and history states. 9. Check that all states are reachable under some combination of events. 10.Check that no state is a dead from which no combination of events will transition the object out of that state.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 11.Trace through the state machine, either manually or by using tools, to check it against expected sequence of events & their responses.Modeling steps for Class Diagrams

1. Identity the things that are interacting with class

diagram. 2. Set the attributes and operations. 3. Set the responsibilities. 4. Identify the generalization and specification classes. 5. Set the relationship among all the things. 6. Adorn with tagged values, constraints and notes.

Modeling steps for Object Diagrams

1. Identify the mechanisms which you would like to

model. 2. Identify the classes, use cases, interface, subsystem which are collaborated with mechanisms. 3. Identify the relationship among all objects. 4. Walk through the scenario until to reach the certain point and identify the objects at that point. 5. Render all these classes as objects in diagram. 6. Specify the links among all these objects.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 7. Set the values of attributes and states of objects.

Modeling steps for Component Diagrams

1. Identify the component libraries and executable files

which are interacting with the system. 2. Represent this executables and libraries as components. 3. Show the relationships among all the components. 4. Identify the files, tables, documents which are interacting with the system. 5. Represent files, tables, documents as components. 6. Show the existing relationships among them generally dependency. 7. Identify the seams in the model. 8. Identify the interfaces which are interacting with the system. 9. Set attributes and operation signatures for interfaces. 10.Use either import or export relationship in b/w interfaces & components. 11.Identify the source code which is interacting with the system. 12.Set the version of the source code as a constraint to each source code. 13.Represent source code as components.

Modeling steps for Deployment Diagram

1. Identify the processors which represent

client & server. 2. Provide the visual cue via stereotype classes. 3. Group all the similar clients into one package. 4. Provide the links among clients & servers. 5. Provide the attributes & operations. 6. Specify the components which are living on nodes. 7. Adorn with nodes & constraints & draw the deployment diagram.

APPLICATION OF RATION ROSE TO UML

Rational Rose was developed by IBM Corporation in order todevelop a software system based on the concepts of Object OrientedAnalysis and Design approach as developed from the models of GradyBooch, Jacobson and Ram Baugh methodologies, resulting into aUnified approach.

Rational Rose is an object-oriented Unified Modeling Language

(UML) software design tool intended for visual modeling and

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110component construction of enterprise-level software applications. Inmuch the same way a theatrical director blocks out a play, a softwaredesigner uses Rational Rose to visually create (model) the frameworkfor an application by blocking out classes with actors (stick figures),use case elements (ovals), objects (rectangles) andmessages/relationships (arrows) in a sequence diagram using drag-and-drop symbols. Rational Rose documents the diagram as it is beingconstructed 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. RationalRose allows designers to take advantage of iterative development(sometimes called evolutionary development) because the newapplication can be created in stages with the output of one iterationbecoming the input to the next. (This is in contrast to waterfalldevelopment where the whole project is completed from start to finishbefore a user gets to try it out.) Then, as the developer begins tounderstand how the components interact and makes modifications inthe design, Rational Rose can perform what is called "round-tripengineering" by going back and updating the rest of the model toensure 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

UNIFIED MODELING LANGUAGE Page no:

A model also contains diagrams and specifications, which

provides a means of visualizing and manipulating the model’selements and their model properties. Since diagram is used toillustrate multiple views of a model, icons representing a modelelement 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, usingfacilities provided by its application window. Within its applicationwindow, it displays each diagram in a diagram window and eachspecification 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 toreuse large- scale design assets developed in earlier modeling effortsby providing the possibility to add frame works in Rational Rose.

AIM: To create a Point of Sale System

STEP 1: Start the application

STEP 2: Create the require actors and use cases in the browserwindowSTEP 3: Goto new use case view and then click the use case view andopen a new packageSTEP 4: Rename the new package with the package with requirednamesSTEP 5: Create two packages actor and use case

Thus various UML Diagrams were generated for POINT OF SALE

UNIFIED MODELING LANGUAGE Page no:

ONLINE BOOK SHOP SYSTEM

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

ONLINE BOOK SHOP SYSTEM

ONLINE BOOKSHOP SYSTEM SPECIFICATIONS:

Objectives:

The purpose of this document is to define requirements of the

online bookshop system. This specification lists the requirements thatare not readily captured in the use cases of the Use case model. Thesupplementary specifications and the use case model together capturea 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:

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 Multiple users must be able to perform workconcurrently. The user must be notified about the stock of books in theinventory.

Reliability: The system shall be available 24 hrs a day and 7 days aweek.

Performance: • The system shall support large number of simultaneous users against the central database at any time. • The system shall provide access to catalog database with no more then ten seconds latency. • The system must be able to complete 80% of all transactions within 2 minutes.

Supportability: None

Brief Description of the Project:

The current project emphasizes on analysis and designof an online bookshop system. That serves the customers needs. Thecustomer’s available activities in the proposed system from logging onthe browsing the book store, selecting items and making purchasesare 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 becompetitive enough by providing the facilities/options that arecurrently provided by reputed systems like Amazon.com and BN.com.The proposed system should allow the customer with activities from

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110logging on to the system, browsing the book store, selecting items andmaking purchases i.e., the customer will be able to browse, select andbuy books online.

An internet customer should have a login to access the book store.

Registration of the customer with the book shop is primary. Aregistered customer can browse through the book catalogue and canmake selections. The new system should even assist the customer inlocating a book in that, the customer can browse the current bookcatalogue online and this should detail the book details and stockdetails 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 currentcategory, they should place an order and request the book. Thisincludes details like Author, Publishers, Title, Book Name andCategory. The payment is done through credit card and also throughgift cheques etc., the customer is informed about the transactiondetails through e-mails. The shipment details are entered by thecustomer and through those details the delivery is processed.

USE CASE The use case model describes the proposed functionality ofthe system. A use case represents a discrete unit of interactionbetween a user and the system. A use case is a single unit ofmeaningful work. Each use case has a description which describes thefunctionality that will be built in a proposed system. A use case may‘include’ another use case functionality or ‘extend’ another use casewith its own behavior.

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.

Modeling steps for Sequence Diagrams

1. Set the context for the interactions, system, subsystem,

classes, object or use cases.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 12206091102. Set the stages for the interactions by identifying objects whichare placed as actions in interaction diagrams.3. Lay them out along the X-axis by placing the important objectat the left side and others in the next subsequent.4. Set the lifelines for each and every object by sending createand destroy messages.5. Start the message which is initiating interactions and place allother messages in the increasing order of items.6. Specify the time and space constraints.7. Set the pre and post conditioned.

Modeling steps for Collaboration Diagrams

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

subsystem, operation or class or one scenario of use case or collaboration. 2. Identify the objects that play a role in the interaction. Lay them as vertices in graph, placing important objects in centre and neighboring objects to outside. 3. Set the initial properties of each of these objects. If the attributes or tagged values of an object changes in significant ways over the interaction, place a duplicate object, update with these new values and connect them by a message stereotyped as become or copy. 4. Specify the links among these objects. Lay the association links first represent structural connection. Lay out other links and adorn with stereotypes. 5. Starting with the message that initiates this interaction, attach each subsequent message to appropriate link, setting sequence number as appropriate. 6. Adorn each message with time and space constraints if needed 7. Attach pre & post conditions to specify flow of control formally.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

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

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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 8. Check that all states are reachable under some combination of events. 9. Check that no state is a dead from which no combination of events will transition the object out of that state. 10.Trace through the state machine, either manually or by using tools, to check it against expected sequence of events & their responses.

Modeling steps for Class Diagrams

1. Identity the things that are interacting with class diagram.

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

Modeling steps for Object Diagrams

1. Identify the mechanisms which you would like to model.

2. Identify the classes, use cases, interface, subsystem which are collaborated with mechanisms. 3. Identify the relationship among all objects. 4. Walk through the scenario until to reach the certain point and identify the objects at that point. 5. Render all these classes as objects in diagram. 6. Specify the links among all these objects. 7. Set the values of attributes and states of objects.

Modeling steps for Component Diagrams

1. Identify the component libraries and executable files which

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

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 5. Represent files,tables,documents as components. 6. Show the existing relationships among them generally dependency. 7. Identify the seams in the model. 8. Identify the interfaces which are interacting with the system. 9. Set attributes and operation signatures for interfaces. 10.Use either import or export relationship in b/w interfaces & components. 11.Identify the source code which is interacting with the system. 12.Set the version of the source code as a constraint to each source code. 13.Represent source code as components. 14.Show the relationships among components. 15.Adorn with nodes, constraints and tag values.

Modeling steps for Deployment Diagram

1. Identify the processors which represent client & server.

2. Provide the visual cue via stereotype classes. 3. Group all the similar clients into one package. 4. Provide the links among clients & servers. 5. Provide the attributes & operations. 6. Specify the components which are living on nodes. 7. Adorn with nodes & constraints & draw the deployment diagram.

CLASS DIAGRAM: A Class is a standard UML construct used to detail thepattern from which objects will be produced at run time. A class is aspecification- an object is an instance of a class. Classes may beinherited from other classes, have other classes as attributes, delegateresponsibilities to other classes and implement abstract interfaces. The class diagram for the proposed system has severalclasses. These classes have attributes and operations. The descriptionfor each of them is described clearly.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

Collaboration names a society of classes, interfaces and other

elements that work together to provide some cooperative behaviorthat is bigger than the sum of all its parts. Collaboration diagramemphasis is based on structural organization of the objects that sendand receive messages.

databa 14: confirm selection

se 2: manages invent ory

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

STATE CHART DIAGRAM:

Objects have behaviors and state. The state of

an object depends on its current activity or condition. A state chartdiagram shows the possible states of the object and the transitionsthat cause a change in state. The initial state (black circle) is a dummyto start the action. Final states are also dummy states that terminatethe action.

An activity diagram is essentially a fancy flowchart. Activity

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

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110diagram focuses attention on an object undergoing a process (or on aprocess as an object), an activity diagram focuses on the flow ofactivities involved in a single process. The activity diagram shows thehow those activities depend on one another. Activity diagrams can bedivided into object swim lanes that determine which object isresponsible for which activity. A single transaction comes out of eachactivity, connecting it to the next activity.

display welcome msg

get login

get pwd rejected

and validate

accepted display item

info

accept selection more selections

completed display create order order for cart

acceptance rejected

ship to customer

COMPONENT DIAGRAM:

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 A component is a code module. Component diagramsare physical analogs of class diagram. Each component belongs on anode. Components are shown as rectangles with two tabs at the upperleft.

Deployment diagram shows the physical configurations of

UNIFIED MODELING LANGUAGE Page no:

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

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

AN ONLINE AUCTION SALE

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

AN ONLINE AUCTION SALE

Aim: To create a case study on ONLINE AUCTION

Overview:

The online auction system is a design about a website where sellers

collect and prepare a list of items they want to sell and place it on thewebsite for visualizing. To accomplish this purpose the user has toaccess the site. Incase it’s a new user he has to register. Purchaserlogs 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 ofthe auction is declared as the owner of the item. If the auctioneer orthe purchaser does not want to bid for the product then there is fixedcutoff price mentioned for every product. He can pay the amountdirectly and own the product. The purchaser gets a confirmation of hispurchase as an acknowledgement from the website. After thetransaction by going back to the main menu where he can view otheritems.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110As per case study, the following analysis diagrams will be created.

1. Use cases for the system.

2. Class diagram for initially identified classes. 3. Activity diagram to show flow of each use case. 4. Sequence and collaboration diagrams. 5. State chart diagram shows states before and after each action.

Conceptualization:

Assumptions:

• The users are allowed to register and give user id’s to have identification. • The users are allowed to bid for any price according to their wish provided it’s more than the minimum price of auction. • The fixed cut-off price is decided and confirmed for every product. • The auctioneer requesting the product for the cut-off price is given priority. • The auctioneer bidding the maximum price is given the product.

Inputs:

• The login details of the auctioneer.

• List of available products on the site. • Details such as specifications and the price of each product. • Bidding price of the auctioneer.

Outputs:

• The cut-off price for each product.

• Updated status of bid price. • Status of each product if it is bid or sold for sale. • Acknowledgement to whom the product is sold.

UNIFIED MODELING LANGUAGE Page no:

Use Cases In Purchaser’s Diagram:

1. Validate User 2. Record chatting.

ALGORITHMIC PROCEDURE:

STEP 1: Start the application

STEP 2: Create the require actors and use cases in the browser window STEP 3: Got new use case view and then click the use case view and Open a new package STEP 4: Rename the new package with the package with required Names STEP 5: Create two packages actor and use case

DIAGRAMS:

Modeling steps for Use case Diagram

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

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. 7. Set the pre and post conditioned.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

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

Modeling steps for State chart Diagram

1. Choose the context for state machine, whether it is a

class, a use case, or the system as a whole. 2. Choose the initial & final states of the objects. 3. Decide on the stable states of the object by considering the conditions in which the object may exist for some identifiable period of time. Start with the high-level states of the objects & only then consider its possible substrates. 4. Decide on the meaningful partial ordering of stable states over the lifetime of the object. 5. Decide on the events that may trigger a transition from state to state. Model these events as triggers to transitions that move from one legal ordering of states to another. 6. Attach actions to these transitions and/or to these states. 7. Consider ways to simplify your machine by using substates, branches, forks, joins and history states. 8. Check that all states are reachable under some combination of events. 9. Check that no state is a dead from which no combination of events will transition the object out of that state. 10.Trace through the state machine, either manually or by using tools, to check it against expected sequence of events & their responses.

Modeling steps for Class Diagrams

1. Identity the things that are interacting with class

diagram. 2. Set the attributes and operations.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 3. Set the responsibilities. 4. Identify the generalization and specification classes. 5. Set the relationship among all the things. 6. Adorn with tagged values, constraints and notes.

Modeling steps for Object Diagrams

1. Identify the mechanisms which you would like to

model. 2. Identify the classes, use cases, interface, subsystem which are collaborated with mechanisms. 3. Identify the relationship among all objects. 4. Walk through the scenario until to reach the certain point and identify the objects at that point. 5. Render all these classes as objects in diagram. 6. Specify the links among all these objects. 7. Set the values of attributes and states of objects.

Modeling steps for Component Diagrams

1. Identify the component libraries and executable files

which are interacting with the system. 2. Represent this executables and libraries as components. 3. Show the relationships among all the components. 4. Identify the files, tables, documents which are interacting with the system. 5. Represent files,tables,documents as components.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 6. Show the existing relationships among them generally dependency. 7. Identify the seams in the model. 8. Identify the interfaces which are interacting with the system. 9. Set attributes and operation signatures for interfaces. 10.Use either import or export relationship in b/w interfaces & components. 11.Identify the source code which is interacting with the system. 12.Set the version of the source code as a constraint to each source code. 13.Represent source code as components. 14.Show the relationships among components. 15.Adorn with nodes, constraints and tag values.

Modeling steps for Deployment Diagram

1. Identify the processors which represent client & server.

2. Provide the visual cue via stereotype classes. 3. Group all the similar clients into one package. 4. Provide the links among clients & servers. 5. Provide the attributes & operations. 6. Specify the components which are living on nodes. 7. Adorn with nodes & constraints & draw the deployment diagram.

Aim: to create a Multi- Threaded Airport Simulation

STEP 1: Start the application

STEP 2: Create the require actors and use cases in the browser window STEP 3: Go to new use case view and then click the use case view and Open a new package STEP 4: Rename the new package with the package with required Names

UNIFIED MODELING LANGUAGE Page no:

A critical step of the project is to design a modeling and

simulation infrastructure to experiment and validate the proposedsolutions The ever growing demand of air transport shows thevulnerability of the current air traffic management system:Congestion, time delays, etc.particularly in poor whether conditions. The project is focused on controller and pilot assistancesystems for approach and ground movements. The critical step of theproject was to design an airport modeling and simulation infrastructureto improve the safety and efficiency of ground movements in allwhether conditions. It simulates the arrivals and departures at anairport in a time sequence. During every minute, planes may enter thesystems, they may land, they may take off, or they may crash. Theproject must keep track of planes, assign planes to runways, executethe take offs and landings, and keep track of status of each plan,runway and terminal. So the finally made computer software should modelvarious aspects of the total airports operation-connecting airside andlandside, 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;

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 • All take offs take the same amount of time and all landings take the same amount of time (through these two times may be different). • Planes arrive for landing at random times, but with a specified probability of a plane arriving during any given minute. • Planes arrive for take off at random times, but with a specified probability of a plane arriving during any given minute • Landings have priorities over takeoffs.

• Planes arriving for landing have a random amount of fuel and

they will crash if they do not land before they run out of fuel.Input will be: • The amount of time needed for one plane to land. • The amount of time needed for one plane to takeoff. • The probability of a plane entering the landing queue in any given minute. • The probability of a plane entering the takeoff queue in any given minute. • The maximum minutes until a plane waiting to land will crash. • The statues of each runway, plane and terminal.The Output of the program will be: • Total simulation time. • The number of planes that takeoff in the simulated time. • The number of planes that landed in the simulated time. • The average time a plane spent in the takeoff queue. • The average time a plane spent in the landing queue. • Updated status of each runway, plane, and terminal.Key terms:  Aircraft simulation.  Airport: runways, terminals, planes, control room.  Aircraft: passengers, model no. cockpit, pilots.  Function points:

Textual Analysis: This covers the requirements and diagrams of the project. Thecomplete 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 usecases. • Transmit/receive signals. • Check availability of runways.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 • Land the plane. • Check if time left for next departure. • Check for free terminal. • Update status of runway, terminal. 1. Transmit/receive signals: The pilot in the aircraft transmits signals for requesting a free runway to takeoff or land. The control room on the ground receives these signals from the aircrafts. 2. Check availability of runway: The status of each runway in the airport is checked if it’s free and its going to be free until the particular aircraft is landed or takeoff. If this is going to be free then runway number is transmitted to the pilot on aircraft. 3. Land the plane: The plane is landed safely on the airport as per directions given by the control room regarding runway and timings. 4. Check if time left for next departure: If the plane leaves immediately after landing then assign again a runway for takeoff. If there is still time then the plane has to be parked in a terminal. 5. Check availability of terminals: the status of each terminal is to be checked to find a free terminal. It should be checked whether that particular model of plane fits into that terminal. Then that particular terminal has to be assigned to the plane. 6. Update Status: the status of runway and terminal are to be set to be using while using them. The status has to be immediately changed as soon as the work is complete. This should be supervised carefully to avoid collisions and crashes of aircrafts.Classes: The classes contain the attributes and operations related to themthe 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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 2. Plane Cockpit: He is the person who controls the aircraft. He transmits or receives signals regarding the free runways and terminals from the control room. He is responsible for the safe landing or takeoff of the plane. 3. Runway: This is the part the planes use to land or takeoff only one plane can use runway at a time to takeoff or land. 4. Terminal: This is the place where the planes are parked until the next departure. The terminal is to be parked in it. 5. Takeoff/land: The leaving of planes is called takeoff and coming back to runway is called landing. The runway is used for either purpose.Diagrams: Class Diagram A Class is a standard UML construct used todetail the pattern from which objects will be produced at run time. Aclass is a specification- an object is an instance of a class. Classes maybe inherited from other classes, have other classes as attributes,delegate responsibilities to other classes and implement abstractinterfaces.Classes of airport simulation are:Class Attributes OperationsControl 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

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110Plane Cockpit -No of pilots +Send signal to ground -Flight no station() -Destination +Receive runway no() -Timings +Land on runway() +Request terminal if time left for next departure() +Receive terminal no() +Get the plane parked in the terminal()Terminal -No of runways -Size of terminal ------------------- -Flight model which ------ fits in -Status of terminalRunway -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 ofinteraction between a user and the system. A use case is a single unitof meaningful work. Each use case has a description which describesthe functionality that will be built in a proposed system. A use casemay ‘include’ another use case functionality or ‘extend’ another usecase with its own behavior. Actors Use casesTechnical head .Transmit/Receive signals .Look for free runway

Terminal .Get the plane into the free

Sequence diagram

UML provides a graphical means of depicting object

interactions over time in sequence diagrams. These typically show a user or actor and the objects and components they interact with in the execution of a use case. 1. Technical head: He is the person who supervises the controls the ground traffic on runway. He checks the status of runways and assigns free terminals for takeoff and landing. 2. Pilot: He is the person who controls the aircraft. He transmits or Receives signals regarding the free runways and terminal from the control room. He is responsible for the safe landing or takeoff the planes.

Objects 1. Runway: This is the path the plane uses to land or takeoff. Only one plane can use a runway at a time takeoff or landing.

UNIFIED MODELING LANGUAGE Page no:

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

Collaboration names a society of classes,

interfaces and other elements that work together to provide some cooperative behavior that is bigger than the sum of all its parts. Collaboration diagram emphasis is based on structural organization of the objects that send and receive messages.

Activity Diagram

An activity diagram is essentially a fancy flowchart.

Activity diagrams and state chart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (oron a process as an object), an activity diagram focuses on the flow ofactivities involved in a single process. The activity diagram shows the how thoseactivities depend on one another. Activity diagrams can be divided intoobject swim lanes that determine which object is responsible for which

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110activity. A single transaction comes out of each activity, connecting itto the next activity.State Chart Diagram Objects have behaviors and state. The state of an objectdepends on its current activity or condition. A state chart diagramshows the possible states of the object and the transitions that cause achange in state. The initial state (black circle) is a dummy to start theaction. Final states are also dummy states that terminate the action.Component Diagram A component is a code module. Component diagrams arephysical analogs of class diagram. Each component belongs on a node.Components are shown as rectangles with two tabs at the upper left.

UNIFIED MODELING LANGUAGE Page no:

Result: The various UML diagrams were drawn for AIRPORTSIMULATION SYSTEM application and the corresponding code wasgenerated.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

A SIMULATED COMPANY

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

A SIMULATED COMPANY

OVERVIEW:

A critical step of the project is to design a modeling and simulation

infrastructure to experiment and validate the proposed solutions.Simulated company is an example that shows the documents producedwhen undertaking the analysis and design of an application thatsimulates a small manufacturing company. This application is calledsimco: Simulated Company. The project if focused on the user to take lend, purchase amachine and over a series of monthly and yearly production runsfollows the concept of the company. The company has to see all thetakings and the losses. They have to see all dealings of the companyand see the additional features of the machine for better development. The company accounts are updated for a given month. Theaccounts take into the gross profits from the sales. General expensessuch as salary and rent are taken into account to calculate the netprofit for the company. In addition details such as inventory and salesare updated. As part of the case study, following analysis diagrams will beupdated.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 ○ Usecase for the system ○ Class diagram for initially identified classes. ○ Activity diagram to show flow for each use case. ○ Sequence and collaboration diagrams. ○ Statechart diagram shows states before and after each action.

Conceptualization:

Assumptions:

The company has to take the loan and repay the loan.It has to purchase machinery and start the production.The sales person has to sell the foods and update the details in therecord.The sales has to submit the record and stock details required.The performance department has to prepare record statistics as givenby marketing department.The performance department has to get collected details from all thedepartments and submit to the company.

Inputs:

 The amount of time required for sanctioning the loan.

 The amount of time needed for the production.  The probability for estimating the machinery cost and raw materials.  The probability of estimating profit and loss.

Outputs:

 Total time required in completing a project.

 The number of goods manufactured in a simulated time.  Number of sales done in a project.  Getting profit and loss for every month.  Case study of the project.

Key Terms:

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

Pay loan/repay loan

Purchase machinery and start production.Sell the products and updated the records.The performance department has to update the statistics and to thecompany.

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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 6. Specify the time and space constraints. 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.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110 3. Identify the precondition of initial state and post conditions of final state. 4. Beginning at initial state, specify the activities and actions and render them as activity states or action states. 5. For complicated actions, or for a set of actions that appear multiple times, collapse these states and provide separate activity diagram. 6. Render the transitions that connect these activities and action states. 7. Start with sequential flows, consider branching, fork and joining. 8. Adorn with notes tagged values and so on.

Modeling steps for State chart Diagram

1. Choose the context for state machine, whether it is a class, a use case, or the system as a whole. 2. Choose the initial & final states of the objects. 3. Decide on the stable states of the object by considering the conditions in which the object may exist for some identifiable period of time. Start with the high-level states of the objects & only then consider its possible substrates. 4. Decide on the meaningful partial ordering of stable states over the lifetime of the object. 5. Decide on the events that may trigger a transition from state to state. Model these events as triggers to transitions that move from one legal ordering of states to another. 6. Attach actions to these transitions and/or to these states. 7. Consider ways to simplify your machine by using sub states, branches, forks, joins and history states. 8. Check that all states are reachable under some combination of events. 9. Check that no state is a dead from which no combination of events will transition the object out of that state. 10.Trace through the state machine, either manually or by using tools, to check it against expected sequence of events & their responses.

UNIFIED MODELING LANGUAGE Page no:

GITAM INSTITUTE OF TECHNOLOGY NAME: T. JAHNAVI ROLL NO: 1220609110

Modeling steps for Class Diagrams

1. Identity the things that are interacting with class diagram.

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

Modeling steps for Object Diagrams

1. Identify the mechanisms which you would like to model. 2. Identify the classes, use cases, interface, subsystem which are collaborated with mechanisms. 3. Identify the relationship among all objects. 4. Walk through the scenario until to reach the certain point and identify the objects at that point. 5. Render all these classes as objects in diagram. 6. Specify the links among all these objects. 7. Set the values of attributes and states of objects.

Modeling steps for Component Diagrams

1. Identify the component libraries and executable files which

are interacting with the system. 2. Represent this executables and libraries as components. 3. Show the relationships among all the components. 4. Identify the files, tables, documents which are interacting with the system. 5. Represent files,tables,documents as components. 6. Show the existing relationships among them generally dependency. 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.

UNIFIED MODELING LANGUAGE Page no:

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