1. UML
NOTES

2. UML for System Design
Notes

3. Outline
System Design
Review – Unified Modeling Language (UML) and Rational’s Unified Process (RUP)
Requirements Analysis
Use Cases
Relationships Between Use Cases
For today, we will discuss the components in Embedded System Design.
Then, we will review Rational’s Design Methodology.
Finally, we will focus on each part of that methodology, with an emphasis on real-time embedded system design. In particular, we will cover requirements analysis today and continue with structural object analysis next time.

4. Design Methodology A design methodology consists of:
a modeling language consisting of a semantic framework and notational schema (UML, etc.), and
a development process governing the use of the language and the set of artifacts that result (RUP, etc.)
Design methodologies consiste of two components a language and a process.

5. Software Development Triangle
Team-Based
Development
Modeling
Language
Unified Process
[Rational]

6. Development Process A development process defines:
who is doing what,
when it should be done, and
how to reach a specific goal.
It describes activities that govern use of the language and the design artifacts (models, etc.) that are produced.

7. Design Artifacts Class Use Case Diagrams Object Sequence State
A model is a description of the system from a particular perspective.
Use Case
Diagrams
Scenario
Collaboration
State
Component
Deployment
Object
Statechart
Sequence
Class
Activity
Models

8. Why Bother With A Process?
To produce systems with consistent quality.
To manage the development of complex systems.
To predict completion time and development cost.
To identify measurable milestones and generate iterative prototypes.
To enable team-collaboration on large-scale systems.

9. Development Phases
Analysis - identify essential characteristics of a correct solution.
Design - define a particular solution based on the optimization of some criterion.
Implementation - create an executable, deployable realization of the design.
Testing - verify the translation and validate correctness of the implementation.
All phases involve work on various models.

10. Sequencing Development Phases
Waterfall Lifecycle
sequential ordering of Analysis, Design, Implementation, and Testing phases.
Iterative Lifecycle
spiral cycles consisting of Analysis, Design, Implementation, and Testing phases to produce Iterative Prototypes.
enabling technology - automatic translation of description models into executable models.

11. Example: Network Architecture
Think Horizontally
Application Layer
Transport Layer
Data Link Layer
Construct Vertically
Application Layer
Transport Layer
Data Link Layer
Vertical Prototypes

12. Iterations and Milestones
An iteration is a sequence of activities with an established plan and criteria for evaluation, resulting in a release.
Each milestone is completed after one or more iterations through each of the phases (Analysis, Design, Implementation, and Testing).

13. Iterations and WorkflowP h a s e I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o
Requirements A n i t e r a o h l b p s
Analysis
Design
Implementation
Testing P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 I t e r a i o n s

14. Unified Software Development Rational Unified Process (RUP)
Iterative and Incremental
Use Case Driven
Architecture-Centric

15. Use Cases bind the workflows together
Use Case Driven
Requirements
Analysis
Design
Implementation
Testing
Use Cases bind the workflows together

16. Use Case Driven Iterations
Use Cases drive development activities:
Creation/validation of the system’s architecture
Definition of test cases and procedures
Planning of iterations
Creation of user documentation
Deployment of system
They also help to synchronize the content of different models.

17. Architecture-Centric
Models are vehicles for visualizing, specifying, constructing, and documenting the architecture.
The Unified Process prescribes the successive refinement of an executable architecture.

18. Architecture and Models
Use Case
Model
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Models
Views
The architecture includes a set of views of the models.

19. Function versus Form
Use cases
Architecture
Use cases specify function and the architecture specifies form.
Use cases and architecture must be balanced.

20. The Unified Process is Engineered
A role played by an individual or a team
Activity
A unit of work
Worker
Describe a
Use Case
Analyst
responsible for
Artifact
A piece of information that is produced, modified, or used by a process
Use case
Use case package

21. Process Frameworks Process frameworks (RUP, etc.):
There is no single Universal Process Framework.
Process frameworks (RUP, etc.):
allow a variety of lifecycle strategies
specify what artifacts to produce
define activities and workers
used to model concepts

22. Two Parts of a Unified Whole
The Unified
Modeling
Language
Unified
Design
Process +
OMG Standard 1.4
Convergence through process frameworks

23. Unified Modeling Language
The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting artifacts of a software-intensive system.
It focuses on a standard modeling language which represents the convergence of several popular object-oriented methodologies [UML, ver. 1.4].

24. Convergence of OO Methodologies
OMT
(Rumbaugh, et.al)
Booch
UML 0.9
(1996)
UML 1.1
(1997)
UML 1.4
(2001)
OOSE
(Jacobson, et.al)
ROOM and Others
UML Reference: OMG:

25. Brief History 1967: Simula programming language
1970’s: Smalltalk programming language
1980’s: Theoretical foundations, C++, etc.
1990’s: Object-oriented analysis and design methods (Booch, OMT, ROOM, etc.)
: UML standardized by the Object Management Group (OMG)

26. Advantages Consistency of model views
Improved problem-domain abstraction
Improved reuse and scalability
Improved reliability and safety
Inherent support for concurrency

27. Disadvantages Perceived as immature technology for embedded systems
Lack of compilers and other tools
Perceived inefficiency of objects
Lack of trained developers

28. Terms and Concepts
An object is used to model a unique real-world or conceptual entity and includes:
Identity
Attributes (values)
Behaviours
Objects are instances of classes.
A class is an abstraction of the elements commonly shared by a set of objects.
temp sensor
temp: int
reset_sensor( )
get_value( )
set_rate(int x)

29. Terms and Concepts Classes relate to other classes by relations:
Associations bind classes together to enable communication via messages.
Links are instances of associations between objects at a specific point in time.
Aggregations apply when one object contains another object.
Composition is a strong form of aggregation.
Generalization is when one class is a specialization of another class.

30. Terms and Concepts
Messages are an abstraction of object communication.
Use cases describe the primary and secondary functions of a system.
A scenario is a specific path (sequence of operations on objects) through a use case.
Actors are interacting objects outside the scope of a system.

31. Objects
All objects are entities that model some physical or conceptual entity. They have several aspects at run-time:
Identity
Attributes (data or named property)
Behavior (operation or method)
State (memory)
Responsibilities

32. Example: Sensor Object
Attributes: Sensor Value, Rate of Change (RoC)
Behavior: Acquire, Report, Enable, ...
State: Last Sensor Value, Last RoC
Identity: Instance for robot arm joint
Responsibility: Provide information about the location of the robot arm in absolute space coordinates.

33. Object Components Public interface
Hidden (encapsulated) implementation
methods
public attributes
Sensor1:
void:set_rate (int x); {
rate = x;
reset( );
… };
+temperature : float
public operations
+reset ( )
+get_value( )
+set_rate(int x)

34. Conceptual Objects Not all objects represent physical entities.
For example, the “telephone call” object:
Telephone Call Object
Telephone Call
Telephone1
Telephone2
createCall ( )
abortCall ( )
addCallingParty (t:Telephone)

35. Classes and Instances
Design-time specifications can be used to instantiate one or more distinct objects at run-time with a common form (structure and behavior)
class
(design time)
phone1:Telephone
busy = true
offHook()
onHook ()
ring()
instance
(run time)
Telephone
busy : boolean
offHook()
onHook ()
ring()
phone2:Telephone
busy = false
offHook()
onHook ()
ring()

36. Object Behavior Example: Simple reactive server model:
Initialize Object
Processing depends on request type and object state
Wait For Request
void:getROC (); {busy = true; obj.readSensor(); … };
Process Request
May invoke ops on other objects
Terminate Object

37. Types of Objects Passive Objects - invoked by external threads
Active Objects - include own single thread
Handle Request
Initialize Object
Terminate Object
Handle Request
Initialize Object
Terminate Object
Wait For Request
Wait For Request

38. Inheritance and Polymorphism
TelephoneClass
busy : boolean
offHook()
onHook ()
dialDigit()
Generalization
(inheritance)
association
TouchTone TelephoneClass
busy : boolean
offHook()
onHook ()
dialDigit()
playTone()
RotaryDial TelephoneClass
busy : boolean
offHook()
onHook ()
dialDigit()
Polymorphism:
an operation ( e.g., dialDigit( ) ) is implemented differently in
different classes

39. Why Build Models? Understand the problems better
Facilitate communication between customers and developers
Find errors or omissions in the design
Plan out the design and analysis
Automate code generation

40. UML Models Requirements (use case diagrams)
Static structure (class diagrams)
Dynamic behavior (state machines)
Interactive behavior (activity, sequence, and collaboration diagrams)
Physical implementation structures (component and deployment diagrams)

41. Class Diagram - Static Structure
association class
Financial Institution
client
creditor
0..*
Person
Mortgage
principal
rate
term
owner
0..*
Bank
Trust Company
generalization
association
0..* 1
residence
0..*
{ordered}
House

42. Object Instance Diagram
link
TheBank : Bank
JoeCool:Person
first : Mortgage
second : Mortgage
cabin : House
home : House

43. State Machine Diagram state machine initial state state created
ready
Initialize Object
state
trigger
Wait For Request
start/^master.ready()
poll/^master.ack()
stop/
Handle Event
action
final state
Terminate Object
transition

44. State Machine Behavior
created
ready
start/^master.ready()
start/
stop/
poll/defer
ready
created
start
start/^master.ready()
ready

45. Active Objects in the UML
Concurrent incoming events are queued and handled one-at-a-time regardless of priority; e.g., run-to-completion (RTC) execution model
ActiveObject:

46. RTC and Concurrency Eliminates need to write synchronization code:
if all passive objects are encapsulated by an active object, only a single thread can pass through each passive object
an active object acts as an implicit critical section

47. Types of Actions Entry action: executed on state entry
Exit action: executed on state departure
Internal transition: a self transition
Operational
request/procRequest();
start/
stop/
entry/^m.entered();
exit/^m.departed()
poll/^m.ack()

48. Requirements Analysis
Requirements are used to specify the functionality that must be provided by the system. They are typically understood and specified by domain experts.
A use case model documents the system’s intended functions (use cases), surroundings (actors), and relationships between actors and use cases.

49. System Requirement Categories
Functional Requirements - define system behavior as viewed from the outside (system as a black box).
Example: When a sensor detects a weed, the corresponding sprayer should be activated.
Quality of Service (QoS) Requirements - specify performance, reliability, and safety properties of functional requirements.
Ex: Actuate the sensor within 15 msec.

50. Use Case The main tool used to capture functional requirements.
A coherent piece of functionality visible (in black box form) from outside the system.
Strictly behavioral, does not define or imply a specific internal structure (objects or classes).

51. Use Case Motivation
Use cases help with the three of the most difficult aspects of development:
capturing requirements,
planning iterations of development, and
system testing
They were first introduced by Ivar Jacobson (in the early 1990’s).

52. <<uses>>
Actors
Objects in the system’s external universe that interact with the system.
Human users, external subsystems, or devices.
Actor A
use case 1
Actor B
<<uses>>
use case 2
system boundary

53. A Simple Use Case Diagram
Deposit Money
Withdraw Money
Bank
Customer
Transfer Money
Between Accounts
Jacobson, “Software Reuse”, Fig. 3.16

54. Actors
An actor is an object in the system’s external universe that interacts with the system; e.g., human users, external subsystems, or devices.
More specifically, an actor represents a class of users; e.g., a bank may have many customers represented by one actor.
An actor is represented as a stick figure in a use case diagram.

55. Use Cases
A use case is shown on a use case diagram as a named oval. The name describes the coherent unit of work; e.g. Withdraw Money.
A use case includes a description of the sequence of messages exchanged between the system and any actors, and actions performed by the system in response.

56. Use Case Diagram

57. Textual Part of Use Case

58. Requirements Capture
Use cases help in requirements capture by providing a structured way to:
identify the actors
for each actor, identify
what they need from the system
interactions they expect to have with the system
use cases in which they participate

59. Notes
Some aspects of system behavior may not show up as use cases for actors.
Some use cases may not interact with any actor; these use cases are called abstract.
In Rational Rose, relationships between use cases are called “generalizations”; note that use case generalizations are different than generalizations between classes.

60. Development Planning
At the end of the Elaboration Phase (or by the end of analysis), we should have generated a complete list of use cases with:
an understanding of what is important to whom,
which use cases carry the most risk including requirements risk, technological risk, safety risk, performance risk, and skills risk, and
a plan for how long it should take to implement each use case.

61. Relationships Between Use Cases
Represented as an open-headed arrow on the use case diagram.
Two types of relationships are distinguished by giving different stereotypes:
<< uses >> - to reuse a use case; the source use case makes use of the target use case
<< extends >> - to separate variant behavior; the source use case specializes or extends the behavior of the target use case

62. << uses >>
Original use case that was
identified in our analysis.
Customer
Withdraw Money
<< uses >>
Part of the behavior that
we decided to factor out
for reuse (e.g., transfer
also uses check account
balance).
Check Account Balance

63. Rational Rose Example
Double-click on the generalization arrow and specify a stereotype of “uses”.

64. Example (continued)

65. << extends >>
Base use case.
Normal behavior.
Withdraw Money
Customer
<< extends >>
Client use case.
Specialized behavior.
Fast Cash

66. Problems With Use Cases
Focusing on use cases may cause developers to lose sight of the system architecture; e.g., designing a top-down, function-oriented, inflexible system.
Developers may mistake requirements for design; e.g., focus only on operational requirements.
By focusing on actors, developers may miss some use cases; e.g., internal ones.

67. Detailing Use Case Behavior
Textual Description - textual part of use case (previous slide)
Scenarios
Sequence Diagrams - show the sequence of messages between objects
Collaboration Diagrams - show collaboration between objects
Statecharts

68. Sequence Diagrams
Initial sequence diagrams at the use case level specify messages exchanged between actors and the system; e.g., there is only one object -- the system.
Later, sequence diagrams are refined to represent more details; e.g., timing constraints, etc.

69. Example Sequence Diagram

70. Example Collaboration Diagram

71. External Event List
Detailed list of environmental messages and events of interest to the system, including:
Event
Description
Direction (to system, or to specific actor)
Arrival pattern (periodic, sporadic, jitter, etc.)
Response performance (deadline)

72. Summary
The UML is an industry standard for analysis and design of object-oriented systems, and provides users with an expressive visual modeling language.
The UML can be used in many different domains to capture domain-specific concepts. It also provides extensibility and specialization mechanisms.
Latest draft version UML 1.5 is a work in progress: