1. Modeling software behavior UML
Acknowledgement: some slides from Philippe Kruchten, Steve Easterbrook

2. Philippe Kruchten
What is a model?
Fall 2007
A representation of a system that allows for investigation of the properties of the system.
Brief Introduction to UML

3. Why build one? A model can guide your exploration:
It can help you figure out what questions to ask
It can help to reveal key design decisions
It can help you to uncover problems
e.g. conflicting or infeasible requirements, confusion over terminology, scope, etc
Can help you check your understanding
Reason about the model to understand its consequences
Does it have the properties you expect?
Animate the model to help us visualize/validate requirements
Can help you communicate
Provides useful abstracts that focus on the point you want to make
…without overwhelming people with detail
Throw-away modeling?
The exercise of modeling is more important than the model itself
Time spent perfecting the models might be time wasted…

4. What is UML? What UML is not Modeling language Not a method in itself
Philippe Kruchten
What is UML?
Fall 2007
Modeling language
What UML is not
Not a method in itself
A notation designed to support various methods for requirement analysis and software design
E.g., (IBM) Rational Unified Process (RUP)
Brief Introduction to UML

5. Two types of UML diagrams
Philippe Kruchten
Two types of UML diagrams
Fall 2007
Static Diagrams
Use-Case
Diagrams
Class
Diagrams
Sequence
Diagrams
Object
Diagrams
Collaboration
Diagrams
Component
Diagrams
Models
Statechart
Diagrams
Deployment
Diagrams
Activity
Diagrams
Dynamic Diagrams (Behavior and Interaction
Brief Introduction to UML

6. Visual modeling of a software system
Philippe Kruchten
Visual modeling of a software system
Fall 2007
Use-Case Diagram
State Diagram
Class Diagram
Use Case 1
GrpFile
read( )
open( )
create( )
fillFile( )
rep
Repository
name : char * = 0
readDoc( )
readFile( )
(from Persistence)
FileMgr
fetchDoc( )
sortByName( )
DocumentList
add( )
delete( )
Document
name : int
docid : int
numField : int
get( )
close( )
sortFileList( )
fillDocument( )
fList 1
FileList
File
read() fill the
code..
Actor A
Actor B
Use Case 2
Use Case 3
Deployment Diagram
Collaboration Diagram
9: sortByName ( )
Document
FileManager
GraphicFile
File
Repository
DocumentList
FileList
mainWnd : MainWnd
Window95
Windows95
1: Doc view request ( )
Windows95 L
2: fetchDoc( )
4: create ( )
gFile : GrpFile
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼­°ü¸®
¹®¼­°ü¸® ¾ÖÇø´
8: fillFile ( )
Windows
user : Clerk NT
Solaris
fileMgr : FileMgr
6: fillDocument ( )
3: create ( )
¹®¼­°ü¸® ¿£Áø.EXE
Windows NT
ÀÀ¿ë¼­¹ö.EXE
Alpha
UNIX
7: readFile ( )
5: readDoc ( )
Mainframe
IBM
repository : Repository
document : Document
µ¥ÀÌŸº£À̽º¼­¹ö
Component Diagram
mainWnd
fileMgr :
FileMgr
document :
Document
gFile
repository
user
ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
1: Doc view request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â
¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­
6: fillDocument ( )
Forward and Reverse Engineering
7: readFile ( )
8: fillFile ( )
È­¸é °´Ã¼´Â ÀоîµéÀÎ
°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡
º¸¿©ÁØ´Ù.
9: sortByName ( )
Sequence Diagram
Brief Introduction to UML

7. Elements of UML Diagrams
Philippe Kruchten
Elements of UML Diagrams
Fall 2007
Elements
Connectors
Adornments
Annotations
Brief Introduction to UML

8. Philippe Kruchten
Reminder: Class
Fall 2007
A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics.
A class may use a set of interfaces to specify collections of operations it provides to its environment
Brief Introduction to UML

9. Philippe Kruchten
Reminder: Object
Fall 2007
An entity with a well-defined boundary and identity that encapsulates state and behavior .
State is represented by attributes and relationships;
Behavior is represented by operations, methods, and state machines.
An object is an instance of a class.
Brief Introduction to UML

10. Modeling elements: class, interface
Philippe Kruchten
Modeling elements: class, interface
Fall 2007
Brief Introduction to UML

11. Types of relationships in class diagrams
Philippe Kruchten
Types of relationships in class diagrams
Fall 2007
Class level:
Dependency:
x depends on y (for implementation, for example)
A dependency exists between two defined elements if a change to the definition of one would result in a change to the other.
Generalization (& specialization):
x is a kind of y (taxonomy, subclassing)
Instance level
Association:
x is a part of y
Brief Introduction to UML

12. Class Level Relationships: Dependency and Generalization
Philippe Kruchten
Class Level Relationships: Dependency and Generalization
Fall 2007
Brief Introduction to UML

14. Types of relationships in class diagrams
Philippe Kruchten
Types of relationships in class diagrams
Fall 2007
Class level:
Dependency:
x depends on y (for implementation, for example)
A dependency exists between two defined elements if a change to the definition of one would result in a change to the other.
Generalization (& specialization):
x is a kind of y (taxonomy, subclassing)
Instance level
Association:
x is a part of y
Brief Introduction to UML

15. Instance-Level Relationships: Association
Philippe Kruchten
Instance-Level Relationships: Association
Fall 2007
A relationship that models a bi (or multi)-directional semantic connection among instances.
An association
represents a
family of links
Brief Introduction to UML

16. One more association example
Philippe Kruchten
One more association example
Fall 2007
Role
Activity
0..* 1
Performs
Artifact
IsResponsibleFor
input
Consumes
Produces
Brief Introduction to UML

17. Two Special Cases of Associations
Philippe Kruchten
Two Special Cases of Associations
Fall 2007
Aggregation = grouping (e.g., “by reference”)
Composition = is made of (e.g., “by value”)
Brief Introduction to UML

18. Composition versus Aggregation
Philippe Kruchten
Composition versus Aggregation
Fall 2007
Course
Instructor ?
Car
Carburetor ?
Brief Introduction to UML

19. Composition versus Aggregation
Philippe Kruchten
Composition versus Aggregation
Fall 2007
Course
Instructor
Aggregation
Car
Carburetor
Composition
Brief Introduction to UML

20. Composition versus Aggregation
Philippe Kruchten
Composition versus Aggregation
Fall 2007
Assume A associated with B
If I destroy an object A, is the associated B also destroyed?
Yes? you probably have a composition
If an object A1 is associated with object B1, can the same object B1 be also associated with another object A2
Yes? you probably have an aggregation
Brief Introduction to UML

21. Composition vs. Aggregation
Philippe Kruchten
Composition vs. Aggregation
Fall 2007
The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must be for only one whole.
The whole of an aggregation may have any multiplicity.
Example:
represent real-world whole-part relationships,
e.g., an engine is part of a car,
 the composition relationship is most appropriate.
represent database relationship,
e.g., car model engine ENG01 is part of a car model CM01,
 an aggregation relationship is best, (as the engine, ENG01 may be also part of a different car model)
Brief Introduction to UML

22. Class Diagram (2) Philippe Kruchten Fall 2007
Brief Introduction to UML

23. Exercise
A system requires representation of folders and files. Both folders and files have names, creation date, and size. Files must be contained in folders and folders may contain files and other folders.
Draw the class diagram
Now add symbolic links

24. One more …
A company consists of departments. Departments themselves can be made of other sub-departments.
Departments are located in one or more offices. One office acts as the company headquarter.
Each department has a manager who is recruited from the set of employees of that department.
An employee is associated with one or more departments but it has one ‘home’ department.
Your task is to model the system for the company.
Draw a class diagram with the classes in your system their attributes, operations and relationships, multiplicity specifications, and other model elements that you find appropriate.

25. Summary so far: What UML class diagrams can show?
Division of Responsibility
Operations that objects are responsible for providing
Subclassing
Inheritance, generalization
Navigability / Visibility
When objects need to know about other objects to call their operations
Aggregation / Composition
When objects are part of other objects
Dependencies
When changing the design of a class will affect other classes
Interfaces
Used to reduce coupling between objects

26. Uses of UML As a sketch As a blueprint As a programming language
Very selective - informal and dynamic
Forward engineering: describe some concept to implement
Reverse engineering: explain how some part of the program works
As a blueprint
Emphasis on completeness
Forward engineering: model as a detailed spec for the programmer
Reverse engineering: model as a code browser
Roundtrip: tools provide both forward and reverse engineering to move back and forth between program and code
As a programming language
UML models are automatically compiled into working code
Requires sophisticated tools
“tripless” - the model is the code

27. Package decomposition
Find dependencies between packages

28. Class Abstraction

29. Things to Model Structure of the code E.g. Behaviour of the code
Code Dependencies
Components and couplings
E.g. Behaviour of the code
Execution traces
State machines models of complex objects
E.g. Function of the code
What functions does it provide to the user?

30. Modeling Dynamic Behavior
Sequence diagram
Depict object interaction by highlighting the time ordering of method invocation

31. Sequence diagram example

32. Sequence diagram

33. Interaction Frames

34. Interaction Frame Operators
Meaning
alt
Alternative; only the frame whose guard is true will execute
opt
Optional; only executes if the guard is true
par
Parallel; frames execute in parallel
loop
Frame executes multiple times, guard indicates how many
region
Critical region; only one thread can execute this frame at a time
neg
Negative; frame shows an neg invalid interaction
ref
Reference; refers to a sequence shown on another
Diagram sd
Sequence Diagram; used to surround the whole
diagram (optional)

35. When to use sequence diagrams
Comparing Design Options
Shows how objects collaborate to carry out a task
Graphical form shows alternative behaviours
Assessing Bottlenecks
E.g. an object through which many messages pass
Explaining Design Patterns
Enhances structural models
Good for documenting behaviour of design features
Elaborating Use Cases
Shows how the user expects to interact with the system
Shows how the user interface operates

36. Modeling a design pattern: The Observer Pattern
An object, i.e., the subject, maintains a list of its dependents, the observers, and notifies them of any state changes, usually by calling one of their methods. 

37. Sequence Diagram for observer pattern
What should this look like?

40. Recap: Sequence Diagram Key Parts
participant: object or entity that acts in the diagram
diagram starts with an unattached "found message" arrow
message: communication between participant objects
the axes in a sequence diagram:
horizontal: which object/participant is acting
vertical: time (down -> forward in time)

45. Style Guide for Sequence Diagrams
Spatial Layout
Strive for left-to-right ordering of messages
Put proactive actors on the left
Put reactive actors on the right
Readability
Keep diagrams simple
Don’t show obvious return values
Don’t show object destruction
Usage
Focus on critical interactions only
Consistency
Class names must be consistent with class diagram
Message routes must be consistent with (navigable) class associations

46. Draw a sequence diagram for: Netflix process to deal with returned DVDs
When a return comes in a person scan’s it in, the S/W detects that and goes through a sequence of steps to send a new movie to a customer.
Think of the different classes that would be involved: Queue, Shipping, Inventory, UserAccount, other classes??
Coming up: In class exercise

47. Modeling Dynamic Behavior: State diagrams
Depict the flow of control using the concepts of state and transitions
Labels of transitions are in the form:
[Event-List][[Guard]][/Action]
Entry action and exit action
entry/Action1 or exit/Action2

48. Modeling Dynamic Behavior: State Diagrams
Nested state diagram
Composite of state diagrams

49. Example

50. Exercise
Reservations are made for repairs of vehicles (if space is available, otherwise they are added to a waiting list). The vehicle is delivered and waits in the dock until repair can commence. Repair can commence at any time. During repair new parts may be needed and the vehicle may have to wait for the parts to arrive. When repairs are completed a test drive is organized. Following the test, more repairs may be needed, or the vehicle will become ready to be picked up. Eventually the vehicle is picked up by its owner.

51. Two types of UML diagrams
Philippe Kruchten
Two types of UML diagrams
Fall 2007
Static Diagrams
Use-Case
Diagrams
Class
Diagrams
Sequence
Diagrams
Object
Diagrams
Collaboration
Diagrams
Component
Diagrams
Models
Statechart
Diagrams
Deployment
Diagrams
Activity
Diagrams
Dynamic Diagrams (Behavior and Interaction
Brief Introduction to UML

52. Design Patterns “Each pattern describes
a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”.
--- Christopher Alexander, 1977
This was in describing patterns in buildings and towns.
In SE, design patterns are in terms of objects and interfaces, not walls and doors.
The manner in which a collection of interacting objects collaborate to accomplish a specific task or provide some specific functionality.

53. Architecture vs. Design Patterns
Key decisions ….
Design Patterns
Lower level than architectures (Sometimes, called micro-architecture)
Reusable collaborations that solve subproblems within an application
how can I decouple subsystem X from subsystem Y?
Why Design Patterns?
Design patterns support object-oriented reuse at a high level of abstraction
Design patterns provide a “framework” that guides and constrains object-oriented implementation

54. What is a Design Pattern?
A design pattern is a general reusable solution to a commonly occurring problem A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

55. Gamma, Helm, Johnson , Vlissides
Design Patterns : Elements of Reusable Object-Oriented Software (1995) ,
Gamma, Helm, Johnson , Vlissides
Factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Interpreter
Template
Chain of
Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Creational
Structural
Behavioral 55

56. 4 Essential Elements of each Design Pattern
Name: identifies a pattern
Problem: describes when to apply the pattern in terms of the problem and context
Solution: describes elements that make up the design, their relationships, responsibilities, and collaborations
Consequences: results and trade-offs of applying the pattern

57. More patterns: Singleton
Ensure a class has only one instance, and provide a global point of access to it.
public class Singleton {
private Singleton() {}
private static _instance = null;
public static S getInstance () {
if (_instance == null) _instance = new Singleton();
return _instance; }
...
multiton
named instances
double-checked locking:
Singleton getInstance() {
if(_instance == null) {
lock(Singleton.class) { }
return _instance;
Lazy instantiation
Tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.
Singleton
# _instance : Singleton
# Singleton()
+ getInstance() : Singleton
return _instance;

58. One more pattern: Factory
Define an interface for creating an object, but let subclasses decide which class to instantiate.
Factory Method lets a class defer instantiation to subclasses.
Product
Creator
+ CreateProduct() : Product
+ SomeOperation()
...
Product product = CreateProduct();
ConcreteCreator
+ CreateProduct() : Product
ConcreteProduct
return new ConcreteProduct();
5858