Dr Reuven Gallant Jerusalem College of Technology All

להנדסה תוכנה מערכות תיכון אישי פרויקט ופיתוח Dr. Reuven Gallant Jerusalem College of Technology All Rights Reserved-Dr. Reuven Gallant 1

The SHADOW All Rights Reserved-Dr. Reuven Gallant 2

How did the SHADOW get its name? ? ? • 2 Theories All Rights Reserved-Dr. Reuven Gallant 3

Theory I • Sikorsky Helicopter Advanced Demonstrator of Operator Workload All Rights Reserved-Dr. Reuven Gallant 4

Theory II • Jimmy Durante’s radio program and nose! All Rights Reserved-Dr. Reuven Gallant 5

All Rights Reserved-Dr. Reuven Gallant 6

Dessert (if anyone has room( All Rights Reserved-Dr. Reuven Gallant 7

The SHADOW was top secret!!!! • Not members of the U. S. House of Representatives… • Not even Senators… – Got to see the SHADOW All Rights Reserved-Dr. Reuven Gallant 8

The SHADOW was top secret!!!! • But the King got to fly in it! All Rights Reserved-Dr. Reuven Gallant 9

4 Helicopters were sent to fetch the King from Boston All Rights Reserved-Dr. Reuven Gallant 10

It was raining, and the King decided that discretion was the better part of valour All Rights Reserved-Dr. Reuven Gallant 11

Our course Jonah’s course All Rights Reserved-Dr. Reuven Gallant 12

Event Driven Reactive Systems (1): Inherited Behavior All Rights Reserved-Dr. Reuven Gallant 13

Event Driven Reactive Systems (2) All Rights Reserved-Dr. Reuven Gallant 14

Event Driven Reactive Systems (3) All Rights Reserved-Dr. Reuven Gallant 15

Event Driven Reactive Systems(4) All Rights Reserved-Dr. Reuven Gallant 16

Event Driven Reactive Systems(5) All Rights Reserved-Dr. Reuven Gallant 17

What is a (good) Design? • “Those characteristics of a system …that are selected by a developer in response to the requirements. ” …Some (characteristics) will be implementation-related, … such as software units and logic…to satisfy the requirements. ” MIL-STD-498 • TNTWI-WHDI? • We will return to this question throughout the course All Rights Reserved-Dr. Reuven Gallant 18

Course Objective (1): to know that good design is להיות יותר חכם מפ'רדי All Rights Reserved-Dr. Reuven Gallant 19

Course Objective (2) To know the state of the art All Rights Reserved-Dr. Reuven Gallant 20

Course Objective (3) To take yourselves seriously All Rights Reserved-Dr. Reuven Gallant 21

Course Objective (4) To program with models All Rights Reserved-Dr. Reuven Gallant 22

What we will learn • to apply ECSAM to Object Oriented Development – to deepen understanding of Statecharts • solidify knowledge of C++ – and its relation to Software Design – acquire good coding style conventions (as exemplified in Rhapsody • to learn how to build and understand UML models – to learn how to work with executable modeling tools • to learn why and how to apply Design Patterns • to learn why and how to design systems with reactive objects • to learn a viable development process for small projects – Agile Software Development, extreme programming, test first programming, refactoring • to learn something about personal life management – Stephen Covey’s 7 Habits of Highly Effective People All Rights Reserved-Dr. Reuven Gallant 23

What’s confusing about this course? • Example-based teaching – this is good • Each example repeats much of what was learned earlier – this is good, provided you keep clear what is old and what is new. • Examples usually require more than one of the skills in the previous slide – thus we have to learn (a little bit) of everything at once – this can be confusing!!!! All Rights Reserved-Dr. Reuven Gallant 24

Course Syllabus-Software Design • • Review of ECSAM (only most relevant parts) Review and enrichment of statecharts Introduction to Object Orientation (OOAD) UML symbology and mapping to Code – exemplified with Rhapsody • UML real-time approaches – exercised in Rhapsody • • Class Design Principles Package Design Principles Non-realtime examples (weather station) Real-time examples All Rights Reserved-Dr. Reuven Gallant 25

Course Syllabus-Personal Software Process • Personal and Interpersonal Growth and Development (leadership and management) – The 7 Habits of Highly Effective People • Management and Leadership of Small Projects – e. Xtreme Programming • Teamwork – Pair Programming • Software Requirements Analysis in the Small – Use Cases • Building in Software Quality – Refactoring All Rights Reserved-Dr. Reuven Gallant 26

Course Topics • ECSAM in UML • Principles of Class Design • Principles of Package Design • Case Study with Design Patterns • Real Time Object Oriented Design • Model Driven Development • Executable Models (Rhapsody) All Rights Reserved-Dr. Reuven Gallant 27

סופי מבחן של דוגמא All Rights Reserved-Dr. Reuven Gallant 35

http: //alum. mit. edu/www/rgallant =www-cc. jct. ac. il =cc/~rgallant@alum. mit. edu א 208 ויילר : חדר 6751016 : טל 6432145 : פקס : קבלה שעות 1330 -1400, 1800 -1830 ' ד , ' ב , ' יום א 1330 -1400 יום ג' במכון טל All Rights Reserved-Dr. Reuven Gallant 37

Class symbol in UML(1) All Rights Reserved-Dr. Reuven Gallant 38

Class symbol in UML(2) All Rights Reserved-Dr. Reuven Gallant 39

Class symbol in UML(3): Class Name All Rights Reserved-Dr. Reuven Gallant 40

Class symbol in UML(4): Attribute All Rights Reserved-Dr. Reuven Gallant 41

How do we define attributes? (1): from class features All Rights Reserved-Dr. Reuven Gallant 42

How do we define attributes? (2): from attribute features All Rights Reserved-Dr. Reuven Gallant 43

Class symbol in UML(5): operation All Rights Reserved-Dr. Reuven Gallant 44

How do we define operations? (1): from class features All Rights Reserved-Dr. Reuven Gallant 45

How do we define operations? (2): from operation features All Rights Reserved-Dr. Reuven Gallant 46

How do we define operations? (3): from operation features All Rights Reserved-Dr. Reuven Gallant 47

Generated Code for an Attribute • Save then edit the code for the Display class Initial Value Protected attribute Accessor Mutator All Rights Reserved-Dr. Reuven Gallant 48

All Rights Reserved-Dr. Reuven Gallant 49

Display -count : int +Display() +is. Done(): bool All Rights Reserved-Dr. Reuven Gallant 50

CG: CGGeneral: Generated. Code. In. Browser All Rights Reserved-Dr. Reuven Gallant 51

Class Source Files // File Display. h #ifndef Display_H #define Display_H class Display { public: Display(); ……. . }; #endif // File Display. cpp #include "Display. h" Display: : Display() { //#[ operation Display() cout << "Hello World" << endl; //#] } …… All Rights Reserved-Dr. Reuven Gallant 52

What is a component? Name Scope Executable All Rights Reserved-Dr. Reuven Gallant 53

What is a Configuration(1)? Name Current configuration All Rights Reserved-Dr. Reuven Gallant 54

What is a Configuration(2)? : Initial Instance All Rights Reserved-Dr. Reuven Gallant 55

What is a Configuration(3)? : ”Settings” Instrumentation Environment All Rights Reserved-Dr. Reuven Gallant 56

What is a Package in UML(1)? All Rights Reserved-Dr. Reuven Gallant 57

What is a Package in UML(2)? All Rights Reserved-Dr. Reuven Gallant 58

What is a reactive object? : Simple Statechart actions default transition timeout state condition connector transition guards terminator All Rights Reserved-Dr. Reuven Gallant 59

What comes first? All Rights Reserved-Dr. Reuven Gallant 60

Sequence Diagram before execution: What We Expect All Rights Reserved-Dr. Reuven Gallant 61

Animated Sequence Diagram: Animated What We Expect All Rights Reserved-Dr. Reuven Gallant 62

Useful View Buttons(1( All Rights Reserved-Dr. Reuven Gallant 63

Useful View Buttons(2( All Rights Reserved-Dr. Reuven Gallant 64

What is a reactive object? (3) Please enter OMTracer Command>> timestamp Please enter OMTracer Command>> go idle OMTracer (0: 00. 000) New instance Display[0]: Display created by main() OMTracer (0: 00. 000) main() Invoked Display[0]->Start Behavior OMTracer (0: 00. 000) Display[0] Entered State ROOT OMTracer (0: 00. 000) Display[0] Invoked print(string = started) OMTracer (0: 00. 000) Display[0]->print(string = started) Returned OMTracer (0: 00. 000) Display[0] Entered State ROOT. active OMTracer (0: 00. 000) Display[0] set tm(200) at ROOT. active OMTracer (0: 00. 000) Display[0]->Start Behavior Returned Executable is Idle All Rights Reserved-Dr. Reuven Gallant 65

What is a reactive object? (4) Please enter OMTracer Command>> go idle OMTracer (0: 00. 200) Display[0] Sent to itself Event tm(200) at ROOT. active OMTracer (0: 00. 200) Display[0] Received from itself Event tm(200) at ROOT. active OMTracer (0: 00. 200) main() Invoked Display[0]->Take Event Timeout OMTracer (0: 00. 200) Display[0] Invoked is. Done() OMTracer (0: 00. 200) Display[0]->is. Done() Returned OMTracer (0: 00. 200) Display[0] Exited State ROOT. active OMTracer (0: 00. 200) Display[0] Invoked print(n = 1) OMTracer (0: 00. 200) Display[0]->print(n = 1) Returned OMTracer (0: 00. 200) Display[0] Entered State ROOT. active OMTracer (0: 00. 200) Display[0] set tm(200) at ROOT. active OMTracer (0: 00. 200) Display[0]->Take Event Timeout Returned Executable is Idle All Rights Reserved-Dr. Reuven Gallant 66

What is a reactive object? (5) Please enter OMTracer Command>> go idle OMTracer (0: 00. 400) Display[0] Sent to itself Event tm(200) at ROOT. active OMTracer (0: 00. 400) Display[0] Received from itself Event tm(200) at ROOT. active OMTracer (0: 00. 400) main() Invoked Display[0]->Take Event Timeout OMTracer (0: 00. 400) Display[0] Invoked is. Done() OMTracer (0: 00. 400) Display[0]->is. Done() Returned OMTracer (0: 00. 400) Display[0] Exited State ROOT. active OMTracer (0: 00. 400) Display[0] Invoked print(n = 0) OMTracer (0: 00. 400) Display[0]->print(n = 0) Returned OMTracer (0: 00. 400) Display[0] Invoked print(string = Done) OMTracer (0: 00. 400) Display[0]->print(string = Done) Returned OMTracer (0: 00. 400) Display[0] Reached Termination State OMTracer (0: 00. 400) Display[0]->Take Event Timeout Returned OMTracer (0: 00. 400) main() Invoked Display[0]->~Display() OMTracer (0: 00. 400) Display[0]->~Display() Returned OMTracer (0: 00. 400) Instance Display[0] of class Display deleted by main() Executable is Idle All Rights Reserved-Dr. Reuven Gallant 67

What is a Method? (1( “The design of software is essentially a creative operation, but the designer of a large system usually requires at least guidelines, and preferably a method. . . ” (David Budgen, Introduction to Software Design, SEI Curriculum Module, SEI-CM-2 -2. 1, January 1989, p. 1. ) Method: (Techniques, notation, heuristics, quality factors) All Rights Reserved-Dr. Reuven Gallant 68

What is a Method? (2( Method: (Techniques, notation, heuristics, quality factors) EXAMPLE OF METHOD AND ITS COMPONENTS METHOD: Real-Time Object Oriented Process for Embedded Systems (ROPES) TECHNIQUE: Dependency Inversion Principle (DIP) NOTATION: Unified Modeling Language HEURISTICS: 1. Identify Use Cases and Draw Use Case Diagram 2. Draw Statechart for each Use Case 3. Draw Black Box Scenario Sequence Diagram(s) for each Use Case. 4. Propose initial architecture, draw Object Model Diagram 5. Map Black Box Scenarios to White box and draw sequence diagrams. 6. Perform strategic closure analysis 7. Enhance the design to support strategic closure. 8. … QUALITY FACTORS: Open Closed Principle (OCP), … All Rights Reserved-Dr. Reuven Gallant 69

Where do quality factors come from? • Quality is not a matter of aesthetics – quality is axiology • Quality must be derived from a process goal – axiology is the chambermaid of teleology • The teleos of object oriented technolgy is effective management of unstable requirements All Rights Reserved-Dr. Reuven Gallant 70

Some Basic Questions • How do we represent requirements? • How do we represent design? • How do we move between requirements and design? (process issues( All Rights Reserved-Dr. Reuven Gallant 71

Answers from the Structured World (1( Requirements Model (DFD) A C All Rights Reserved-Dr. Reuven Gallant B 72

Answers from the Structured World (2( Alternative Designs (Structure Chart) B A C C C A BOSS C B A All Rights Reserved-Dr. Reuven Gallant B 73

Answers from the Structured World (2( Alternative Designs (Structure Charts) B A C C C A BOSS C B A All Rights Reserved-Dr. Reuven Gallant B 74

ECSAM Review (1( All Rights Reserved-Dr. Reuven Gallant 75

ECSAM Review (2) Our course Jonah’s course All Rights Reserved-Dr. Reuven Gallant 76

How do we do it in OO? (1): UML Object Model Diagram if Telephone System corresponds to ECSAM System in its Environment Chart All Rights Reserved-Dr. Reuven Gallant 77

How do we do it in OO? (2): UML Use Case Diagram corresponds to ECSAM S-capabilities Chart All Rights Reserved-Dr. Reuven Gallant 78

How do we do it in OO? (3): UML/Rhapsody Statechart of “Make Call” Use Case corresponds to ECSAM S-capability Control Chart All Rights Reserved-Dr. Reuven Gallant 79

How do we do it in OO? (4): UML/Rhapsody Sequence Diagram of ‘sunny day’ Scenario of “Initialize Phone” Use Case corresponds to ECSAM Operational Scenario All Rights Reserved-Dr. Reuven Gallant 80

How do we do it in OO? (5): UML/Rhapsody Sequence Diagram of ‘Failure’ Scenario of “Initialize Phone” Use Case corresponds to ECSAM Operational Scenario All Rights Reserved-Dr. Reuven Gallant 81

How do we do it in OO? (6) Use case: Make Call (from Requirements Document) Scenario: Successful connection 1. User presses the digit buttons to enter the phone number. 2. For each digit, the display is updated to add the digit to the phone number. 3. For each digit, the dialer generates the corresponding tone and emits it from the speaker. 4. User presses “Send” 5. The “in use” indicator is illuminated on the display 6. The cellular radio establishes a connection to the network. 7. The accumulated digits are sent to the network. 8. The connection is made to the called party. All Rights Reserved-Dr. Reuven Gallant 82

Problem Domain Model: Composite All Rights Reserved-Dr. Reuven Gallant 83

Composition in Browser All Rights Reserved-Dr. Reuven Gallant 84

Problem Domain Model: Composite All Rights Reserved-Dr. Reuven Gallant 85

Composite in Browser All Rights Reserved-Dr. Reuven Gallant 86

Dynamic Requirements Model (Collaboration Diagram) All Rights Reserved-Dr. Reuven Gallant 87

Dynamic Requirements Model (Sequence Diagram Version) All Rights Reserved-Dr. Reuven Gallant 88

Reconcilation of Static and Dynamic Model 1 its. Display All Rights Reserved-Dr. Reuven Gallant 89

Reconcilation of Static and Dynamic Model 1 its. Display All Rights Reserved-Dr. Reuven Gallant 90

Initial Object Model (Design(? 1 its. Display All Rights Reserved-Dr. Reuven Gallant 91

Designing for Unstable Requirements Class Design Principles Open-Closed Principle (OCP) Liskov Substitution Principle (LSP) Dependency Inversion Principle (DIP) Interface Segregation Principle (ISP) Package Design Principles Reuse/Release Equivalence Principle (REP) Common Reuse Principle (CRP) Common Closure Principle (CCP) Acyclic Dependencies Principle (ADP) Stable Dependencies Principle (SDP) Stable Abstractions Principle (SAP) Design Metrics All Rights Reserved-Dr. Reuven Gallant 92

Open Closed Principle (OCP) the key to management of unstable requirements “SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC. ) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION. ” --Bertrand Meyer, Object Oriented Software Construction, Prentice Hall, 1988, p 23 1. “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications. 2. “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it. All Rights Reserved-Dr. Reuven Gallant 93

Abstraction is the Key Closed Client Open Client All Rights Reserved-Dr. Reuven Gallant 94

(Object) ADAPTER SERVER pattern for decoupling Button from Dialer All Rights Reserved-Dr. Reuven Gallant 95

Embedded Avionic Software All Rights Reserved-Dr. Reuven Gallant 96

Interface Segregation Principle: Class Adapter Pattern All Rights Reserved-Dr. Reuven Gallant 97

Open Closed Principle (OCP) All Rights Reserved-Dr. Reuven Gallant 98

Open Closed Principle “SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC. ) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION. ” Bertrand Meyer, Object Oriented Software Construction, Prentice Hall, 1988, p 23 לשינוי סגורה אלא , להרחבה פתוח מ נלקח הזאת ליחידה החומר רוב : הערה - Robert C. Martin, “The Open Closed Principle, ” www. objectmentor. com. All Rights Reserved-Dr. Reuven Gallant 99

How so? ● “Open For Extension”. – This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications. ● “Closed for Modification”. – The source code of such a module is inviolate. No one is allowed to make source code changes to it. ● איך אפשר לשנות את ההתנהגות של מודול בלי לשנות את ( קוד המקור source code) ? ? All Rights Reserved-Dr. Reuven Gallant 100

Abstraction is the Key Closed Client Open Client All Rights Reserved-Dr. Reuven Gallant 101

The Shape Abstractionin C Listing 1 Procedural Solution to the Square/Circle Problem enum Shape. Type {circle, square}; struct Shape { Shape. Type its. Type; }; struct Circle { Shape. Type its. Type; double its. Radius; Point its. Center; }; struct Square { Shape. Type its. Type; double its. Side; Point its. Top. Left; }; // These functions are implemented elsewhere // void draw. Square(struct Square*) void draw. Circle(struct Circle*); typedef struct Shape *Shape. Pointer; void draw. All. Shapes(Shape. Pointer list[], int n) { int i; for (i=0; i<n; i++) { struct Shape* s = list[i]; switch (s->its. Type) { case square: draw. Square((struct Square*)s); break; case circle: draw. Circle((struct Circle*)s); break; }} All Rights Reserved-Dr. Reuven Gallant 102

The Shape Abstraction. OOD solution Listing 2 OOD solution to Square/Circle problem. class Shape { public: virtual void draw() const = 0; }; class Square : public Shape { public: virtual void draw() const; }; class Circle : public Shape { public: virtual void draw() const; }; void Draw. All. Shapes(Set<Shape*>& list) { for (Iterator<Shape*>i(list); i; i++) (*i)->draw(); } All Rights Reserved-Dr. Reuven Gallant 103

Run Time Type Identification (RTTI) Listing 9 RTTI violating the open-closed principle. class Shape {}; class Square : public Shape { private: Point its. Top. Left; double its. Side; friend Draw. Square(Square*); }; class Circle : public Shape { private: Point its. Center; double its. Radius; friend draw. Circle(Circle*); }; void draw. All. Shapes(Set<Shape*>& ss) { for (Iterator<Shape*>i(ss); i; i++) { Circle* c = dynamic_cast<Circle*>(*i); Square* s = dynamic_cast<Square*>(*i); if (c) draw. Circle(c); else if (s) draw. Square(s); } Listing 10 RTTI that does not violate the open-closed Principle. class Shape { public: virtual void draw() cont = 0; }; class Square : public Shape { // as expected. }; void draw. Squares. Only(Set<Shape*>& ss) { for (Iterator<Shape*>i(ss); i; i++) { Square* s = dynamic_cast<Square*>(*i); if (s) s->draw(); } All Rights Reserved-Dr. Reuven Gallant 104

Liskov Substitution Principle )LSP( All Rights Reserved-Dr. Reuven Gallant 105

LSP-What is it? “FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. ” The above is a paraphrase of the Liskov Substitution Principle (LSP). Barbara Liskov first wrote it as follows nearly 8 years ago: “What is wanted here is something like the following substitution property: If for each object o 1 of type S there is an object o 2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o 1 is substituted for o 2 then S is a subtype of T. ” [Barbara Liskov, “Data Abstraction and Hierarchy, ” SIGPLAN Notices, 23, 5 (May, 1988). ] All Rights Reserved-Dr. Reuven Gallant 106

A Simple Example of a Violation of LSP via RTTI void draw. Shape(const Shape& s) { if (typeid(s) == typeid(Square)) draw. Square(static_cast<Square&>(s)); else if (typeid(s) == typeid(Circle)) draw. Circle(static_cast<Circle&>(s)); } All Rights Reserved-Dr. Reuven Gallant 107

Square and Rectangle: a More Subtle Violation. class Rectangle { public: void set. Width(double w) {its. Width=w; } void set. Height(double h) {its. Height=h; } double get. Height() const {return its. Height; } double get. Width() const {return its. Width; } private: double its. Width; double its. Height; }; All Rights Reserved-Dr. Reuven Gallant 108

What happens when we call f with an object that is a square? void Square: : set. Width(double w) { Rectangle: : set. Width(w); Rectangle: : Set. Height(w); } void Square: : set. Height(double h) { Rectangle: : set. Height(h); Rectangle: : set. Width(h); } Square s; s. set. Width(1); // Fortunately sets the //height to 1 too. s. set. Height(2); // sets width and //height to 2, good thing. But consider the following function: void f(Rectangle& r) { r. set. Width(32); // calls Rectangle: : Set. Width } All Rights Reserved-Dr. Reuven Gallant 109

Virtual to the rescue! class Rectangle { public: virtual void set. Width(double w) {its. Width=w; } virtual void set. Height(double h) {its. Height=h; } double get. Height() const {return its. Height; } double get. Width() const {return its. Width; } private: double its. Height; double its. Width; }; All Rights Reserved-Dr. Reuven Gallant 110

The Real Problem What does the client expect to happen when g is called with a square? void g(Rectangle& r) { r. set. Width(5); r. set. Height(4); assert(r. Get. Width() * r. Get. Height() == 20); } All Rights Reserved-Dr. Reuven Gallant 111

All Rights Reserved-Dr. Reuven Gallant 112

All Rights Reserved-Dr. Reuven Gallant 113

All Rights Reserved-Dr. Reuven Gallant 114

Fixed! template <class T> void Persistent. Set: : Add(const T& t) { its. Third. Party. Persistent. Set. Add(t); // This will generate a compiler error if t is // not derived from Persistent. Object. } As the listing above shows, any attempt to add an object that is not derived from Persistent. Object to a Persistent. Set will result in a compilation error. (The interface of the third party persistent set expects a Persistent. Object&). All Rights Reserved-Dr. Reuven Gallant 115

Application of Liskov Substitution Principle to Reactive Objects All Rights Reserved-Dr. Reuven Gallant 116

To Maximize State Inheritance Compliance with LSP • New States and transitions may be added freely in the child class · States and transitions defined by the parent cannot be deleted · Actions and activity lists may be changed (added or removed) for each transition and state · Actions and activities may be specialized in the subclass · Substates may not alter their enclosing superstate (including adding a new one) · Transitions may be retargeted to different states · Orthogonal components may be added to inherited states All Rights Reserved-Dr. Reuven Gallant 117

Dependency Inversion Principle )DIP( All Rights Reserved-Dr. Reuven Gallant 118

The Definition of a “Bad Design” • The TNTWI-WHDI Criterion – “Why’d you do it that way? ” “That’s not the way I would have done it” • But there is one set of criteria that I think all engineers will agree with. A piece of software that fulfills its requirements and yet exhibits any or all of the following three traits has a bad design. – It is hard to change because every change affects too many other parts of the system. (Rigidity) – When you make a change, unexpected parts of the system break. (Fragility) – It is hard to reuse in another application because it cannot be disentangled from the current application. (Immobility) All Rights Reserved-Dr. Reuven Gallant 119

Example: the “Copy” program Output. Device Listing 1. The Copy Program copy c c void copy() { int c; while ((c = Read. Keyboard()) != EOF) write. Printer(c); } Listing 2. The “Enhanced” Copy Program read Keyboard write Printer enum Output. Device {printer, disk}; void copy(output. Device dev) { int c; while ((c = read. Keyboard()) != EOF) if (dev == printer) write. Printer(c); else write. Disk(c); } All Rights Reserved-Dr. Reuven Gallant 120

Dependency Inversion The Copy Program: Listing 3: The OO Copy Program class IReader { public: virtual int read() = 0; }; class IWriter { public: virtual void Write(char) = 0; }; void Copier: : copy(IReader& r, I Writer& w) { int c; while((c=r. read()) != EOF) w. write(c); } Listing 4: Copy using stdio. h #include <stdio. h> #include Copy. h void Copier: : copy() { int c; while((c = getchar()) != EOF) putchar(c); } All Rights Reserved-Dr. Reuven Gallant 121

Case Study in Dependency Management copy_lowercase (courtesy of IPL—canata++) All Rights Reserved-Dr. Reuven Gallant 122

Concrete Classes All Rights Reserved-Dr. Reuven Gallant 123

Dependency on Private Variables!! //Hypothetical example of a stub for Keyboard: : Keyboard //Don’t do this in real life! #define STUB_KEYBOARD_PORTNUM 0 x 1002 Keyboard: : Keyboard() : port(STUB_KEYBOARD_PORTNUM) {} // //BAD IDEA! Depends on name and type of private data members All Rights Reserved-Dr. Reuven Gallant 124

Abstract Interface Classes All Rights Reserved-Dr. Reuven Gallant 125

Envelope-Letter Pattern All Rights Reserved-Dr. Reuven Gallant 126

Conditional Compilation All Rights Reserved-Dr. Reuven Gallant 127

The Dependency Inversion Principle: • What does it say? – HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS. – ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS SHOULD DEPEND UPON ABSTRACTIONS. • Does layering solve this: – “. . . all well structured object-oriented architectures have clearlydefined layers, with each layer providing some coherent set of services through a well-defined and controlled interface. ” • [Grady Booch, Object Solutions, Addison Wesley, 1996, p. 54. ] All Rights Reserved-Dr. Reuven Gallant 128

Not necessarily!! All Rights Reserved-Dr. Reuven Gallant 129

A Simple Example //file Button. h----------class Lamp; class Button { public : Button (Lamp& l); void detect(); private: bool get. Physical. State(); protected: Lamp * its. Lamp; }; // file lamp. h class Lamp { public: void turn. On(); void turn. Off(); }; // file Button. cpp------------#include “button. h” #include “lamp. h” void Button: : detect() { bool is. Button. On = get. Physical. State(); if (is. Button. On) its. Lamp->turn. On(); else its. Lamp->turn. Off(); }; All Rights Reserved-Dr. Reuven Gallant 130

// file: IButton. Server. h-----------{ public: virtual void turn. On() = 0; virtual void turn. Off() = 0; }; // file Button. h ----------------class IButton. Server; class Button { public: Button (IButton. Server& a. Button. Server); void detect(); virtual bool get. State() = 0; protected: IButton. Server * its. IButton. Server; }; // file Button. cpp -------------#include Button. h #include IButton. Server. h Button: : Button(IButton. Server& a. Button. Server) : its. IButton. Server (& a. Button. Server) { } void Button: detect() { bool is. Button. On = get. State(); if (is. Button. On) its. IButton. Server->turn. On(); else its. IButton. Server->turn. Off(); } //File Lamp. h-------------------#include “IButton. Server. h” class Lamp : public IButton. Server { public: virtual void turn. On(); virtual void turn. Off(); }; // File Button. Implement. h---------#include “Button. h” class Button. Implement : public Button { public: Button. Implementation (IButton. Server& a. Button. Server) virtual bool get. State(); }; // File Button. Implement. cpp---------Button. Implement: : Button. Implement (IButton. Server& a. Button. Server) : Button ( a. Button. Server) {} All Rights Reserved-Dr. Reuven Gallant 131

Extending the Abstraction Further What if Lamp is 3 rd Party software that doesn’t have turn. On() and turn. Off() operations? Button +detect(): void #get. State(): bool Button. Implement +get. State(): bool IButton. Server 1 its. IButton. Server +turn. On(): void +turn. Off(): void <<Interface>> Lamp. Adapter +turn. On(): void +turn. Off(): void 1 its. Lamp <<Usage>> All Rights Reserved-Dr. Reuven Gallant 132 Lamp +on(): void +off(): void

//File Lamp. Adapter. h----------------#include “IButton. Server” class Lamp; class Lamp. Adapter : public IButton. Server { public: Lamp. Adapter (Lamp & a. Lamp); virtual void turn. On(); virtual void turn. Off(); Lamp * its. Lamp; }; //File Lamp. Adapter. cpp------------#include “Lamp. Adapter. h” #include “Lamp. h” Lamp. Adapter: : Lamp. Adapter (Lamp & a. Lamp) : its. Lamp( & a. Lamp) {} Lamp. Adapter: : turn. On() {its. Lamp->on(); } Lamp. Adapter: : turn. Off() {its. Lamp->off(); } //File Lamp. h-------------------#include “Lamp. Adapter. h” class Lamp { public: Lamp (); virtual void on(); virtual void off(); }; //File Lamp. cpp------------------#include “Lamp. h” Lamp: : Lamp () { new Lamp. Adapter( *this); } All Rights Reserved-Dr. Reuven Gallant 133

Interface Segregation Principle )ISP( All Rights Reserved-Dr. Reuven Gallant 134

Interface Pollution Consider a security system. Door objects can be locked, unlocked, and know whether they are open or closed // file Door. h class Door { public : virtual void lock()=0; virtual void unlock()=0 ; virtual bool is. Open()=0; }; Now consider one such implementation. Timed. Door needs to sound an alarm when the door has been left open for too long. In order to do this, the Timed. Door object communicates with another object called Timer. // file Timer. Client. h class Timer. Client { public: virtual void time. Out ( ) = 0; }; // file Timer. h class Timer. Client; class Timer { public: void register_(int timeout, const Timer. Client & client) }; All Rights Reserved-Dr. Reuven Gallant 135

A Common Solution: Timer Client at top of hierarchy Let’s say we want to provide for cancellation of obsolete timeouts as per the listing below. Do we want to have to modify every derivative of Door? // file Timer. h class Timer. Client; class Timer { public: void register_ (int timeout, int time. Out. Id, Timer. Client & client) ; }; // file Timer. Client. h-------------------------class Timer. Client { public: virtual void time. Out(int time. Out. Id)=0; }; }; All Rights Reserved-Dr. Reuven Gallant 136

The Interface Segregation Principle (ISP) • CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE. All Rights Reserved-Dr. Reuven Gallant 137

Class Adapter Pattern Solution // file Timer. cpp #include “Timer. h” #include “Timer. Client. h” … // file Timer. h class Timer. Client; class Timer { public: void register_(int timeout, int time. Out. Id, const Timer. Client & client) }; // file Timer. Client. h class Timer. Client} public: virtual void time. Out(int timeout, int time. Out. Id; 0=( }; // file Door. h-------------class Door { public : virtual void lock()=0; virtual void unlock()=0 ; virtual bool is. Open()=0; }; // file Timed. Door. h----------#include “Door. h”; #include “Timer. Client. h”; class Timed. Door : public Door, public Timer. Client { public : virtual void lock(); virtual void unlock() ; virtual bool is. Open(); virtual void time. Out(int timeout, int time. Out. Id); }; All Rights Reserved-Dr. Reuven Gallant 138

Object Adapter Pattern Solution: Delegation // file Timed. Door. h-------#include Door. h class Door : public Door { public : virtual void lock()=0; virtual void unlock()=0 ; virtual bool is. Open()=0; virtual void sound. Alarm()=0; }; // file Timed. Door. cpp------#include Timed. Door. h class Door : public Door { public : virtual void lock()=0; virtual void unlock()=0 ; virtual bool is. Open()=0; virtual void sound. Alarm()=0; }; All Rights Reserved-Dr. Reuven Gallant 139

Package Design Principles All Rights Reserved-Dr. Reuven Gallant 140

Review: Class Design Principles 1. The Open Closed Principle. (OPC) a software module that is designed to be reusable, maintainable and robust must be extensible without requiring change. Such modules can be created in C++ by using abstract classes. The algorithms embedded in those classes make use of pure virtual functions and can therefore be extended by deriving concrete classes that implement those pure virtual function in different ways. The net result is a set of functions written in abstract classes that can be reused in differ-ent detailed contexts and are not affected by changes to those contexts. 2. The Liskov Substitution Principle. (LSP) Sometimes known as “Design by Contract”. This principle describes a system of constraints for the use of public inheritance in C++. The principle says that any function which uses a base class must not be confused when a derived class is substituted for the base class. This article showed how difficult this principle is to conform to, and described some of the subtle traps that the software designer can get into that affect reusability and maintainability. 3. The Dependency Inversion Principle. (DIP) This principle describes the overall structure of a well designed objectoriented application. The principle states that the modules that implement high level policy should not depend upon the modules that implement low level details. Rather both high level policy and low level details should depend upon abstractions. When this principle is adhered to, both the high level policy modules, and the low level detail modules will be reusable and maintainable. 4. The Interface Segregation Principle. (ISP) This principle deals with the disadvantages of “fat” interfaces. Classes that have “fat” interfaces are classes whose interfaces are not cohesive. In other words, the interfaces of the class can be broken up into groups of member functions. Each group serves a different set of clients. Thus some clients use one group of member functions, and other clients use the other groups. The ISP acknowledges that there are objects that require non-cohesive interfaces; however it suggests that clients should not know about them as a single class. Instead, clients should know about abstract base classes that have cohesive inter-faces; and which are multiply inherited into the concrete class that describes the non-cohesive object. All Rights Reserved-Dr. Reuven Gallant 141

What is a Package? “A general purpose mechanism for organizing elements into groups. Packages may be nested within other packages. A system may be thought of as a single highlevel package, with everything else in the system contained in it. ” All Rights Reserved-Dr. Reuven Gallant 142

Package Dependencies All Rights Reserved-Dr. Reuven Gallant 143

Designing with Packages. • Packages allow us to reason about classes at a higher level of abstraction. But how should we partition classes to allocate them to packages? • What are the best partitioning criteria? • What are the relationships that exist between packages, and what design principles govern their use? • Should packages be designed before classes (Top down)? Or should classes be designed before packages (Bottom up)? • How are packages physically represented? In C++? In the development environment? • Once created, to what purpose will we put these packages? All Rights Reserved-Dr. Reuven Gallant 144

Package Design Principles The Reuse/Release Equivalence Principle (REP). THE GRANULE OF REUSE IS THE GRANULE OF RELEASE. ONLY COMPONENTS THAT ARE RELEASED THROUGH A TRACKING SYSTEM CAN BE EFFECTIVELY REUSED. THIS GRANULE IS THE PACKAGE. The Common Reuse Principle (CRP) THE CLASSES IN A PACKAGE ARE REUSED TOGETHER. IF YOU REUSE ONE OF THE CLASSES IN A PACKAGE, YOU REUSE THEM ALL. The Common Closure Principle (CCP) THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINST THE SAME KINDS OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE CLASSES IN THAT PACKAGE. The Acyclic Dependencies Principle (ADP) THE DEPENDENCY STRUCTURE BETWEEN PACKAGES MUST BE A DIRECTED ACYCLIC GRAPH (DAG). THAT IS, THERE MUST BE NO CYCLES IN THE DEPENDENCY STRUCTURE. All Rights Reserved-Dr. Reuven Gallant 145

Methods for Breaking Cycles Dependency All Rights Reserved-Dr. Reuven Gallant 146

Package Design with Acyclic Dependencies All Rights Reserved-Dr. Reuven Gallant 147

Package Design with Cyclic Dependencies All Rights Reserved-Dr. Reuven Gallant 148

Weather Monitoring Station: Case Study This is a preliminary chapter of Object Oriented Analysis and Design with Applications, 2 d. ed. , Grady Booch, Robert C, Martin, James Newkirk. Copyright © 1998, by Addison Wesley Longman, Inc. No portion of this document may be reproduced without the written permission of Addison Wesley Longman, Inc. All Rights Reserved-Dr. Reuven Gallant 149

Requirements (1( Nimbus-LC Requirements Usage Requirements This system shall provide automatic monitoring of various weather conditions. Specifically, it must measure: • Wind speed and direction • Temperature • Barometric pressure • Relative Humidity • Wind chill • Dew point temperature The system shall also provide an indication of the current trend in the barometric pressure reading. The three possible values include stable, rising, and falling. For example, the current barometric pressure is 29. 95 inches of mercury (IOM) and falling. The system shall have a display which continuously indicates all measurements, as well as the current time and date. All Rights Reserved-Dr. Reuven Gallant 150

Requirements (2( 24 -Hour History Through the use of a touch screen the user may direct the system to display the 24 hour history of any of the following measurements: • Temperature • Barometric Pressure • Relative Humidity This history shall be presented to the user in the form a line chart (see Figure 3 -24) User Setup The system shall provide the following facilities to the user to allow the station to be configured during installation. • Setting the current time, date, and time zone. • Setting the units that will be displayed (english or metric) All Rights Reserved-Dr. Reuven Gallant 151

Requirements (3( All Rights Reserved-Dr. Reuven Gallant 152

Initial Sensor Model All Rights Reserved-Dr. Reuven Gallant 153

Making Periodic Measurments All Rights Reserved-Dr. Reuven Gallant 154

Making Periodic Measurments(2( All Rights Reserved-Dr. Reuven Gallant 155

Barometric Pressure Trend Where do we put it? Algorithm: If the pressure is rising or falling at a rate of at least 0. 06 inch per hour and the pressure change totals 0. 02 inch or more at the time of the observation [to be taken once every three hours], a pressure change remark shall be reported. - Federal Meteorological Handbook No. 1, Chapter 11, Section 11. 4. 6 (http: //www. nws. noaa. gov) All Rights Reserved-Dr. Reuven Gallant 156

Decoupling the User Interface and the Scheduler: Observer Pattern All Rights Reserved-Dr. Reuven Gallant 157

All Rights Reserved-Dr. Reuven Gallant 158

All Rights Reserved-Dr. Reuven Gallant 159

Observer also solves our Barometric Pressure Trend Problem! All Rights Reserved-Dr. Reuven Gallant 160

Okay, now let’s decouple scheduler from the sensors All Rights Reserved-Dr. Reuven Gallant 161

How do we structure the Sensors? use Template Method All Rights Reserved-Dr. Reuven Gallant 162

How do we separate hardware API from the system application? use Bridge pattern All Rights Reserved-Dr. Reuven Gallant 163

Creational Issues--hardware dependencies main does it public class Weather. Station { public static void main(String[] args) { Alarm. Clock ac = new Alarm. Clock(new Nimbus 1_0 Alarm. Clock); Temperature. Sensor ts =new Temperature. Sensor(ac, new Nimbus 1_0 Temperature. Sensor); Barometric. Pressure. Sensor bps = new Barometric. Pressure. Sensor(ac, new Nimbus 1_0 Barometric. Pressure. Sensor); Barometric. Pressure. Trend bpt = new Barometric. Pressure. Trend(bps) } } All Rights Reserved-Dr. Reuven Gallant 164

Abstract Factory does it better! All Rights Reserved-Dr. Reuven Gallant 165

Only Alarm. Clock (and the Tool. Kit) are hardware dependent All Rights Reserved-Dr. Reuven Gallant 166

But Sensor construction is only dependent on the Toolkit (no hardware dependence!) All Rights Reserved-Dr. Reuven Gallant 167

Getting the Tool. Kit to create the Alarm. Clock ala Bridge pattern All Rights Reserved-Dr. Reuven Gallant 168

Getting the Tool. Kit to create the Alarm. Clock ala Bridge pattern -the construction process All Rights Reserved-Dr. Reuven Gallant 169

Look ma, only one hand! All Rights Reserved-Dr. Reuven Gallant 170

Look ma, no hands! All Rights Reserved-Dr. Reuven Gallant 171

What’s wrong with this package structure? All Rights Reserved-Dr. Reuven Gallant 172

Doctor’s instructions • Pull main out of the Weather Station Class Package All Rights Reserved-Dr. Reuven Gallant 173