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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-18 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-23 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-24 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!!!!

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-25 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-26 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 –eXtreme Programming Teamwork –Pair Programming Software Requirements Analysis in the Small –Use Cases Building in Software Quality –Refactoring

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-27 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)

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-28 דרישות הקורס השתתפות בניסוי-חובה נוכחות תרגלי מעבדה מפלוס 10+ עד (מינוס!!!) 20- % בוחן 20% מגן (יש רק מועד אחד!) מבחן סופי 70% או 90% (תלוי בבוחן)

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-29 דרישות (1): השתתפות בניסוי-חובה הניסוי מיועד לבודק תלות בין רמת הבנת statechart לבין מורכבות של statechart לצורך הקורס והניסוי נתמקד ב- statecharts בהתחלת הקורס בהרצאות בהרצאות הנ"ל נרשום נוכחות כל תלמיד/ה י/תכתוב תשובות לשאלון. נכונות של התשובות לא ישפיע על ציון של התלמיד/ה.

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-30 דרישות (2): נוכחות נוכחות אינה חובה---אבל – מאחר וגישת הקורס הוא שונה ומשונה ומאחר הצלחה בקורס מחייבת הבנה לעומק, יהיה קשה לרכוש את הידע “ יד שניה ”. מי שלא משתתף ברציניות בשיעורים ובמעבדות עלול / ה ליכשל. רישום נוכחות בהרצאות statechart – רק לצורך המחקר, לא ישפיע על הציון – בכל זאת, כל מי שנוכח בהרצאות הנ " ל תבוא עליו ברכה

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-31 דרישות ( 3 ) תרגילי מעבדה ביצוע של התרגילים היא בזוגות ( ולא יותר ) כל תלמיד נבדק " בעל פה " בנפרד ( לא בזוגות ) על כל תרגיל יהיו כ 10 תרגילים. ( בהמשך ההסבר נתייחס למספר התרגילים כמשתנה בשם N) – מי שנבחן על כל התרגילים בעוד מועד מקבל עד 10 נקודות – תרגיל שמוגש באיחור נחשב תרגיל שלא מוגש – מי שלא נבחן על אף תרגיל בעוד מועד מקבל 20 - נקודות – נוסחת נקודות מקסימום לתרגילים היא : (M*10/N)-(N-M)*20/N

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-32 דרישות ( 3 א ): תרגילי מעבדה מדיניות התרגילים נראית אכזרית, אבל זאת אכזריות של רחמנים. מדיניות התרגילים מיועדת לעודד השקעה שוטפת במקום מאמצים יומיים לפני המבחן. בלי מאמצים שוטפים אי אפשר לקבל מה שצריך לקבל מהקורס. כל מחזור יש תלמידים שלא שמים לב למדיניות התרגילים, ולכן הציון המקסימלי שלהם בקורס יהיה 70 ( כמובן רק אם מקבלים 100 במבחן סופי ) במבחן סופי יש הדגש על הבנת התרגילים !!

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-33 דרישות ( 4 ): בוחן הבוחן הוא מגן במשקל של 20%. לכן הוא לא חובה. יהיה רק מועד אחד לבוחן. לצערי, אין לי זמן לטפל מועדים נוספים על אף שזה עלול לפגוע במקרים של העדרות מוצדקת.

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-34 דרישות(5): מבחן סופי הדגש על הבנה מעמיקה לכן מי שכותב פתרון שנראה בסדר, אבל בנקודות קריטיות מפגין שהוא לא הבין, יקבל ציון לפי האיכות ולא לפי הכמות. לא יהיה פקטור!!!!!!!! לא תהיה הארכת זמן במבחן!!!!!! לכן רק מאמץ שוטף במשך הקורס יוביל לציון גבוה!!!!!

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-36 שינויים במדיניות ותוכן הקורס אחראיות של כל תלמיד להתעדכן לגבי שינויים במדיניות של הקורס, בתוכן של הקורס וכו', בין אם המדע נמסר בעל פה (ע"י המרצה או מתרגילי מעבדה) בין אם המדע נמסר בכתב או ברשת.

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

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

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

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

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

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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-68 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)

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-69 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), …

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-70 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-71 Some Basic Questions How do we represent requirements? How do we represent design? How do we move between requirements and design? (process issues)

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-80 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-81 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-82 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.

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-92 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-93 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.

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-99 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.

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-100 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) ????

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-102 T he Shape Abstractionin C Listing 1 Procedural Solution to the Square/Circle Problem enum ShapeType {circle, square}; struct Shape { ShapeType itsType; }; struct Circle { ShapeType itsType; double itsRadius; Point itsCenter; }; struct Square { ShapeType itsType; double itsSide; Point itsTopLeft; }; // These functions are implemented elsewhere // void drawSquare(struct Square*) void drawCircle(struct Circle*); typedef struct Shape *ShapePointer; void drawAllShapes(ShapePointer list[], int n) { int i; for (i=0; i<n; i++) { struct Shape* s = list[i]; switch (s->itsType) { case square: drawSquare((struct Square*)s); break; case circle: drawCircle((struct Circle*)s); break; }}

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-103 The Shape AbstractionOOD 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 DrawAllShapes(Set & list) { for (Iterator i(list); i; i++) (*i)->draw(); }

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-104 Run Time Type Identification (RTTI) Listing 9 RTTI violating the open-closed principle. class Shape {}; class Square : public Shape { private: Point itsTopLeft; double itsSide; friend DrawSquare(Square*); }; class Circle : public Shape { private: Point itsCenter; double itsRadius; friend drawCircle(Circle*); }; void drawAllShapes(Set & ss) { for (Iterator i(ss); i; i++) { Circle* c = dynamic_cast (*i); Square* s = dynamic_cast (*i); if (c) drawCircle(c); else if (s) drawSquare(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 drawSquaresOnly(Set & ss) { for (Iterator i(ss); i; i++) { Square* s = dynamic_cast (*i); if (s) s->draw(); }

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-106 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 o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.” [Barbara Liskov, “Data Abstraction and Hierarchy,” SIGPLAN Notices, 23,5 (May, 1988).]

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-107 A Simple Example of a Violation of LSP via RTTI void drawShape(const Shape& s) { if (typeid(s) == typeid(Square)) drawSquare(static_cast (s)); else if (typeid(s) == typeid(Circle)) drawCircle(static_cast (s)); }

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-108 Square and Rectangle: a More Subtle Violation. class Rectangle { public: void setWidth(double w) {itsWidth=w;} void setHeight(double h) {itsHeight=h;} double getHeight() const {return itsHeight;} double getWidth() const {return itsWidth;} private: double itsWidth; double itsHeight; };

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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-110 Virtual to the rescue! class Rectangle { public: virtual void setWidth(double w) {itsWidth=w;} virtual void setHeight(double h) {itsHeight=h;} double getHeight() const {return itsHeight;} double getWidth() const {return itsWidth;} private: double itsHeight; double itsWidth; };

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-111 The Real Problem What does the client expect to happen when g is called with a square? void g(Rectangle& r) { r.setWidth(5); r.setHeight(4); assert(r.GetWidth() * r.GetHeight() == 20); }

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-115 Fixed! template void PersistentSet::Add(const T& t) { itsThirdPartyPersistentSet.Add(t); // This will generate a compiler error if t is // not derived from PersistentObject. } As the listing above shows, any attempt to add an object that is not derived from PersistentObject to a PersistentSet will result in a compilation error. (The interface of the third party persistent set expects a PersistentObject&).

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-117 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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-119 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)

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-120 OutputDevice c Example: the “ Copy ” program Listing 1. The Copy Program void copy() { int c; while ((c = ReadKeyboard()) != EOF) writePrinter(c); } Listing 2. The “ Enhanced ” Copy Program enum OutputDevice {printer, disk}; void copy(outputDevice dev) { int c; while ((c = readKeyboard()) != EOF) if (dev == printer) writePrinter(c); else writeDisk(c); } copy read Keyboard write Printer c

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-121 Dependency Inversion 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 #include Copy.h void Copier::copy() { int c; while((c = getchar()) != EOF) putchar(c); } The Copy Program:

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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-128 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. DETAILS SHOULD DEPEND UPON ABSTRACTIONS. Does layering solve this: –“...all well structured object-oriented architectures have clearly-defined 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.]

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-130 A Simple Example // file Button.cpp------------------------- #include “button.h” #include “lamp.h” void Button:: detect() { bool isButtonOn = getPhysicalState(); if (isButtonOn) itsLamp->turnOn(); else itsLamp->turnOff(); }; //file Button.h--------------------- class Lamp; class Button { public : Button (Lamp& l); void detect(); private: bool getPhysicalState(); protected: Lamp * itsLamp; }; // file lamp.h class Lamp { public: void turnOn(); void turnOff(); };

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-131 //File Lamp.h--------------------------------------- #include “IButtonServer.h” class Lamp : public IButtonServer { public: virtual void turnOn(); virtual void turnOff(); }; // File ButtonImplement.h------------------ #include “Button.h” class ButtonImplement : public Button { public: ButtonImplementation (IButtonServer& aButtonServer) virtual bool getState(); }; // File ButtonImplement.cpp------------------ ButtonImplement::ButtonImplement (IButtonServer& aButtonServer) : Button ( aButtonServer) {} // file: IButtonServer.h---------------------- { public: virtual void turnOn() = 0; virtual void turnOff() = 0; }; // file Button.h --------------------------------- class IButtonServer; class Button { public: Button (IButtonServer& aButtonServer); void detect(); virtual bool getState() = 0; protected: IButtonServer * itsIButtonServer; }; // file Button.cpp --------------------------- #include Button.h #include IButtonServer.h Button::Button(IButtonServer& aButtonServer) : itsIButtonServer (& aButtonServer) { } void Button:detect() { bool isButtonOn = getState(); if (isButtonOn) itsIButtonServer->turnOn(); else itsIButtonServer->turnOff(); }

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-132 Extending the Abstraction Further What if Lamp is 3 rd Party software that doesn’t have turnOn() and turnOff() operations? +turnOn():void +turnOff():void IButtonServer > +turnOn():void +turnOff():void LampAdapter +on():void +off():void Lamp +detect():void #getState():bool Button +getState():bool ButtonImplement itsLamp 1 itsIButtonServer 1 >

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-133 //File LampAdapter.h-------------------------------- #include “IButtonServer” class Lamp; class LampAdapter : public IButtonServer { public: LampAdapter (Lamp & aLamp); virtual void turnOn(); virtual void turnOff(); Lamp * itsLamp; }; //File LampAdapter.cpp------------------------- #include “LampAdapter.h” #include “Lamp.h” LampAdapter::LampAdapter (Lamp & aLamp) : itsLamp( & aLamp) {} LampAdapter::turnOn() {itsLamp->on();} LampAdapter::turnOff() {itsLamp->off();} //File Lamp.h--------------------------------------- #include “LampAdapter.h” class Lamp { public: Lamp (); virtual void on(); virtual void off(); }; //File Lamp.cpp------------------------------------ #include “Lamp.h” Lamp::Lamp () { new LampAdapter( *this);}

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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-136 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 TimerClient; class Timer { public: void register_ (int timeout, int timeOutId, TimerClient & client) ; }; // file TimerClient.h-------------------------------------------------- class TimerClient { public: virtual void timeOut(int timeOutId)=0;}; };

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-138 Class Adapter Pattern Solution // file TimerClient.h class TimerClient { public : virtual void timeOut(int timeout, int timeOutId)=0; }; // file Door.h--------------------------- class Door { public : virtual void lock()=0; virtual void unlock()=0; virtual bool isOpen()=0; }; // file Timer.h class TimerClient; class Timer { public: void register_(int timeout, int timeOutId, const TimerClient & client) }; // file TimedDoor.h--------------------- #include “Door.h”; #include “TimerClient.h”; class TimedDoor : public Door, public TimerClient { public : virtual void lock(); virtual void unlock(); virtual bool isOpen(); virtual void timeOut(int timeout, int timeOutId); }; // file Timer.cpp #include “Timer.h” #include “TimerClient.h” …

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-139 Object Adapter Pattern Solution: Delegation // file TimedDoor.h-------------- #include Door.h class Door : public Door { public : virtual void lock()=0; virtual void unlock()=0; virtual bool isOpen()=0; virtual void soundAlarm()=0; }; // file TimedDoor.cpp------------- #include TimedDoor.h class Door : public Door { public : virtual void lock()=0; virtual void unlock()=0; virtual bool isOpen()=0; virtual void soundAlarm()=0; };

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-141 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 object- oriented 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.

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-142 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 high- level package, with everything else in the system contained in it.”

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-144 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?

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-145 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.

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

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-150 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.

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-151 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)

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-156 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)

5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-164 Creational Issues--hardware dependencies main does it public class WeatherStation { public static void main(String[] args) { AlarmClock ac = new AlarmClock(new Nimbus1_0AlarmClock); TemperatureSensor ts =new TemperatureSensor(ac, new Nimbus1_0TemperatureSensor); BarometricPressureSensor bps = new BarometricPressureSensor(ac, new Nimbus1_0BarometricPressureSensor); BarometricPressureTrend bpt = new BarometricPressureTrend(bps) }

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

Similar presentations

Presentation on theme: "5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-1 תיכון מערכות תוכנה להנדסה ופיתוח פרויקט אישי Dr. Reuven Gallant Jerusalem College of Technology."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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

Similar presentations

Presentation on theme: "5/12/2015 All Rights Reserved-Dr. Reuven Gallant Slide I-1 תיכון מערכות תוכנה להנדסה ופיתוח פרויקט אישי Dr. Reuven Gallant Jerusalem College of Technology."— Presentation transcript:

Similar presentations

About project

Feedback