UML an overview

Topics covered in this Session

1. Introducing UML
2. What constitutes the UML 3. Concepts of UML

4. System Architecture

Introduction
What is UML?
Is a language. It is not simply a notation for drawing diagrams It is a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication.

Unified Modeling Language (UML)

used for both database and software modeling version 1.1 was adopted in November 1997 by the Object Management Group (OMG) as a standard language for object-oriented analysis and design
Ivar Jacobson is known as the father of Use Cases.

Refernces http://www.inconcept.com/JCM/April1998/halpin.html

The Unified Modeling Language.

Unification

Specify

Construct The UML Goal

Visualize

Document

Process

Basic Building Blocks

Things Relationships Diagrams

The UML process

There are four kinds of things in the UML. 1. Structural Things. 2. Behavioral Things.

3. Grouping Things.
4. Annotational Things.

Things in UML

Structural Things 1. Class 2. Interface 3. Collaboration 4. Use Case 5. Active Class 6. Components 7. Nodes

Behavioral Things 1. Interaction 2. State Mechanism

Grouping Things 1. Packages

Annotational Things 1. Notes

Class

Interface

description of a set of objects that share the same attributes, operations, semantics & relationships represents externally visible behavior of the class or component collection of operations that specifies a service of the class or component Defines an interaction Society of roles and other elements that work together to provide a co-operate behavior that is greater than the sum of all the elements

Collaboration

Use Case

Description of a set of sequence of actions that a system performs inorder to give an observable result Type of class that initiates control activity Represents elements whose behavior is concurrent with other elements Represents the physical packaging of logical elements such as classes, interfaces and collaborations A physical element that exists at runtime

Active Class

Component

Node

Interaction

A set of messages exchanged among a set of objects within a particular context to accomplish a specific task
Specifies the sequence of states an object can undergo during its lifetime in response to events

State Machine

Relationship
Tie together things
Dependency semantic relation Association structural relation Aggregation Generalization Realization

UML Diagrams

UML includes diagrams for use cases static structures (class and object diagrams) behavior (state-chart, activity, sequence and collaboration diagrams) implementation (component and deployment diagrams).

Diagrams in UML A Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of things and relationships. UML includes 9 such diagrams. 1. Class Diagram. 2. Object Diagram.

3. Use Case Diagram.

4. Sequence Diagram. 5. Collaboration Diagram. 6. State Chart Diagram. 7. Activity Diagram. 9. Deployment Diagram.

Use case diagrams

Use Case Diagrams describe the functionality of a system and users of the system Models the dynamic aspects of the system These diagrams contain the following elements: Actors: represent users of a system, including human users and other systems Use Cases: represent functionality or services provided by a system to users Dependency, generalization and association relationships

Use Case Diagram

<<include>> withdrawal <<include>> <<include>> validation

user <<include>> balance enquiry <<extend>>

<<extend>>

process transaction

<<extend>> cancel change passwd

Include Relationship

Incorporates one use case within the behavior sequence of another use case. Shown as a dashed arrow from the source to the target use case Adds incremental behavior to a use case Some initial capability is defined and later features are added modularly Shown as a dashed arrow from the extension use case to the base use case

Extend Relationship

Class Diagrams
Class Diagrams Class Diagrams describe the static structure of a system These diagrams contain the following elements Classes Interfaces Collaborations Relationships

Class Diagram

Interaction Diagrams

Shows interactions set of objects, their relationships and the messages dispatched among them

Sequence Diagram Collaboration Diagram

Sequence Diagrams
Time ordering of messages Objects are arranged along x-axis Messages ordered in increasing time along y-axis
Sequence diagrams contain the following elements: Objects Messages: represent communication between objects.

Lifelines: represent the existence of an object over a period of time.

Focus of control or Activations: represent the time during which an object is performing an operation.

Object Message Call Self call Return Signal Create Destroy Life line Activation

Sequence Diagram
user : Customer atm : Atm 1: insert card() 2: getPassword( ) 3: password 4: verifyAccount( ) 5: checkBankcode( ) 6: checkAcccode( ) 8: accountOK 9: reqTransaction( ) 10: transactionType() 11: getAmount( ) 12: amountEntered() 13: processTransaction( ) 14: processTransaction( ) 15: transactionSuccessful 16: transactionSuccessful 17: dispenseCash( ) 18: takeCash() 19: reqTransaction( ) 20: terminate() 21: printReceipt( ) 22: ejectCard( ) 23: takeCard() 24: displayScreen( ) 7: accountcodeOK consortium : Consortium bank : Bank

Collaboration Diagram
Structural organization of the objects that send and receive messages Collection of vertices and arcs The links are adorned with the messages that the objects send and receive
Difference of Collaboration diagram from sequence diagram Path: indicates how one object is linked to another object

Sequence Number: Indicates the time order of a message

1: insert card() 3: password 10: transactionType() 12: amountEntered() 18: takeCash() 20: terminate() 23: takeCard() user : Customer

2: getPassword( ) 9: reqTransaction( ) 11: getAmount( ) 17: dispenseCash( ) 19: reqTransaction( ) 21: printReceipt( ) 22: ejectCard( ) 24: displayScreen( )

atm : Atm

8: accountOK 16: transactionSuccessful

4: verifyAccount( ) 13: processTransaction( ) 5: checkBankcode( ) 6: checkAcccode( ) 14: processTransaction( ) consortium : Consortium 7: accountcodeOK 15: transactionSuccessful bank : Bank

Statechart Diagrams
Modeling the dynamic aspects of the system Statechart diagram shows state machine emphasis the flow of control from state to state State Machine: behavior that specifies the sequence of states an object goes through during its lifetime in response to events, and its responses to those events

These diagrams contain the following elements:

States: represent the situations during the life of an object in which it satisfies some condition, performs some activity, or waits for some event

Transitions: represent relationships between the different states of an object

State Chart Diagram

Transitions: Arrows

Start Marker
States: Rounded rectangles

End Marker

Activity Diagrams
Model the dynamic aspects of the system Flowchart showing flow of control from activity to activity Activity is a non atomic execution within a state machine

Activity Diagrams contain

Action States: represent atomic, noninterruptible, actions of entities or steps in the execution of an algorithm. Activity states: not atomic, can be decomposed and takes some duration to complete.

Transitions: shows the path from one action or activity state to another action or activity state. Represented using a directed line.

Branching

One incoming transition Two or more outgoing transition Boolean expression placed on each outgoing branch

evaluated once on entering the branch

Branch

Forking and Joining (Concurrent Flows)

Fork has on incoming transition and two or more outgoing transitions Join has two or more incoming transitions and one outgoing transition

Above the join activities continue in parallel

At the join concurrent flows synchronize - each waits until all incoming flows have reached the join One flow of control below the join

Swimlanes: Divide the activity states into groups and assign these groups to objects that must perform the activities.

Activity Diagram

Swimlanes

fork

join

Component Diagrams
Model the static implementation view of the system Shows the set of components and their relationships Modeling physical things that reside on a node executables libraries tables files documents

Executable Library

Document
File Table

Component diagram modeling executables and libraries

Deployment Diagrams
Static deployment view of the system Deployment diagram shows the configuration of runtime processing nodes and the components that live on them. It is a collection of vertices and arcs.

System Architecture

Use Case View

Describes the behavior of the system Analysts and end users are interested Static aspect of the view from use case diagram Dynamic aspects from interaction diagram, statechart diagram and activity diagram

Design View

Supports the functional requirements of the system Describes the vocabulary of the system and its solutions Interest to Developers Static aspect from class diagram and object diagram Dynamic aspects from interaction diagram, statechart diagram and activity diagram

Process View

Threads and processes that form the system Describes the performance, scalability and throughput Static aspects from the class diagram with active classes Dynamic aspects from interaction diagram, statechart diagram and activity diagram

Deployment View

Gives information about the various processing node Describes system topology, distribution and installation of various components Static aspects from deployment diagram Dynamic aspects from interaction diagram, statechart diagram and activity diagram

Implementation View

Components and files Describes system assembly and configuration management Static aspects from component diagram Dynamic aspects from interaction diagram, statechart diagram and activity diagram

Advantages of UML
UML is effective for modeling large, complex software systems It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects It can specify systems in an implementation-independent manner 10-20% of the constructs are used 80-90% of the time Use case modeling specifies the functional requirements of system in an object-oriented manner

Other uses of UML

analyze existing source code and reverse-engineer it into a set of UML diagrams A number of tools on the market generate Test and Verification Suites from UML models

Thank You !!