INTRODUCTION TO UML Understanding UML Diagrams

Full text



UML is the industry standard modeling notation for object oriented systems, and is the premiere platform for rapid application development. In this chapter, we describe how UML came into being, introduce the concepts of object oriented programming, and show you how to use UML to structure your applications.

• Learning about the object oriented paradigm and visual modeling • Exploring types of graphical notation

• Looking at types of UML diagrams

• Developing software using visual modeling

Understanding UML Diagrams

UML allows people to develop several different types of visual diagrams that represent various aspects of the

system. Rational Rose supports the development of the majority of these models, as follows:

• Business Use Case diagram • Use Case diagram

• Activity diagram • Sequence diagram • Collaboration diagram • Class diagram • Statechart diagram • Component diagram • Deployment diagram

These model diagrams illustrate different aspects of the system. For example, the Collaboration diagram shows the required interaction between the objects in order to perform some functionality of the system. Each diagram has a purpose and an intended audience.



Rational Rose is a powerful visual modeling tool to aid in the analysis and design of object oriented software systems. It is used to model your system before you write any code, so you can be sure that the system is architecturally sound from the beginning. Using the model, you can catch design flaws early, while they are still inexpensive to fix. Rational Rose supports business modeling, helping you to understand the business around the system. It helps with systems analysis by enabling you to design use cases and Use Case diagrams to show the system functionality. It will let you design Interaction diagrams to show how the objects work together to provide the needed functionality. Class diagrams can be created to show the classes in a system and how they relate to each other. Component diagrams can be developed to illustrate how the classes map to

implementation components. Finally, a Deployment diagram can be produced to show the network design for the system.

A Rose model is a picture of a system from various perspectives. It includes all of the UML diagrams, actors, use cases, objects, classes, components, and deployment nodes in a system. It describes in great detail what the system will include and how it will work, so developers can use the model as a blueprint for the system being built.

A blueprint is a good analogy for a Rose model. Just as a house has a set of blueprints that let different members of the construction crew see it from different perspectives (plumbing, electrical, and so on), a Rose model contains a number of different diagrams that let the project team see the system from different perspectives (customer, designer, project manager, tester, and so on).



Definition :

Use – case diagrams graphically depict system behavior (called use cases). These diagrams present a high level view of how the system is used as viewed from an outsider’s (actor’s) perspective. A use case diagram may depict all or some of the use cases of a system.

Utility of Use Case Diagram : A detailed description might characterize a use case 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.

Use case diagrams provide a means to : • Capture system requirements.

• Communicate with the end users and domain experts • Test the system

Since all the needs of a system typically cannot be covered in one use case , it is usual to have a collection of use cases . Together this use case collection specifies all the ways of using the system.














Sequence diagrams are Interaction diagrams that are ordered by time; you read the

diagram from the top to the bottom. As we mentioned above, each use case will have a number of alternate flows. Each Sequence diagram represents one of the flows through a use case.The objects that participate in the flow are shown in rectangles across the top of the diagram.

Each object has a lifeline, drawn as a vertical dashed line below the object. The lifeline begins when the object is instantiated and ends when the object is destroyed. A message is drawn between the lifelines of two objects to show that the objects communicate. Each message represents one object making a function call of another.

Later in the process, as we define operations for the classes, each message will become an operation.Messages can also be reflexive, showing that an object is calling one of its own operations.





O p e ra to r B a r c o d e re a d e r s tud e nt info c o ntro lle r B o o k info c o ntro lle r

M e ssa ge b o xstud e nt d e ta ilsre turn b o o kB o o k d e ta ils re a d b a rc o d e

s ub m it b a rc o d e ge t d e ta ils

s ub m it b o o k c o d e v a lid a te d e ta ils

c he c k a va ilib ility inva lid s tud e nt

no t a va ila b le a d d re c o rd a d d re c o rd s ub m it v a lid a te if fine up d a te up d a te b o o k re turn s uc c e ss ful is s ue s uc c e s s



student registrar account


scrutiny officer request for the course

prompt for form submission submit form details

form verification

if valid

check student details

return details to registrar prompt for fee submission

submit fees

confirm fee submition grant admission letter

request for cancellation

verification of details confirm details forward student details




A class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces.

A class diagram is a pictorial representation of the detailed system design.

A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system.

Elements of a Class Diagram

A class diagram is composed primarily of the following elements that represent the system's business entities:

Class: A class represents an entity of a given system that provides an

encapsulated implementation of certain functionality of a given entity. These are exposed by the class to other classes as methods. Apart from business

functionality, a class also has properties that reflect unique features of a class. The properties of a class are called attributes.

A class is represented by a rectangle. The following diagram shows a typical class in a class diagram:

We can apply access modifiers such as public access, protected access, and private access applied to methods and attributes of a class—even to a class as well, if required. These access modifiers determine the scope of visibility of the class and its methods and attributes.

We can add documentation information to a class. Notes and constraints can be added to a list of attributes. Notes contain additional information for reference while developing the system, whereas constraints are the business rules that the class must follow, and are text included in curly brace brackets.


Classes are of the following types as per their behavior, as shown in the following table:

Class Behavior

Boundary In an ideal multi tier system, the user interacts only with the boundary classes. For example, JSPs in a typical MVC architecture form the boundary classes.

Control These classes typically don't contain any business functionality. However, their main task is to transfer control to the appropriate business logic class, depending on a few inputs received from the boundary classes.

Entity These classes are those that contain the business functionality. Any interactions with back-end systems are generally done through these classes.

Interface: An interface is a variation of a class. As we saw from the previous

point, a class provides an encapsulated implementation of certain business functionality of a system. An interface on the other hand provides only a

definition of business functionality of a system. A separate class implements the actual business functionality.

An interface shares the same features as a class; in other words, it contains attributes and methods. The only difference is that that the methods are only declared in the interface and will be implemented by the class implementing the interface.

In addition to the above, there is one more element used in class diagrams:

Package: A package provides the ability to group together classes and/or

interfaces that are either similar in nature or related. Grouping these design elements in a package element provides for better readability of class diagrams, especially complex class diagrams.

We can see a package is represented as a tabbed folder. A package can also have relationships with other packages similar to relationships between classes and interfaces.



card reader card number accept card() eject card() read card() atm screen prompt() accept input() account account number pin balance open() withdraw funds() deduct funds() verify funds() cash dispenser cash balance provide cash() provide receipt()




Introduction :

State Transition diagram shows the life cycle of a single object, from the time it is created until it is destroyed. These diagrams are a good way to model the dynamic behavior of a class. Dynamic behavior of a class implies that the class can exist in many states. To determine whether the class is dynamic or not , one can this by looking at its attributes, as the class may behave differently with different values of that attributes. Also, relationship is a good indicator for the same.

In- depth :

One can create one State Transition diagram per class.

State : It is one of the possible conditions in which an object may exist.

Activity : It is some behavior that an object carries out while it is in a particular state. An activity is an interruptible behavior.

Entry Action : An entry action is the behavior that occurs while the object is transitioning in to the state . It is non interruptible. It happens as a part of the transition into the state. Exit Action : An exit action is similar to an entry action but it occurs as a part of the transition out of a state.

Transition : It is a movement from one state to another . The set of transitions on a diagram shows how the object moves from one state to another.

Event : An event is something that occurs that causes a transition from one state to another.

Guard Condition : A condition that controls when a transition can or cannot occur. A guard condition is drawn along the transition line, after the event name and enclosed in square brackets.





c h e c k va lid i ty A va i la b le r e q u e s t d e n ie d Is s u e d B o o k is is s u e d b o o k n o t a va il a b l e s tu d e n t is va li d r e q u e s t fo r b o o k is s u e s tu d e n t is i n va li d B o o k is re tu r n e d




Collaboration diagrams and sequence diagrams are alternate representations of an interaction. A collaboration diagram is an interaction diagram that shows the order of messages that implement an operation or a transaction whereas a sequence diagram shows object interaction in a time based sequence.

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 interaction or structural relationships that occur between objects and object like entities in the current model.

Collaboration diagrams contain icons representing objects. You can create one or more collaboration diagrams to depict interactions for each logical package in your model. Such collaboration diagrams are themselves contained by the logical package enclosing the objects they depict.

An Object specification enables you to display and modify the properties and

relationships of an object. The information in a specification is presented textually. Some of this information can also be displayed inside the icons representing objects in

collaboration diagrams.

Use collaboration diagrams as the primary vehicle to describe interactions that express your decisions about the behavior of the system.

Relationships :

A dependency relationship can be drawn from a component to another component. This type of dependency relationship means that the classes contained in the client component can inherit from , contain instances of ,use, and otherwise depend on classes that are exported from the supplier component.

A dependency relationship can also be drawn from a component to an interface of another component, which means that the client component uses the operations of the other component.

Also a realize relationship can be drawn from a component to an interface of another component , which means that the client component provides the operations of the other component.



ATM SCREEN USER ACCOUNT CARD READER Customer 2: READ CARD CASH DISPENSER 16: verify funds 17: deduct funds 6: open account 7: verify pin 12: withdraw funds 4: prompt for pin

5: enter pin

8: promt for transaction 9: select transaction

10: prompt for amount 11: enter amount 13: provide cash 14: provide receipt 3: INITIALISE SCREEN 15: eject cash 1: ACCEPT CARD



Operator Bar code reader student info controller Book info controller student details Book details Message box return book 5: validate if fine 9: validate details 12: check availibility 1: read barcode 2: submit barcode

11: submit book code

4: submit 3: get details

10: invalid student 13: not available 16: issue success 14: add record 15: add record 6: update 7: update



s t u d e n t

r e g i s t r a r

a c c o u n t

m a n a g e r

s c r u t in y

o ffic e r

5 : c h e c k s t u d e n t d e t a i l s

1 : r e q u e s t fo r t h e c o u r s e

3 : s u b m i t fo r m d e t a i l s

1 1 : r e q u e s t fo r c a n c e l la t i o n

2 : p r o m p t f o r fo r m s u b m i s s i o n

7 : p r o m p t fo r fe e s u b m i s s i o n

1 0 : g r a n t a d m is s i o n le t t e r

8 : s u b m it fe e s

1 5 : r e t u r n fe e s a ft e r d e d u c t i n g c a n c e l la t io n c h a r g e s

4 : fo r m v e r ifi c a t i o n

1 2 : v e r i fi c a t i o n o f d e t a il s

6 : r e t u r n d e t a ils t o r e g is t r a r

1 3 : c o n fi r m d e t a i ls

9 : c o n fir m fe e s u b m i t i o n

1 4 : fo r w a r d s t u d e n t d e t a i l s



Definition :

Component diagrams provide a physical view of current model. A component diagram shows the organization and dependencies among software components, including source code components, binary code components and executable components . These diagrams also show the externally – visible behavior of the components by displaying the

interfaces of the components . Calling dependencies among components are shown as dependency relationships between components and interfaces on other components. Here interfaces actually belong to the logical view , but they can occur both in class diagrams and in component diagrams.

Component diagrams contain :

• Component packages • Components

• Interfaces

• Dependency relationships

One or more component diagrams can be created to depict the component packages and components at the top level of the component view , or to depict the contents of each component package. Such component diagrams belong to the component package that they depict.

Component Package :

Component packages represent clusters of logically related components , or major pieces of the system. Component packages parallel the role played by logical packages for class diagrams. They allow partitioning the physical model of the system . A component package can have dependencies with other component packages, components and interfaces.

Component :

A component represents a software module ( source code, binary code, executable, DLL, etc.) with well defined interface. The interface of a component is represented by one or several interface elements that the component provides. Components are used to show compiler and runtime dependencies, interface and calling dependencies among software modules and also show which components implement a specific class.




Card Reader Cash Dispenser

ATM Screen

Card Reader



Printer Account Main Screen E m ployee.exe M ain s creen account


Card Reader


Main Screen library.exe



orde r op tions

order c lien tex e

order de tail o rde r m g r orde r s e rverex e order tra ns ac tio n m gr ord er item