1. SOEN 343 Software Design
Computer Science and Software Engineering Department
Concordia University
Fall 2004
Instructor: Patrice Chalin

2. Agenda – Lecture 4b OO: mutability
Simplify the process and skip Design!
Hmmm, no, bad idea.
Design Model
Design documentation
Inertia in writing and maintaining it.
Making sure your Design Model is kept “live”.
12/4/2018
SOEN 343, © P.Chalin,

3. Opening Remarks
OO fundamentals is essential to achieving success in this course.
Exercise sets and tutorials are important.
Give you a chance to exercise your skills.
If you do not understand, try it out, post to the mailing list, ask a friend, a tutor or instructor, …
Lectures
If you do not understand, ask!
Tutorial: e-submit your work – Proposal 4.
12/4/2018
SOEN 343, © P.Chalin,

4. Mutability An object is either mutable or immutable.
The state of immutable objects never change.
String t = “a”;
String s = “b”;
t = t + “z”;
For answer see Exercise Set remarks (course web site, Schedule page).
12/4/2018
SOEN 343, © P.Chalin,

5. Design Model: Sequence Diagrams
Participants:
Customer class
r : Rental (object)
m : Movie (object).
UML1 convention: if participant is …
Underlined then it denotes an object (i.e. a class instance).
Not underlined: it denotes a class.
Customer
m : Movie
r : Rental
1 : getMovie ( )
2 : getPriceCode ( ) m
12/4/2018
SOEN 343, © P.Chalin,

6. Why Not Skip Design?
Requirements: Problem to be solved, or Service needed.
Design: ?
Implementation: System realizing a Solution, offering Service.
12/4/2018
SOEN 343, © P.Chalin,

7. Skip Design? Possible for programming-in-the-small.
Feasible for target SW Engineering proj.?
How about other fields of engineering …
12/4/2018
SOEN 343, © P.Chalin,

8. Design: A Solution Plan or Model
Solution “plan” (compared to the implementation).
Why “plan” a solution vs. implement it directly?
Suppose we do design, how can we express it?
12/4/2018
SOEN 343, © P.Chalin,

9. Design Languages / Notations
Natural language.
Subset of programming language.
Graphical notations.
UML arose out of a concerted effort.
12/4/2018
SOEN 343, © P.Chalin,

10. Expressing Designs Using UML
Collection of design artifacts we will call a
Design Model
12/4/2018
SOEN 343, © P.Chalin,

11. Design Models Two main aspects Structure Behavior
12/4/2018
SOEN 343, © P.Chalin,

12. Design Models: Structure
We can model
Structure
Behavior
Structure:
Documented mainly via “class” diagrams.
Can illustrate more than classes.
Here are some examples … (details are not important).
12/4/2018
SOEN 343, © P.Chalin,

13. Design Model: Subsystems
Excerpt from Larman.
12/4/2018
SOEN 343, © P.Chalin,

14. Design Model: Classes & Interfaces
Example of a composite pattern.
Excerpt from Larman.
12/4/2018
SOEN 343, © P.Chalin,

15. Design Model: Classes & Interfaces
Excerpt from Larman.
12/4/2018
SOEN 343, © P.Chalin,

16. Design Model: Structure - Summary
Documented mainly via class diagrams.
Entities captured
Packages (subsystems).
Classes.
Interfaces.
Other “structural” UML diagram types:
Package, component, deployment, …
12/4/2018
SOEN 343, © P.Chalin,

17. Design Models: Behavior
We can model
Structure
Behavior
Behavior:
Documented via interaction diagrams.
Most popular: sequence diagrams.
12/4/2018
SOEN 343, © P.Chalin,

18. Design Models: Behavior
Examples.
12/4/2018
SOEN 343, © P.Chalin,

19. Design Model: Sequence Diagrams
Participants:
c : Customer,
r : Rental,
m : Movie
Each participant has a life line (vertical dashed line)
Synchronous message
Return result
Activation bar
12/4/2018
SOEN 343, © P.Chalin,

20. Design Model: Sequence Diagrams
12/4/2018
SOEN 343, © P.Chalin,

21. Design Model: Sequence Diagrams – Larman’s Style for Return Messages
c : Customer
m : Movie
r : Rental
1 : getMovie ( )
2 : getPriceCode ( ) m
c : Customer
r : Rental
m : Movie
1 : m := getMovie ( )
2 : getPriceCode ( )
12/4/2018
SOEN 343, © P.Chalin,

22. Design Model: Sequence Diagrams – Larman’s Style for Return Messages
12/4/2018
SOEN 343, © P.Chalin,

23. Design Model: Collaboration (Communication – UML 2) Diagram
12/4/2018
SOEN 343, © P.Chalin,

24. Design Model: Behavior - Summary
Interaction diagrams.
Sequence diagrams.
Collaboration (Communication) diagrams.
Others :
Activity diagrams,
State machine diagrams,
(studied in SOEN 342).
12/4/2018
SOEN 343, © P.Chalin,

25. Design Documentation in Practice

26. Design Documentation in Practice
Documentation is sometimes produced, but …
… as system evolves … not maintained … hence looses its usefulness / value.
Can we do better?
Traditionally Design Artifacts, if produced at all, rapidly became out-of-date as S/W evolved.
12/4/2018
SOEN 343, © P.Chalin,

27. Design Documentation: Problems
Not always produced.
Usefulness decreases over time, either because
Increased mismatch with actual implementation.
Increased complexity  consolidation necessary.
12/4/2018
SOEN 343, © P.Chalin,

28. Evolution and Consolidation (Refactoring)
All evolving systems increase in complexity …
Redesign becomes necessary to consolidate changes
Retain same level of functionality while reducing complexity.
Hence refactoring.
12/4/2018
SOEN 343, © P.Chalin,

29. Evolutionary Design Gone Bad
Too small  new room.
Forgot door.
Changed mind about door.
Not enough light. …
No copyright notice on original.
12/4/2018
SOEN 343, © P.Chalin,

30. Design Documentation: Problems Summarized
Not always produced.
Over time
Increased gap: design vs. implementation.
Add-on syndrome.
12/4/2018
SOEN 343, © P.Chalin,

31. Addressing the Design Doc Problems
Approaches to design:
Planned Design
Evolutionary Design
12/4/2018
SOEN 343, © P.Chalin,

32. Approaches : Planned Design
Through analysis attempt to predict future changes.
12/4/2018
SOEN 343, © P.Chalin,

33. Approaches: Evolutionary Design
Admits that we generally cannot accurately predict the future evolution of a S/W application.
12/4/2018
SOEN 343, © P.Chalin,

34. Two Main Approaches To Design
Planned vs. Evolutionary.
Both can help address problems:
No design documentation produced.
Increased gap: design vs. implementation.
Add-on syndrome.
12/4/2018
SOEN 343, © P.Chalin,

35. Planned Design and MDD
In its most advanced form we have Model Driven Design (MDD) Model Driven Development Model Driven Architecture (MDA).
12/4/2018
SOEN 343, © P.Chalin,

36. Live Design Artifacts/Documentation?
“Live” means up-to-date and actively used.
How to ensure that Design Artifacts are live?
Why not derive implementation framework from the design model?
 Model Driven Design.
Why not derive implementation framework from the design?
That is precisely the idea of Model Drive Development.
12/4/2018
SOEN 343, © P.Chalin,

37. Flash Exercise: Two Main Approaches To Design
Planned:
MDD
Evolutionary: XP
How does each approach address:
No doc. produced.
Increased gap: design vs. impl.
Add-on syndrome.
12/4/2018
SOEN 343, © P.Chalin,

38. Model Driven Design (MDD)
Next few slides based on a presentation given by Bran Selic (IBM/Rational) on UML2 and MDA.
12/4/2018
SOEN 343, © P.Chalin,

39.    What Engineers Do Before they build the real thing...
…they first build models
…and then learn from them   
12/4/2018
SOEN 343, © P.Chalin,

40. Model Examples From Other Fields
12/4/2018
SOEN 343, © P.Chalin,

41. Engineering Models
Engineering model: A reduced representation (abstraction)
Modeled system
Model
12/4/2018
SOEN 343, © P.Chalin,

42. How Models are Used Help understand the system we are going to
Build.
Maintain.
Help detect errors and omissions in our proposed design solution before investing in implementation.
12/4/2018
SOEN 343, © P.Chalin,

43. Models of Software A description of the software which
Abstracts out irrelevant detail.
Presents the software using (higher-level) abstractions.
Hmm, what do you mean? Example please!
Follow example is a behavioral model.
The following example illustrates this difference between implementation and a model.
12/4/2018
SOEN 343, © P.Chalin,

44. Models vs. Implementation
case mainState of initial: send(initMsg); end Off: case event of on: send(oa,5); next(On); end off: next(Off); end end On: case event of off: next(Off); end done: terminate; end end end
Off On
on/send(oa,5);
off/
done/
Detail is a burden to understanding
This is a behavior model (vs. a structure model).
12/4/2018
SOEN 343, © P.Chalin,

45. How Models are Used Help understand. Help detect errors.
Drive implementation
MDD
12/4/2018
SOEN 343, © P.Chalin,

46. MDD: Evolving Models Adding detail to a high-level model: S1 S1 S2
e1/send(oa,5);
Adding detail to a high-level model:
e1[q=5]/ {d = msg->data(); send(oa,5, d);}
e2/ {printf(q);}
end/ {printf(“bye”);}
S21
e32/
12/4/2018
SOEN 343, © P.Chalin,

47. MDD in Rational XDE: Sample
Forward enginerring (code generation)
Reverse Engineering
12/4/2018
SOEN 343, © P.Chalin,