INDEX

1. Unified modeling language 2. Use case Introduction 3. Use case diagram a. Use case of ATM machine b. Use case of Library management c. Use case of Railway Reservation System 4. Class introduction 5. Class diagram a. Class diagram of collage management system b. Class diagram of Hospital Management system c. Class diagram of Library management system 6. Interactive diagram Introduction 7. Interactive diagram a. Interactive diagram for ATM machine b. Interactive diagram for Library Management system c. Interactive diagram for Railway Reservation system 8. Collaboration introduction 9. Collaboration diagram a. Collaboration diagram for ATM machine b. Collaboration diagram for Library machine c. Collaboration diagram for Railway Reservation machine 10. State machine diagram 11. State chart diagram for CD player 12. Activity diagram introduction 13. Activity diagram a. Activity diagram of ATM without swinlanes b. Activity diagram of ATM with swinlanes 14. Component diagram introduction 15. Component diagrams a. Component diagram for ATM System b. Component diagram for Hospital Management System 16. Deployment diagram 17. Deployment diagram for ATM system 18. Forward engineering 19. Reverse engineering 20. Case study a. Bank ATM System b. Cellular phone Network c. Student course registration system d. Hospital Management System e. Library Information system f. Ticket vending system g. Trading system 2 8 10 11 12 13 16 17 18 19 22 23 24 25 26 27 28 30 32 33 35 36 37 41 42 43 44 45 54 61 69 79 88 97 107 115

1 UNIFIED MODELING LANGUAGE

UML is a graphical notation used to visualize, specify, construct and document the artifact of software intensive. UML is appropriate for modeling systems ranging from Enterprise Information Systems to Distributed Web-based Application and even to Hard Real-time Embedded systems. UML effectively starts with forming a conceptual modeling of the language.

There are 2 types of diagrams. They are, 1. Static Diagrams a) Use case diagrams b) Class diagrams c) Object diagrams d) Component diagrams e) Deployment diagrams 2. Dynamic diagrams a) Interaction diagrams i) Sequence diagrams ii) Collaboration diagrams b) State machine diagrams i) State chart diagrams ii) Activity diagrams Applications of UML: UML is intended primarily for software intensive systems. It has been used effectively for such domains as 1. Enterprise Information Systems

2. 3. 4. 5. 6. 7. 8. 9.

Banking and Financial Services Telecommunications Transportation Defense and Aerospace Retail Medical Electronics Scientific Distributed Web-based Services

Basic building blocks of UML: The building blocks of UML can be categorized as 1. Things 2. Relationships and 3. Diagrams Things:Things are the most important building blocks of UML. Things can be a) b) c) d) Structural Behavioral Grouping Annotational

a) Structural Things: They define the static part of the model. They represent physical and conceptual elements. Following are the structural things 1. Class: - It describes a set of objects that share the same attribute operations, relationships and semantics.
Class name Attributes Operations

2.Object: - It is a collection of operations that specifies a service of a class or a component.

3. Collaboration: - It defines interaction between elements.

4. Use case: - They are used to identify different use case components of a particular software project. It is used to model the operation.

5. Component: - It is a physical and replaceable part that confirms to and provides realization of set of interfaces.

6. Node: - A physical resource that exists in runtime and represent a computational resource.

7. Actor: - The out side entity that communicates with a system. Typically a person playing a role on an external device.

b) Behavioral Things: They consist of dynamic parts of the UML model. The following are behavioral things 1. Interaction: - It is defined as a behavior that consists of a group of message exchanged among elements to accomplish a specific task.
message

2. State machine: - It is useful when the states of an object in its life cycle. It defines the sequence of states and object goes through in response to events.

c) Grouping Things: They can be defined as a mechanism to group elements of UML model together. There is only one grouping thing available i.e., Package. Package is used for gathering structural and behavioral things.

d) Annotational Things: - They can be defined as a mechanism to capture remarks, description and comments of UML model elements. There is only one annotational thing available i.e., Note. Note is used to render comments, constraints and so on of a UML element.

Relationships: The relationship is another most important building block of UML. They show how elements are associated with each other and their association describes the functionality of application. There are 5 types of relationships. They are, 1. Dependency: It is a relationship between two things in which change in one element also affects another.

2. Generalization: It can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the object. It is a is_a hierarchy.

3. Realization: It can be defined as a relationship in which two elements are connected. One element describes some responsibility which is not implemented and the other one implement then. This relationship exists in case of interfaces.

4. Association: It is a set of links that connects elements of an UML model. Two types of associations a) Unidirectional b) Bidirectional c) 5. Aggregation: It is a has_a relationship. It is of two types as a) Simple aggregation b) Composition aggregation

UML Diagrams: 1. Class diagram 2. Use case diagram 3. Interaction diagram i) Sequence diagram ii) Collaboration diagram 4. State machine diagram i) State chart diagram ii) Activity diagram 5. Component diagram 6. Deployment diagram

2. USE CASE DIAGRAMS

A use case diagram describes a set of sequences in which each sequence indicates the relation with outside things. A use case involves the interaction of actor and system. There exist 3 types of relationships1. Association 2. Dependency 3. Generalization Use case diagrams can contain Actors things outside the system Use cases system boundaries identifying what the system should do. Use case diagram can be used during analysis to capture the system requirements and to understand how the system should work. During the design phase, you can use use-case diagrams to specify the behavior of the system as implemented. Actor:Actor represents system users. They help delimit the system requirements and give a clearer picture of what the system should do. An actor is someone or something that Interacts with or uses the system. Provides input to and receives information from the system. Is external to the system and has no control over the use cases.

Customer (actor)

Actors are discovered by examining, Who directly uses the system Who is responsible for maintaining the system? External hardware used by the system.

 Other systems that need to interact with the system.

Use case: A use case can be described as a specific way of using the system from users (actors) perspective. Use case can be characterized as A pattern of behavior the system exhibits. A sequence of related transactions performed by an actor and the system. Delivering something of value to the actor.

Transfer Funds

Note: Use cases often start with a verb.

Use cases provide a means to, Capture system requirements. Communicate with end users and domain experts. Test the system.

TICKET VENDING SYSTEM

Problem Statement: A Ticket Vending System(TVM) dispenses tickets to passengers at a railway station.Passengers use the front panel to specify their Boarding and destination place,details of passengers(number of adults and children) and date of travel.The machine displays the fare for the requested ticket.The passengers then deposits cash in the bin provided and presses accept cash.The machine checks the cash,if it is more,the balance cash is paid out.And the ticket requested is printed.The system is also used by the operator who might want to knowthe cash held in the machine,the break-up of small change available in the machine,withdraw or deposit cash when need.And the report options also include the detailed report of trasactions,summary report of the number of tickets sold for each destication,opening balance,each collected,cash dispensed and current balance in the machine.

Functional Requirements:

Specify Ticket details:Initiated by the passengers and gives the following details:Destination place,date of journey,passengers details(adults,child) and coach details. Buy ticket:Initiated by the passenger to buy ticket,the passenger pays cash and presses accept cash button.the system checks out the cash and print out the ticket and dispense the balance if any.The system also updates the records to reflect the number of tickets to each designation,the total cash collected,total cash dispensed,current balance etc., Summary report:Initiated by the operator to know the summary of the total business transacted for the day,the cash collected and balance cash available in the system. Get cash details: Initiated by the operator to get a denomination wise number of notes and coins available with the machine at that time. The operator connects from a remote place to vending machine to get cash details.

Withdraw cash: Initiated by the operator to withdraw cash from the machine. The operator connects to the machine locally and the machine dispenses cash. Deposit cash :Initiated by the operator to deposit cash in the machine. The operator connects to the machine locally and specifies the amount to be deposited with the denomination details. Check Master files: Initiated by the system administrator. System administrator can log in from a remote place and check the details of machine-id, user-id, password and ticket, balance details. Update Master: Initiated by the system administrator to update system details. Non Functional Requirements: a) System should be designed simple enough to enable operators to get summary reports,get chas details, withdraw cash and deposit cash without any delay. b)System must be secured and protected from passengers and other unauthorized users. A passenger is allowed only to enquire ticket details and buy ticket. c)System Administrator must only check and update master files. d)System must handle Network and power failure. e)System must be efficient to use and provide quick recover from the fault. f) Software must validate and cancel operation in case of incorrect passenger details,incomplete transaction, and time delay and return failure. g)User interface screen must be designed to operate easily. It should have visual appealing.

Usecase Diagram For Ticket Vending System

specific ticket details Passenger Buy ticket check master files Summary report System Administrators

Get cash Details Operator

Update master files

Withdraw cash

Deposit Cash

3. CLASS DIAGRAMS

The class diagram contains icons representing classes, interfaces and their relationships. Class:A class is a set of objects that share a common structure and common behavior (the same attributes, operations and semantics). A class is a abstraction of real-world items. When these items exist in the realworld, they are instances of the class and are referred to as objects. A class icon is a 3-part box.
Class name Attributes Operations

1. Generalize relationship for classes: It shows that sub classes share the structure or behavior defined in one or more super classes. Use a generalize relationship to show is_a relationship.
Super class

Sub class 1

Sub class2

2. Dependency Relationship: The dependency is a relationship between two model elements in which change in one element will affect the other model element. Typically on class diagrams, a dependency relationship indicates that the operations of the client invoke operation of the supplier.

Cardinality Adornment:- Cardinality specifies how many instances of one class may be associated with single instance of other class. When you apply a cardinality adornment to a class, you are indicating number of instances allowed for that class. A relationship, you are indicating number of links allowed between one instance of a class and the instances of another class. Valid Values: Value Description 0..0 zero 0..1 zero or one 0..n zero or more 1..1 one 1..n one or more n unlimited number Interface:-An interface specifies the externally visible operations of a class and/or component, and has no implementation of its own. An interface specifies only a limited part of behavior of class or a component. 3. Association relationship: An association provides a pathway of communications. The communication can be between use cases, actors, classes or interfaces. If two classes are usually considered independently, the relationship is an association.
Unidirectional Bi directional

An association is an orthogonal or straight solid line with an arrow at one end.

Customer

Transfer funds

4. Aggregate relationship: Use the aggregate relationship to show a whole or part relationship between two classes.
Unidirectional aggregation Bidirectional aggregation

The diamond end designates the client class.

Supplier A Client Suppler B

Class Diagram For Ticket Vending System

4. INTERACTION DIAGRAMS

An interaction is an important sequence of interactions between objects. There are two types of interaction diagrams, a) Sequence Diagrams. b) Collaboration diagrams. 1. Sequence Diagrams: A sequence diagram is a graphical view of a scenario that shows object interaction in a time based sequence, what happens first, what happens next. Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces. A sequence diagram has two dimensions: vertical placement represents time and horizontal placement represents different objects. Link: Objects interact through their links to other objects. A link is an instance of an association, analogous to an object being instance of a class. A link should exist between two objects, including class utilities, only if there is a relationship between their corresponding classes.

Message icons: A message icon represents the communication between objects indicating that an action will follow. The message icon is a horizontal, solid arrow connecting two lifelines together.

A message icon in a sequence diagram represents exactly one message.

Lifeline: Each object appearing on the sequence diagram contains a dashed vertical line, called lifeline, which represents the location of an object at a particular point in time. The lifeline also serves as a place for messages to start and stop and a place for the focus of control to reside.

Lifeline

Message or Event: a message is a communication carried between two objects that trigger an event. A message is represented in collaboration and sequence diagrams by a message icon which usually indicates its synchronization. Synchronization types that are supported. 1. 2. 3. 4. 5. 6. 7. Simple Synchronous Balking Time out Asynchronous Procedure call Return

Message to self: It is a tool that sends a message from one object back to the same object. The sender of the message is same as the receiver.

Tools: 1. Object

2. Object message 3. Message to self

4. Return message 5. Destruction marker

5. Sequence Diagram For Ticket Vending System

Passenger : P

Front Panel

Ticket transacter

Requisitio nslip

Farecalcul ator

1: Ticket Request 2: Generate Request 3: PrepareSlip 4: Get Fare 5: Fare 7: Fare 8: Indicate Fare 6: Fare

6. Collaboration diagrams

A collaboration diagram is an interaction diagram that shows the order of messages that implement an operation or a transaction. Collaboration diagrams show objects, their links, and their messages. They can also contain simple class instances and class utility instances. Each collaboration diagram provides a view of the interactions or structural relationships that occur between objects and object-like entities in the current model. Collaboration diagrams contain icons representing objects. The Create Collaboration Diagram Command creates a collaboration diagram from information contained in the sequence diagram. The Create Sequence Diagram Command creates a sequence diagram from information contained in the interaction's collaboration diagram. The Goto Sequence Diagram and Goto Collaboration Diagram commands traverse between an interaction's two representations.

7. Collaboration Diagram For Ticket Vending System

1: Ticket Request Front Panel Passenger : P 8: Indicate Fare

2: Generate Request Ticket transacter 7: Fare

6: Fare 3: PrepareSlip

4: Get Fare Requisiti onslip 5: Fare Farecalc ulator

8. STATE-MACHINE DIAGRAMS There are two types of state-machine diagrams: 1. State chart diagram 2. Activity diagram 1. State chart diagram: state chart diagrams model the dynamic behavior of individual classes or any other kind of object. They show the sequence of states that an object goes through the events that cause a transition from one state to another and the actions that result from a state change. A state chart diagram is typically used to model the discrete stages of an objects lifetime. A state chart diagram typically contains one start state and multiple end states. 1. State :- A state represents a condition or situation during the life of an object during which it satisfies some condition or waits for an event. Each state represents a cumulative history of its behavior. States can be shared between state machines. Transitions cannot be shared.

Naming: The name of the state must be unique to its enclosing class, within the state. Actions: Actions on states can occur at one of four times On entry On exit Do On event 2. Start state:- A start state (also called an initial state) explicitly shows the beginning of the execution of the state machine on the state chart diagram or beginning of the workflow on an activity diagram.

Normally, one outgoing transition can be placed from the start state. However, multiple transitions may be placed on start state, if at least one of them is labeled with a condition. No incoming transitions are allowed. The start state icon is a small, filled circle that may contain the name (Begin process).
Begin process

3. End state:- An end state represents a final or terminal state on an activity or state chart diagram.. Transitions can only occur into an end state. The end state icon is a filled circle inside a slightly larger unfilled circle that may contain the name (End process).

End process

4. State transition:- A state transition indicates that an action in the source state will perform certain specified actions and enter the destination state when a specified event occurs or when certain conditions are satisfied. A state transition is a relation ship between two states, two activities or between an activity or a state. The icon for a state transition is a line with an arrow head pointing toward the destination state or activity.

We can show one or more state transitions from a state as long as each transition is unique. Transitions originating from a state cannot have the same event, unless there are conditions on the event. Naming: We should label each state transition with the name of at least one event that causes the state transition. We do not have to use unique labels for the state transitions because the same event can cause a transition to many different states or activities.

Tools: 1. State

2. Activity

3. Start state 4. End state 5. State transition 6. Transition to self 7. Horizontal synchronization

8. Vertical synchronization

9. Decision

10. Swimlanes

12.Activity diagram:- An activity diagram is a special case of state diagram. An activity diagram is like a flow chart showing the flow a control from one activity to another. An activity diagram is used to model dynamic aspect of the system. Activity diagram contains: 1. Activity states and action states 2. Transition 3. Object Action state:- These are atomic, executable computation which represents the execution of an action.

Activity state:- They can be decomposed. That is, their activity is represented by other activity diagrams.

Branching:- In branching, we have one incoming transition and two or more outgoing transitions.
Decision

Forking and Joining:Forking:- It is a process of splitting a single flow of control into multiple flow of controls. Generally a fork has a single incoming flow of control but multi outgoing flow of control.

Joining:- It is exactly opposite of forking. It generally has multiple incoming flows of control but single outgoing flow of control.

Swim-lanes:- They represent the columns in the activity diagram to group the related activities. These are represented in the form of partitioned region. Swim-lanes are helpful when modeling a business work flow because they can represent organizational units or role with in a business model. Swim-lanes are very similar to an object because they provide a way to tell who is performing a certain role.

9. Activity Diagram For Ticket Vending System

Start

specify ticket details

Check master files

Ticket Available Buy Ticket

Tickets not available

Get cash details

Pay cash

Update master Files

10. COMPONENT DIAGRAMS They provide a physical view of the current model. A component diagram shows the organizations and dependencies among software components, including source code component, binary code component, and executable component. These diagrams also show the externally visible behavior of the component by displaying the interfaces of the components. Component diagrams contain: 1. Component package 2. Components 3. Interfaces 4. Dependency relationship 1. Component package:- component package represents clusters of logically related components, or major pieces of our system. Component packages parallel the role played by logical packages for class diagrams. They allow us to partition the physical model of the system. Typically, a component package name is the name of a file system directory. The component package is a folder shaped icon.

2. Components:- A component represents a software module (source code, binary code, executable, dll, etc.) with a welldefined interfaces. The interfaces of the component are represented by one or several interfaces elements that the component provides. Components are used to show the compiler and runtime dependencies as well as interface and calling dependencies among software modules.

Interface circle attached to the component icon means that the component supports that particular interface. Component stereotypes:- A system may be composed of several software modules of different kinds (.exe files, .dll files etc). To distinguish different kinds of software modules from each other, component stereotypes are used. By default, the following stereotypes types of components are available. a) Main program b) Sub program c) Packages d) Tasks e) EXE f) DLL a) Package:- A software component of the type package consists of a specification module and an implementation module; the implementation module often referred to as body. By default, a class is declared in a package.

b) DLL:- A dll component stereotype represents a data link library (a .dll file).

c) Main program:- This component represents a file that contains the root of the program. There is only one main program component per program.

d) Sub program:- Sub program components corresponds to sub routine declarations. Sub programs generally contain single or grouped sub routines; they do not contain class definitions.

e) Task:- Task components represents package with independent thread of control. If task are compiled differently than regular packages, we can allocate a class definition to a task.

f) EXE:- A component of the type EXE represents executable(.exe file).

3. Interface:- An interface specifies the externally-visible operations of a class or component and has no implementation of its own. An interface typically specifies only a limited part of behavior of a class or component. Interfaces belonging to the logical view but can occur in class, use case and component diagram.

4. Dependency relationship:- A dependency relationship between two model elements in which a change to one model element will affect the other model element. Use a dependency relationship to connect model elements with the same level of meaning.

11. Component Diagram For Ticket Vending System

Ticket Vending Main Ticket Vending Executable File

Operator

Passenger

TicketVendingDatabas e

Deposit Cash

Withdraw cash

Summary Report

Buy Ticket

Ticket Details

12. DEPLOYMENT DIAGRAM A deployment diagram shows processors, devices and connections. Each model contains a single deployment diagram which shows the connections between its processors and devices and its processes to processors. Processor:- A processor is a hardware component capable of executing programs. Each processor must have a name, there are no constraints on the processor name because processors denote hardware rather than software entities. The icon for processor is a shaded box.

Device:- A device is a hardware component with no computing power. Each device must have a name. Device names can be generic, such as modem or terminal. The icon of device is a box.

Connection:- A connection represents some type of hardware coupling between two entities. An entity is either a processor or a device. The hardware coupling can be direct such as an RS232 cable or indirect such as satellite-to-ground communication. Connections are usually bidirectional. The icon for connection is a straight line.

13. Deployment Diagram For Ticket Vending System

Ticket Vending Main Server

server1

server2

server3