UML

03/05/23 Winlex Ltd. 1

Rational Unified Process and Unified Modelling Language

Vinil Gupta

Winlex Ltd. 203/05/23

UML History

Grady Booch – methodology Ivar Jacobson – methodology * Jim Rumbaugh – Object Modelling

Techniques Many others


Why UML

Provides visual syntax throughout SDLC Suitable for most applications and is platform

neutral Provides excellent support for pure OO

languages, hybrid OO languages and non-OO languages.

Supports UP for OO systems and other engineering processes


Objects and UML

UML models the world as system of interacting objects

An Object is a cohesive cluster of data and function

Two aspect of UML: 1. Static Structure 2. Dynamic Behaviour


UML Structure

1. Building Blocks – basic modelling elements, relationships and diagrams

2. Common Mechanism – way of achieving specific goal

3. Architect – view of system architecture


1. Building Blocks

Things – modelling elements themselves Relationship – specifies how things are

semantically related Diagrams – view into models; collection of

things that tells a story about the software system; how it will do something


1.ThingsIn UML modelling elements are called things

Structured things – class, interface, collaboration, use case, active class, component, node

Behaviour things – interactions, state machines Group things – package of semantically related

modelling elements Annotational things – ad hoc info; yellow sticker


2.Relationship Description of a set of link between

objects A change to a thing affects the

semantics of a dependent thing One element is a specialisation of

another; substituted more general element

One classifier specifies a contract that the other classifier guarantees to carry out

Association

Dependency

Generalisation

Realisation


3. Diagrams

Diagrams contains things. Things can be deleted from diagram but not from model

Diagrams are only views into the model and not the model itself

There are a total of nine different UML diagrams (i) Static Model; (ii) Dynamic Model


3.Diagrams

Static Model – System structure1. Class diagram2. Component Diagrams3. Deployment Diagram


3.Diagrams

Dynamic Model – System behaviour

1. Object diagram2. Use Case diagram3. Sequence diagram4. Collaboration diagram5. Statechart diagram6. Activity diagram


UML Common Mechanism

UML has four common mechanism

1. Specifications2. Adornments3. Common divisions4. Extensibility mechanism


1.SpecificationSpecifications are the meat of the UML model.

They provide the semantic backplane of the model. UML model has at least two dimensions

1. Graphic dimensions – diagram

2. Textural dimensions – specifications textual descriptions of the semantics of an element


1.Specification

UML models may be: Elided – some elements from diagrams to simplify the view Incomplete – some elements may be missing entirely Inconsistent – model may contain contradictions

BankAccount

nameaccountNumber

deposite()withdraw()calculateInterest()

Icon or modelling element

Semantic BackplaneClass Specification

Use Case specification

Dependency specification

Deposit


2.Adornments

A feature of UML that allows a symbol to every modelling element, to which number of adornments

Window

Window{author = jim, status = tested}

+size : Area =(100, 100)#visibility : Boolean = false+defaultSize : Rectangle#maximumSize : rectangle-xptr : Xwindow*

+create()+hide()+display( location : Point)-attachXWindow( xwin : Xwindow* )

Unadorned element

Element with adornments


3.Common Division

Common division describe particular way of thinking about world. Two common UML divisions are:

1. Classifier and instance• Classifier – an abstract notion e.g. a type of bank

account• Instance – a concrete thing e.g. my bank account


3.Common DivisionAccount

Number : intOwner : StringBalance : double

Deposit()Withdraw()

jimsAccount:Account

Number : 801Owner : “Jim Arlow”Balance : 300.00

fabsAccoumt:Account

Number : 802Owner : FabBalance : 1000.00

<<instantiate>><<instantiate>>

objects

class

1. Classifier and Instance – In UML an instance usually has the same icon as the corresponding classifier, but for instance the name on the icon is underlined


3.Common Division

2. Interface and implementation The principle here is to separate what

something does from how it does it

• Interface – e.g. the buttons on front of your CD recorder – similar to a legal contract

• Implementation – e.g. the mechanism inside your CD recorder


4. Extensibility Mechanisms

1. Constraints – These extend the semantics of element by allowing us to add new rules

2. Stereotypes – allows us to add a new modelling element based on existing one – we define the semantics of the stereotype ourselves; Stereotype add new element to the UML metamodel

3. Tagged value – allows us to add new ad hoc information to element’s specification


4. Extensibility Mechanisms

1. Constraints – simply a text in in braces { } that specifies rules that must be maintained as true.

2. Stereotype – represent a variation on existing element but with a different intent. Each element can have at most one stereotype, define a set of tagged values and constraints, associate a new icon. You have to define semantics of the new element somewhere i.e. put a note on the model or refer to doc. Use ST name in << >>or the icon. You can ST relationships as well as classes


4. Extensibility Mechanisms<<entity>>

Ticketprefered <<entity>>

Ticket icon

stereotype

Ticket

Ticket

prefered

<<control>>JobManager Scheduler

<<call>>

3. Tagged Values – allow you to add your own properties to model elements.

{tag1=value1, tag2=value2, …, tagN=valueN} i.e. {auther=Vinil Gupta}


Architecture

The organisational structure of a system, including its decomposition into parts, their connectivity, interaction, mechanism and the guiding principles that inform the design of a system OR

The highest-level concept of a system in its envionment


Architecture

UML captures the strategic aspects of a system in a “4+1 view” of architectureLogical viewProcess view Implementation viewDeployment viewUse Case view


Architecture

Implementation View

- Component diagrams

Logical View

Process View Deployment View

- Deployment diagrams

- Class diagram- Statecharts- Object diagrams

- Class diagrams- Object diagrams

Use Case View

- Use Case diagrams- Interaction diagrams

Behaviour

ü Vocabulary ü Functionality

ü Performanceü Scalabilityü Througput

ü System assemblyü Configuration Management

ü System topologyü Distributionü Delivery ü Installation


Architecture

1. Logical View - captures the vocabulary of problem domain as a set of classes and objects. The emphasis is on showing how the object and classes that compose the system, implement the required system behaviour.


Architecture

2. Process View – models the executable threads and processes in our system as active classes. It is really a process in our system as active classes. It is really a process-oriented variation on the logical view, and contains all the same artfeacts.


Architecture

3. Implementation view - models the files and components that make up the physical code base of the system. It is also about illustrating dependencies between components, and about configuration management of set of components to define a version of the system.


Architecture

4. Deployment View - models the physical deployment of components onto a set of physical, computational nodes such as computers and peripherals. It allows you to model the distribution of components across the nodes of a distributed system.


Architecture

5. Use Case View – all of the other views derived from the use case view. This view captures the basic requirements for the system as a set of use cases and provides the basis for the construction of other views.


Architecture

Under UP the 4+1 architecture is not created in one go, rather it evolves over time, using stepwise refinements. Each iteration captures just enough information about the system to allow it to be built.

Documents

UML