2. Recap : UML artefacts Black Box Requirements Functional Specification
Actors
Use Cases
Use Case Diagrams
Storyboards
Black Box Requirements
Functional Specification
Diagrams:
Class Sequence Statechart Activity
System Test
System Design
Test Cases
System Development
System Validation
Notes
Details
Signatures

3. Modeling the run-time view! Software Design
Today
Modeling the run-time view!
Software Design
Metrics
Classification
Code Review

4. Modeling using UML Diagrams are the main artefacts of UML.
(These are not a sequence of steps!!!!)
Use case diagrams
Functional behavior of the system as seen by the user.
Activity diagrams
Dynamic behavior of a system expressed as a flowchart.
Class diagrams
Static structure of the system: Objects, Attributes, and Associations.
Sequence diagrams
Dynamic behavior between actors and system objects.
Statechart diagrams
Dynamic behavior of an individual object.
...

5. Use Case Example Name: Purchase ticket Participating actor: Passenger
Entry condition:
Passenger standing in front of ticket distributor.
Passenger has sufficient money to purchase ticket.
Exit condition:
Passenger has ticket.
Event flow:
1. Passenger selects the number of zones to be traveled.
2. Distributor displays the amount due.
3. Passenger inserts money, of at least the amount due.
4. Distributor returns change.
5. Distributor issues ticket. 25

6. UML Sequence Diagrams In requirements analysis In system design
Passenger
In requirements analysis
To refine use case descriptions
to find additional objects (“participating objects”)
In system design
to refine subsystem interfaces
Columns = classes
Arrows = messages
Narrow rectangles = activations
Dashed lines = lifelines
TicketMachine
selectZone()
insertCoins()
pickupChange()
pickUpTicket() 38

7. UML Sequence Diagrams: Nested Messages
Passenger
TarifSchedule
Display
ZoneCheckbox
selectZone()
lookupPrice(selection)
price
Dataflow
displayPrice(price)
…to be continued...
The source of an arrow indicates the activation which sent the message
An activation is as long as all nested activations 39

8. Sequence Diagram Observations
UML sequence diagram represent behavior in terms of interactions
Run-time view
They complement class diagrams, which represent structure
Compile-time view
Very useful for finding participating objects
Time-consuming to build but worth the investment where interactions are complex 40

9. Sequence Diagram Object Message Activation blinkHours() blinkMinutes()
incrementMinutes()
refresh()
commitNewTime()
stopBlinking()
pressButton1()
pressButton2()
pressButtons1And2()
:WatchUser
:Time
:LCDDisplay
:SimpleWatch
Message
Activation 18

10. Sequence Diagrams – Interaction Frames
alt (conditional)
opt (optional)
par (run in parallel)
loop (iteration)
region (one thread)
neg (invalid)
ref (reference: defined in another diagram)

11. Statechart Diagrams State Initial state Event Transition Final state
button1&2Pressed
button1Pressed
button2Pressed
Increment
Minutes
Hours
Blink
Seconds
Stop
Blinking
Initial state
Event
Transition
button1&2Pressed
Final state 19

12. Summary
UML provides a wide variety of notations for representing many aspects of software development
Powerful, but complex language (keep it simple!)
Can be misused to generate unreadable models (automatic generators)
Can be misunderstood when using too many exotic features (KISS!)
We concentrate only on a few notations:
Functional model: use case diagram
Object model: class diagram
Dynamic model: sequence, statechart and activity diagrams
UML is not a methodology, but the textbook describes a methodology that uses UML 45

13. UML artefacts Black Box Requirements Functional Specification
Actors
Use Cases
Use Case Diagrams
Storyboards
Black Box Requirements
Functional Specification
Diagrams:
Class Sequence Statechart Activity
System Test
System Design
Test Cases
System Development
System Validation
Notes
Details
Signatures

14. Measuring quality of abstractions
We will never make an ultimate
design on the first try.
Design is an incremental and
iterative process!
How can we know if our
architecture is well designed?
When shall we stop the design
process?
Five meaningful metrics:
1. Coupling
2. Cohesion
3. Sufficiency
4. Completeness
5. Primitiveness

15. Coupling "Coupling is the strength of association between modules."
Strong coupling makes a system harder to understand,
change or correct.
Complexity can be reduced by designing for weak coupling.
Inheritance introduces significant coupling!
Thus, select inheritance as a design method restrictively.

16. Coupling Aggregation = weak coupling Composition = strong coupling
TicketMachine 3
Aggregation = weak coupling
ZoneButton
Composition = strong coupling
Exhaust System 1
0..2
Muffler
Tailpipe
Button
ZoneButton
CancelButton
Inheritance = strongest coupling

17. Cohesion
"Cohesion measures the degree of connectivity within a module."
Try to avoid coincidental cohesion, where entirely unrelated abstractions form a class or module.
Thus, struggle for well-bounded behavior, where functional cohesiveness is achieved (semantics kept within the module).
A class should be focused on one kind of thing

18. Sufficiency
"A sufficient module captures enough characteristics of the abstraction to permit meaningful and efficient interaction."
Keep it small! Keep it simple!
Sufficiency implies a minimal interface.

19. Completeness
"A complete module captures all the meaningful characteristics of the abstraction."
Completeness implies an interface that covers all aspects of the abstraction.
Thus, an interface that is general enough to be commonly usable.
It is very subjective, and is easily overdone!

20. Primitiveness
"Primitive operations are those that can be efficiently implemented only if given access to the underlying representation of the abstraction."
Each method should be focused on one thing

21. Measuring quality of abstractions
Five meaningful metrics:
1. Coupling
2. Cohesion
3. Sufficiency
4. Completeness
5. Primitiveness
What are the important choices?

22. Choosing operations Crafting an interface is plain hard work.
As we do the design, we find patterns of abstractions that leads us to create new classes or to reorganize existing ones, incrementally.
The aim to to create primitive operations, which exhibit a small well-defined behavior.
We call these fine-grained.

23. Choosing operations To contract out behavior to: 1. one operation
simpler interface large complex operations
unmanageably modules
2. several operations
complex interface
simpler operations
fragmentation
This is one of the core arts in design.

24. Choosing operations
What is a Method?
Function (check state)
Procedure (change state)
A mixture of the above?

25. Criteria for choosing operations
1. Reusability
Would this behavior be useful in more than one context?
2. Complexity
How difficulty is it to implement the behavior?
3. Applicability
How relevant is the behavior to the type?
4. Implementation knowledge
Does the behavior's implementation depend upon the
internal details of a type?
Defining utility classes can help keeping a class primitive.

26. Choosing relationships
Class structure when using inheritance, aggregation and composition:
Narrow and deep
Balanced
Wide and shallow
Inheritance
Trees of classes with a common super class
Small classes
Exploits commonality
Hard to understand
Combination
Hard to define
Hard to achieve
Successful trade-off
Aggregation or Composition
Forests of loosely coupled classes
Large classes
May not exploit commonality
Easier to understand

27. Choosing relationships, Rules of thumb
Rule of thumb 1:
"Inheritance is appropriate when every instance of one class may
also be viewed as an instance of another class." IS-A
Rule of thumb 2:
"If the behavior of an object is more than the sum of its individual
parts, then aggregation is probably the superior." HAS-A
Rule of thumb 3:
"Favor composition over inheritance."

28. Choosing implementation
The representation (implementation) of a class should
always be an encapsulated secret of abstraction.
That is, hide the implementation!
Program to an interface, not an implementation!
This makes it possible to alter the implementation
without violating the interface and behavior!!!

29. Choosing implementation, example
Class Square_Efficient_Storage {
int width;
void setWidth(int width) {
this.width = width; }
int getArea() {
return width*width; …
Class Square_Efficient_Computation {
int area;
area = width*width;
return area;
The most common
trade-off is
storage
versus
computation.
Example:
Imagine a square, which has a width.
Should we store the area or calculate it each time we need it?
The answer is to store if focus is on speed, and to calculate if focus is on space efficiency.

30. ZZZZZZ...oxygen anyone?

31. What is this? ?

32. It’s this!

33. Classification The identification of classes and objects
involves both discovery and invention.
Discovery:
Recognizing key abstractions and mechanisms,
that form the vocabulary of the problem domain.
Invention:
Devising generalized abstractions as well as new
mechanisms that specify how objects collaborate.
Classification is grouping common structures or behavior.

34. Classification: Snake, Lion or Giraffe?

35. Classification
Classification help us identify generalization, specialization
and aggregation hierarchies among classes.
Coupling and cohesion is metrics for the commonality among
classes and objects.
The best software designs look simple, but it takes a lot of hard
work to design a simple architecture.

36. Evolving classification
Derivation
Creating new subclasses from existing ones.
Factorization
Splitting a large class into several smaller ones.
Composition
Create one larger class by uniting smaller ones.
Abstraction
Discover commonality and devise a new class.

37. Classification The developer has two primary design tasks, to find:
Key abstractions Discover the classes and objects that form the vocabulary of the problem design.
Mechanisms Invent relational structures for meeting requirements of collaborative behavior.

38. Classification...
...is about finding common attributes!

39. Classify... ...the trains by yourself! Select any method that
You deem proper.
3 minutes

40. The trains classified... One solution per person is likely!
Half of the solutions are unique!
Some examples:
The length of the trains
The color of the wheels
Curved lines in the letters (A E F H I vs. B C D G J)
Some solutions are more inventive than
others, especially when using non-linear
thinking and creative insight!

41. To classify... ...is easier when more is known! What if:
triangles = atomic waste
squares = persons
Systems experts are vital!

42. Who is right?

43. Recap Implementation Program to an interface, not an implementation!
Operations
Reusability, Complexity, Applicability, Primitiveness
Method: Function (check state) or Procedure (change state)

44. The first quiz will be on the next lecture (Friday, September 13)
Will cover the material of the first 5 lectures

45. That’s all folks! Thanks for your attention!