4. UML. CPSC 333: Foundations of Software EngineeringJ. Denzinger 4.1. Motivation The Unified...

4. UML

CPSC 333: Foundations of Software Engineering J. Denzinger

4.1. Motivation

The Unified Modeling Language tries to integrate older approachesDeveloped by Rational (CASE tool) they hired Booch, Rumbaugh, Jacobsen

Standardized at version 1.1 by the OMG (Object Management Group)Supported by almost all OO CASE tools … but with some limitations …Currently it is at version 1.4 (OMG working on 2.0)


Goals of UML

Provide users with ready-to-use, expressive visual modeling language to develop and exchange meaningful models.Provide extensibility and specialization mechanisms to extend the core concepts.Be independent of particular languages and processes.Provide formal basis for understanding the modeling language.Encourage the growth of the OO tools market.Support higher-level development concepts such as collaborations, frameworks, patterns and components.Integrate best practices.


UML has 9 kinds of diagrams

Class Diagram Object Diagram Component Diagram Deployment Diagram Use Case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram

Structural DiagramsStructural Diagrams

Behavioral DiagramsBehavioral Diagrams


4.2. Structural diagrams4.2.1. Class diagram

Central for OO modelingShows static structure of the system Types (!) of objects Static relationships (see next lecture)

Association(e.g.: a company has many employees)

Generalization (subtypes)(e.g.: an employee is a kind of person)

Dependencies(e.g.: a company is using trucks to ship

products)


Class

Set of objectsDefines name attributes

(optional: type optional: initial value)

operations

Task

startDate: Date = defaultendDate: Datename

setStartDate (d : Date)setEndDate (d : Date)getDuration () : Date


Class diagram example

Light

off( )on( )

Heater Cooler

Environmental Controller

define_climate( )terminate_climate( )

0..*

1

1

1

1

1

SystemLog

display( )recordEvent( )

Actuator

startUp( )shutDown( )

Temperature

generalization

aggregation

association


Three Perspectives

We can look at classes from these perspectives:Conceptual (OOAnalysis)

Shows concepts of the domain Should be independent from implementation

Specification (OODesign) General structure of the running system Interfaces of software (types, not classes) Often: Best perspective

Implementation (OOProgramming) Structure of the implementation (classes) Most often used

Try to draw from a clear, single perspective


Attributes

Conceptual: Indicates that customer have namesSpecification: Customer can tell you the name and set it(short for get/set methods)Implementation: An instance variable is available

Customer

nameaddress

creditRating


Operations

Services that a class knows to carry outCorrespond to messages of the class (or IF)Conceptual level principal responsibilities

Specification level public messages = interface of the class

Normally: Don’t show operations that manipulate attributes


UML syntax for operations

visibility name (parameter list) : return-type-expression

+ assignAgent (a : Agent) : Boolean

visibility: public (+), protected (#), private (-) Interpretation is language dependent Not needed on conceptual level

name: string parameter list: arguments (syntax as in attributes) return-type-expression: language-dependent

specification


Operations vs. Responsibilities

Conceptual: Operations should specify responsibilities, not IF, e.g.: The Customer specifies the Orders The Orders list the Customer

*1

OrderdateReceived

isPrepaid

number : String

price : Money

Responsibilities- lists the customer

UML 1.3 Specific (similar to CRC Cards)

Customernameaddress

Responsibilities- specifies orders


Class versus type

Type protocol understood by an object set of operations that are used

Class implementation oriented construct implements one or more types

In Java a type is an interface, in C++ a type is an abstract classUML 1.3 has the <<interface>> stereotype and the lollipop


Interfaces in UML (1)

Stereotype <<interface>>

InputStream{abstract}

OrderReader

DataInputStream Realization

DependencyGeneralization

<<interface>>

DataInput

close()


Interfaces in UML (2)

OrderReader

DataInputStream Dependency

DataInput

Interface

Lollipops (“short-hand notation”)


requestclientsubsystem

contract

contract contract

request

request

serversubsystem

peersubsystem

peersubsystem

4.2.2. Systems and subsystems System Design


test status

request for alarm notification

periodic check-in

require for configuration update

request for statusControlpanel

subsystem

Sensorsubsystem

Centralcommunication

subsystem

request for system status

specification of type of alarm

periodic status check

Systems and Sub-Systems


How to break a system into smaller subsystems?

• Roman principle: Divide & conquer– Split up a large system into manageable parts

• In structured methods: functional decomposition• In OO: Group classes into higher level units

Packages (conceptual; at development time)

Components (physical; at run time)


Packages

General purpose mechanism for organizing elements into groupsPackage forms a namespace Names are unique within ONE package UML assumes an anonymous root package

ResourcePool


Package vs. Component

Packages Conceptual structuring of system model Source code structure

Components “Physical and replaceable part of the system that

conforms to and provides the realization of a set of interfaces”,e.g.:

COM+ components, Java Beans, … source code files Documents


4.2.3. Component diagrams Component representation

resourcePool.javabuglist.dll

Realizes: BugList FilteredListSystem::kernel.

dll {version=1.23}

path name


Example Diagram


Components vs. classes

Both have names and realize interfacesClass logical abstraction Attributes and operations

Component Physical thing that exist on machines Physical packaging of logical things (classes,

interfaces, …) Only has operations (only reachable thru its IF)


Components and interfaces

IFs used in all component-based OS-facilities (COM+, CORBA, EJB)

ProjectMgt.java resourcePool.java

ResourcePool

ResourcePool = import interface for ProjectMgt.javaResourcePool = export interface for resourcePool.java

DependencyInterface

Realization


Alternative representation

ProjectMgt.java resourcePool.java

ResourcePool = import interface for ProjectMgt.javaResourcePool = export interface for resourcePool.java

Dependency

Realization

<<interface>>ResourcePool

addEmployee()


4.2.4. Deployment diagrams

Show physical relationship among software & hardware componentsShow where components of a distributed system are located


Deployment diagrams (2)

Nodes: Computational units (most often: Hardware)Connections: Communication paths over which the system will interact

Client

TCP/IP

Server


Nodes and components

AccountServer

DeploysAccountDB.javaAccountMgt.java

AccountServer

AccountMgt.javaAccountDB.java


Kiosk

Account Server

Kiosk

0..*

10..*

1

SalesTerminal

Date post:	03-Jan-2016
Category:	Documents
Upload:	corey-sparks
View:	219 times
Download:	0 times