4. uml
DESCRIPTION
4. UML. 4.1. Motivation. The U nified M odeling L anguage tries to integrate older approaches Developed by Rational (CASE tool) they hired Booch, Rumbaugh, Jacobsen Standardized at version 1.1 by the OMG (Object Management Group) - PowerPoint PPT PresentationTRANSCRIPT
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)
CPSC 333: Foundations of Software Engineering J. Denzinger
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.
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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)
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
Interfaces in UML (1)
Stereotype <<interface>>
InputStream{abstract}
OrderReader
DataInputStream Realization
DependencyGeneralization
<<interface>>
DataInput
close()
CPSC 333: Foundations of Software Engineering J. Denzinger
Interfaces in UML (2)
OrderReader
DataInputStream Dependency
DataInput
Interface
Lollipops (“short-hand notation”)
CPSC 333: Foundations of Software Engineering J. Denzinger
requestclientsubsystem
contract
contract contract
request
request
serversubsystem
peersubsystem
peersubsystem
4.2.2. Systems and subsystems System Design
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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)
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
4.2.3. Component diagrams Component representation
resourcePool.javabuglist.dll
Realizes: BugList FilteredListSystem::kernel.
dll {version=1.23}
path name
CPSC 333: Foundations of Software Engineering J. Denzinger
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)
CPSC 333: Foundations of Software Engineering J. Denzinger
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
CPSC 333: Foundations of Software Engineering J. Denzinger
Alternative representation
ProjectMgt.java resourcePool.java
ResourcePool = import interface for ProjectMgt.javaResourcePool = export interface for resourcePool.java
Dependency
Realization
<<interface>>ResourcePool
addEmployee()
CPSC 333: Foundations of Software Engineering J. Denzinger
4.2.4. Deployment diagrams
Show physical relationship among software & hardware componentsShow where components of a distributed system are located
CPSC 333: Foundations of Software Engineering J. Denzinger
Deployment diagrams (2)
Nodes: Computational units (most often: Hardware)Connections: Communication paths over which the system will interact
Client
TCP/IP
Server
CPSC 333: Foundations of Software Engineering J. Denzinger
Nodes and components
AccountServer
DeploysAccountDB.javaAccountMgt.java
AccountServer
AccountMgt.javaAccountDB.java