Introduction to UML

What is Model/modeling??????

A model is a simplification of reality. A model provides the blueprints of a system or may encompass detailed plans. A model may be structural, emphasizing the organization of the system, or it may be behavioural, emphasizing the dynamics of the system. modeling is a proven and well-accepted engineering technique. We build architectural models of houses to help their users visualize the final product. modeling is a central part of all the activities that lead up to the deployment of good software.

Why do we Model???
There are many elements that contribute to a successful software organization; one common thread is the use of modeling.
Need of building Model to communicate the desired structure and behaviour of our system. to visualize and control the system!s architecture. to better understand the system we are building, often e"posing opportunities for simplification and reuse. to manage ris#.

Aim for Modeling:

help us to visualize a system as it is or as we want it to be. permit us to specify the structure or behaviour of a system. give us a template that guides us in constructing a system. document the decisions we have made.

Approach for modeling.........

$he two most common ways are Algorithmic perspective %b&ect-oriented perspective Algorithmic perspective The traditional view of software development 'n this approach, the main building bloc# of all software is the procedure or function. !"ect#oriented perspective :The contemporary view of software development 'n this approach, the main building bloc# of all software systems is the ob&ect or class.

Introducing the UML

(M) stands for Unified modeling Language. is different from the other common programming languages li#e *++, ,ava, *%-%) etc. is a pictorial language used to ma#e software blue prints. is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. is a very e"pressive language, addressing all the views needed to develop and then deploy such systems.

(M) is not a programming language but tools./ational /ose0 can be used to generate code in various languages using (M) diagrams.

$he (M) is a language for 1isualizing 2pecifying *onstructing 3ocumenting the artifacts of a software-intensive system.

(M) can be described as the successor of ob&ect oriented analysis and design. 2ome fundamental concepts of ob&ect oriented world !"ects: %b&ects represent an entity and the basic building bloc#. $lass *lass is the blue print of an ob&ect. A!straction: Abstraction represents the behavior of an real world entity. %ncapsulation: 4ncapsulation is the mechanism of binding the data together and hiding them from outside world. Inheritance: 'nheritance is the mechanism of ma#ing new classes from e"isting one. &olymorphism: 't defines the mechanism to e"ists in different forms.

'istory
(M) was created by %b&ect Management 5roup. (M) 6.7 specification draft was proposed to the %M5 in ,anuary 6889 %M5 adopted technologies in November 6889 as (M) 6.6,minor revision is (M) 6.:, 6.;, 6.< (M) =.7 ma&or revision that was adopted by the %M5 in =77<. versions =.6.6 and =.6.= appeared in =779, followed by (M) =.= in >ebruary =778. (M) =.: was formally released in May =767. (M) =.;.6 was formally released in August =766

A $onceptual Model of the UML

$hree ma&or elements

(M) building bloc#s /ules to connect the building bloc#s *ommon mechanisms of (M)

Where $an the UML (e Used?

)oftware#intensive systems 4nterprise information systems -an#ing and financial services $elecommunications $ransportation 3efence?aerospace /etail Medical electronics 2cientific 3istributed Web-based services *on software systems wor#flow in the legal system, the structure and behaviour of a patient healthcare system the design of hardware.

UML (uilding (loc+s

$hree #inds of building bloc#s $hings /elationships 3iagrams Things are the abstractions that are first-class citizens in a model; relationships tie these things together; diagrams group interesting collections of things.

,hings in the UML

$here are four #inds of things in the (M)

2tructural things -ehavioural things 5rouping things Annotational things

)tructural ,hings
2tructural things are the nouns of (M) models. $he 2tructural things define the static part of the model. $hey represent physical and conceptual elements. $here are seven #inds of structural things$lass: *lass represents set of ob&ects having similar responsibilities. Interface: 'nterface defines a set of operations which specify the responsibility of a class. $olla!oration: *ollaboration defines interaction between elements. Use case: (se case represents a set of actions performed by a system for a specific goal. Active classes: an active class is a class whose ob&ects own one or more processes or threads and therefore can initiate control activity.

$omponent: *omponent describes physical part of a system. *ode: A node can be defined as a physical element that e"ists at run time.

(ehavioral things
Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. There are two primary kinds of behavioral things Interaction: Interaction is defined as a behavio r that consists of a gro p of messages e!changed among elements to accomplish a specific task. State machine: "tate machine is sef l when the state of an ob#ect in its life cycle is important. It defines the se$ ence of states an ob#ect goes thro gh in response to events. %vents are e!ternal factors responsible for state change.

-rouping things
&ro ping things are the organi'ational parts of UML models. These are the bo!es into which a model can be decomposed. There is one primary kind of gro ping thing ( Package: )ackage is the only one gro ping thing available for gathering str ct ral and behavioral things.

Annotational things
*nnotational things are the e!planatory parts of UML models. These are the comments yo may apply to describe, ill minate, and remark abo t any element in a model. There is one primary kind of annotational thing ( Note: * note is sed to render comments, constraints etc of an UML element.

.elationships in the UML

't shows how elements are associated with each other and this association describes the functionality of an application. $here are four #inds of relationships in the (M) 6. 3ependency =. Association :. 5eneralization ;. /ealization

Dependency: +ependency is a relationship between two things in which change in one element also affects the other one. Association: *ssociation is basically a set of links that connects elements of an UML model. It also describes how many ob#ects are taking part in that relationship. Generalization: &enerali'ation can be defined as a relationship which connects a speciali'ed element with a generali'ed element. It basically describes inheritance relationship in the world of ob#ects. Realization: ,eali'ation can be defined as a relationship in which two elements are connected. -ne element describes some responsibility which is not implemented and the other one implements them.

UML /iagrams
A diagram is the graphical presentation of a set of elements a diagram may contain any combination of things and relationships. (M) includes nine such diagrams 6. *lass diagram =. %b&ect diagram :. (se case diagram ;. 2equence diagram <. *ollaboration diagram @. 2tate chart diagram 9. Activity diagram A. *omponent diagram 8. 3eployment diagram

UML Architecture

Use Case view which connects all these four. 't represents the functionality of the system. 't encompasses the use cases that describe the behaviour of the system as seen by its end users, analysts, and testers. Design view of a system encompasses the classes, interfaces, and collaborations . $he class diagrams 0o!"ect diagrams0 interaction diagrams0 state chart diagrams, and activity diagrams are used to support this perspective. Process view of system defines the flow of the system. $he same elements as used in 3esign are also used to support this perspective. mplementation view of a system defines the components assembled together to ma#e a complete physical system. $omponent diagrams, interaction diagrams0 state chart diagrams, and activity diagrams are used to support this perspective. Deployment view of the system represents the physical nodes of the system that forms the hardware. /eployment diagram is used to support this perspective.

UML Modeling ,ypes

(M) diagrams represent two different views of a system model !tructural modeling" 't captures the static features of a system. 2tructural model represents the framewor# for the system. $hey consist of the followings *lasses diagrams %b&ects diagrams 3eployment diagrams Bac#age diagrams *omposite structure diagram *omponent diagram

#ehavioral $odeling" 't describes the interaction in the system. 't represents the interaction among the structural diagrams. -ehavioral modeling shows the dynamic nature of the system. $hey consist of the following Activity diagrams 'nteraction diagrams 2equence diagrams *ollaboration diagram 2tate chart diagram (se case diagrams