CPSC333 SENG 311: Foundations Principles of SE

1
CPSC333 / SENG 311 Foundations / Principles of SE

• Unified Modeling Language (UML)

2
Motivation

• The Unified Modeling Language 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)
• Supported by almost all OO CASE tools but with
  some limitations

3
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.

4
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 Diagrams
Behavioral Diagrams
5
Structural diagrams - Class diagram

• Central for OO modeling
• Shows 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)

6
Class

• Set of objects
• Defines
• name
• attributes(optional type optional initial
  value)
• operations

Task
startDate Date default
endDate Date name
setStartDate (d Date)
setEndDate (d Date)
getDuration () Date
7
Class diagram example
association
Actuator
startUp( )
shutDown( )
generalization
Light
Heater
Cooler
Temperature
off( )
1
1
on( )
0..
aggregation
1
1
1
Environmental Controller
SystemLog
define_climate( )
display( )
terminate_climate( )
recordEvent( )
8
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

9
Attributes

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

Customer
name
address
creditRating
10
Operations

• Services that a class knows to carry out
• Correspond to messages of the class (or IF)
• Conceptual level
• principal responsibilities
• Specification level
• public messages interface of the class
• Normally Dont show operations that manipulate
  attributes

11
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 at conceptual level
• name string
• parameter list arguments (syntax as in
  attributes)
• return-type-expression language-dependent
  specification

12
Operations vs. Responsibilities
UML 1.3 Specific (similar to CRC Cards)

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

Order
dateReceived
Customer
isPrepaid
name
address
price Money

1
Responsibilities - specifies orders
Responsibilities - lists the customer
13
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 class
• UML 1.3 has the ltltinterfacegtgt stereotype and the
  lollipop

14
Interfaces in UML (1)

• Stereotype ltltinterfacegtgt

InputStream abstract
OrderReader
Dependency
Generalization
DataInputStream
Realization
15
Interfaces in UML (2)

• Lollipops (short-hand notation)

DataInput
OrderReader
Interface
DataInputStream
Dependency
16
Systems and subsystems System Design
17
Systems and Sub-Systems
Control
Sensor
request for status
panel
subsystem
test status
subsystem
request for system status
specification of type of alarm
periodic status check
Central
communication
subsystem
18
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)
19
Packages

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

20
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

21
Component diagrams - Component representation
resourcePool.java
buglist.dll
Realizes BugList FilteredList
Systemkernel.dll version1.23
path name
22
Example Diagram
23
Components vs. classes

• Both have names and realize interfaces
• Class
• 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)

24
Components and interfaces

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

Interface
Realization
Dependency
ResourcePool
ResourcePool import interface for
ProjectMgt.java ResourcePool export interface
for resourcePool.java
25
Alternative representation
Dependency
Realization
ResourcePool import interface for
ProjectMgt.java ResourcePool export interface
for resourcePool.java
26
Deployment diagrams

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

27
Deployment diagrams (2)

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

Client
TCP/IP
28
Nodes and components
29
Kiosk
Kiosk
1
1
0..
0..
SalesTerminal
30
Were Available!

• Questions?
• if you have any questions about contents of this
  lecture or other course-related issues, please
  come by during our office hours, or send us email
• Dr. Joshua MTW, 12-1pm, ICT 548
• joshuar_at_cpsc.ucalgary.ca
• Dr. Walker WF, 1-2pm, ICT 546
• rwalker_at_cpsc.ucalgary.ca