Museum Automation Subsystem: Design Scenario and CRC Cards

1. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 SE 430: Lecture 7

2. Administrivia • Comments and feedback • Team Project Preliminary Description • Will send email to each team. SE 430: Lecture 7

3. Exam Results SE 430: Lecture 7

4. Assignment 5 • (Due October 27, 2016) Museum Automation Subsystem: Design Scenario and CRC Cards • Create some design artifacts for the Visitor Information Subsystem Visitor Audit Tracking feature.  • Design the Visitor Audit Tracking feature.  • Develop a design scenario (slides 89-100) for this functionality. • Create CRC cards for this design scenario. SE 430: Lecture 7

5. Assignment 5 • Visitor Information Subsystem Visitor Audit Trackingfeature. • This is an add-on feature. It should not require changes to other parts of the system, or know about them except for global information. • It assumes an existing design and the existence of the Feature class and the SubFeature class. • The VGAT sub-system interfaces with the above classes only. • Design both parts of the feature (VGAT and CAM) • Use the patterns discussed today to implement • Do the design scenario procedure at least twice for assignment 5. • This assignment is NOT related to the Mixed Information Display and thus does not incorporate any of those features! SE 430: Lecture 7

6. SE 430 – Class 7 Topics: Start of Design • Packages • Frameworks • Patterns • Patterns Overview • A System of Patterns • Coupling and Cohesion • Design Patterns • Architectural • Responsibility Driven Design • GRASP Patterns • Design Scenarios – used for assignments 5-6! Reading: • Arlow & Neustadt, Ch. 19, 20 • Reading list SE 430: Lecture 7

7. Thought for the Day "This book's been out for six months." (Pause) "That's ancient, isn't it?" SE 430: Lecture 7

8. Last Time • The Nature of an Object • Contracts and Dependencies • Relationships Among Objects • System Behavior Modeling: • Interaction Diagrams • State Charts SE 430: Lecture 7

9. Packages SE 430: Lecture 7

10. Packages Package • shown as a tabbed folder containing a group of modeling components representing a logical subset of a system • model elements can be of any kind • (Classes, use cases, collaborations, and other packages) • The model elements are logically grouped together because they • provide related services (high coupling and collaboration) • have strongly related responsibilities • have low coupling and collaboration with elements of other packages SE 430: Lecture 7

11. Packages Visibility between Packages • Visibility to a component in a package represents coupling to the package • There should be no coupling from Domain or Storage to Presentation • Presentation components can have high visibility to many components in Domain packages • Domain packages have visibility to one component of a Service Package. Package Dependency • A package has coupling with components of another package • Coupling implies visibility between packages SE 430: Lecture 7

12. Patterns and Frameworks SE 430: Lecture 7

13. Frameworks • One type of variable multiuse component is a framework: • most frameworks have a reusable program skeleton • you customize the skeleton by adding in new code that the framework will call to do the application-specific parts of the job • the “new code” may be inserted in several ways: callbacks, application generators, and subclasses are three popular schemes framework (reused code) new code (extensions to the framework) SE 430: Lecture 7

14. Frameworks and OO /* file Myapp.h */ class CMyappApp : public CWinApp { .... }; /* file MyappDoc.h */ class CMyappDoc : public CDocument { .... }; /* file MyappView.h */ class CMyappView : public CView { .... }; /* file MyAuxDlg.h */ class MyAuxDlg : public CDialog { .... }; • “Object oriented” frameworks are collections of collaborating abstract classes that can be extended by building subclasses to be used in new situations • Example: Microsoft Foundation Classes • Contains several important superclasses: CWinApp, CDocument, CView • Application programmers will create subclasses that redefine operations in the MFC base classes: SE 430: Lecture 7

15. Patterns Patterns: a technique for reusing designs as well as code SE 430: Lecture 7

16. Patterns Overview Patterns and Pattern Languages are ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience. SE 430: Lecture 7

17. Patterns • Patterns • Repertoire of general principles and solutions • The patterns have worked in the past and they should be applicable to new situations • Patterns Community • Based on the books • Christopher Alexander – Timeless Way of Building • Gang of Four: Gamma, E., et. al., Design Patterns, Addison-Wesley, ISBN: 0-201-633621-2 • Hillside group – community of researchers formed to advance the concepts of patterns in software technology. SE 430: Lecture 7

18. Patterns: a reuse technique • A pattern is “a solution to a problem in a context” • The idea originally comes from the architect Christopher Alexander (see note) • It is one way to formalize some of the “tricks” and “idioms” that are becoming “standard engineering practice” • Since 1994, there have been books, articles, conferences, and training courses on “documenting the patterns of software development” • Design patterns: standard groupings of classes that solve many problems • example: the “Observer” pattern • Organizational patterns: one way of recording successful models of organizational structure and communication techniques within a software development organization SE 430: Lecture 7

19. What are software patterns? • A pattern is a named, paired problem and solution. • Patterns can be applied in various design contexts. • Patterns capture solutions that have developed and evolved over time. • Patterns can be applied at different levels of abstraction: • Architectural, which provide solutions at the system level. • Design, which provide solutions at the object collaboration or module level. • Idiomatic, which provide solutions at the line-of-code level. • A good collection of notes about the whole subject: Patterns and Software: Essential Concepts and Terminology, Brad Templeton,http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html SE 430: Lecture 7

20. What is in a pattern? • A pattern needs to describe the problem and the context precisely • the pattern “readers” must be able to determine if it can help solve their problem • the pattern “writers” often use object oriented analysis/design notation (such as UML Class diagrams) to describe the problem, the context, and the solution • But the problem and context have to be general enough • There are several different formats for patterns • Class diagrams with generalized examples are used throughout the Design Patterns book • Patterns have become a “shorthand” for designers to talk about possible solutions SE 430: Lecture 7

21. Patterns are reusable designs • When you use a pattern, you are applying abstraction: • you are “matching” your problem with a “generalized problem statement” in a pattern (or a group of patterns) • you are weighing the tradeoffs: some patterns give a list of potential problems in a section labeled “consequences” • if the pattern works, you benefit from design reuse • There are “groups of patterns” that work together • a group of patterns that work together is called a pattern language • Good designs and architectures are full of patterns • take the time to look for the patterns you are using • document your patterns so others can use them • you might even bring in a “pattern miner” to look for patterns in your existing designs SE 430: Lecture 7

22. Example: Leaky Bucket Problem: How do you deal with transient faults? Context: Fault-tolerant system software that must deal with failure events. Failures are tied to episode counts and frequencies. Consider a data communications path: it has errors, are they bad enough to warrant placing the line out of service? A story describing the idea. See notes section for official description or Leaky Bucket Counter SE 430: Lecture 7

23. Pattern components • Four essential components comprise a pattern (from Gamma et al.): • Pattern name. A simple one- or two-word identifier to allow ready incorporation into our working design vocabulary. • Problem or application. The problem and the context in which the pattern may be applied. • Solution. A general description of the elements that make up the pattern, including entities, relationships, assignment of responsibilities, and collaborations. • Consequences. The results and consequences of applying the pattern. • The standard documentation style first presented by Gamma (in the Design Patterns book) always contains a section titled “Applicability” that spells out the situations in which the pattern can be applied. SE 430: Lecture 7

24. Patterns Short Form Pattern name: Problem solved: Applicability: Solution: Standard Form Pattern name: Problem solved: Design forces: Applicability: Solution: Consequences: SE 430: Lecture 7

25. Patterns – Extended Form • Pattern name: • Intent: • Also Known As: • Motivation: • Applicability: • Structure: • Participants: • Collaborations: • Consequences: • Implementation: • Known Uses: • Related Patterns: SE 430: Lecture 7

26. A System of Patterns SE 430: Lecture 7

27. Review: What is an architectural pattern? • Represents a structural organization plan for a software system • Can be applied in various design contexts • Consists of: • A set of predefined subsystems or components • Definitions of subsystem or component responsibilities • Rules and guidelines for structuring relationships or collaborations among the subsystems or components • Also known as architectural style or system design pattern SE 430: Lecture 7

28. Layers pattern example: TCP/IP Application layer Transport layer Internet layer Network interface layer Source application Destination application Generates data to transmit Gets data to other process Gets data to other host Gets data onto network SE 430: Lecture 7

29. Model-View-Controller Static structure • Integral use of Observer pattern • Controller observes View • Controller acquires updates of View • Controller modifies Model • View observes Model • View acquires updates of Model • Note: • Viewdoes not modifyModel • Use of two interface notations is redundant. For illustration purposes only SE 430: Lecture 7

30. Design patterns • A design patterndescribes a recurring structure of collaborating software system components, usually at the object level • Gamma et al. categorized design patterns into three species: • Creational patterns, such as Creator and Singleton • Structural patterns, such as Controller and Façade • Behavioral patterns, such as Information Expert and Observer • Also known as application design patterns SE 430: Lecture 7

31. Observer design pattern Pattern Name: Observer– Behavioral Problem: One object contains some state information, but several other objects need to be notified each time that state information is changed. Design Forces: You don't want to put everything in one class, for one of these reasons: • in the next design iteration the main class won't change, but some of the other classes might change • the list of objects that need to be notified is changing at runtime Applicability Use the Observer pattern when: • There is at least one message sender in the system. • There are one or more message receivers and the population of receivers may vary at run time. • The message sender is not concerned with what the receivers do with the information sent. SE 430: Lecture 7

32. Observer design pattern Description The Observer pattern provides a means for generating events for a population of message receivers (observers). The message producers (Subject or observed components) send messages to notify the observers of these events. The observers are responsible for registering with the Subject component, while the Subject component is responsible for notifying the observers when an event of interest occurs. Solution: The “observed” object keeps a list of the objects that want to be notified. SE 430: Lecture 7

33. Observer design pattern Implementation • Subject. Interface that defines interaction of observed and observers. May define several methods for notification of observers. • ConcreteSubject. Implements the methods of the Subject interface and maintains a collection of observers. Notification methods use iterators. • Observer. Interface that defines the method used to receive notification from the Subject . • ConcreteObserver. Implements Observer interface and determines how to respond to notification from Subject. SE 430: Lecture 7

34. Observer design pattern Static structure 0..* notifyObservers: for all observers o o.handleEvent() «interface» Subject «interface» Observer ConcreteObserver ConcreteSubject +void addObserver(Observer o) +void removeObserver(Observer o) +void notifyObservers() +void handleEvent() +void handleEvent() -Observer[] observers +void addObserver(Observer o) +void removeObserver(Observer o) +void notifyObservers() SE 430: Lecture 7

35. Observer design pattern o :Subject o 1 : O b s e r v e r o 2 : O b s e r v e r O b s e r v e r o 1 e v e n t i l l u s t r a t e s t h e n o t i f y O b s e r v e r s ( ) u s e o f g e n e r i c m e s s a g i n g . h a n d l e E v e n t ( ) h a n d l e E v e n t ( d a t a ) g e t D a t a ( ) O b s e r v e r o 2 i l l u s t r a t e s t h e d a t a u s e o f s p e c i f i c m e s s a g i n g . Dynamic behavior SE 430: Lecture 7

36. Observer design pattern Benefits and Drawbacks • Very flexible. Components can be added and removed at any time. • Relatively lightweight. • Generic messaging – simply notifying observer that something has changed – can lead to high message traffic volume and observer processing overhead. • Specific messaging – observed provides more information in notification – can lead to higher complexity in both observed and observer components. • Subject must maintain a list of observers. Related Pattern • Publish/Subscribe SE 430: Lecture 7

37. The Observer pattern: example garageCounter : Car counter car_count = 100 olist : List of Observer objects Objects to notify when car_count changes: gcontrol : GateControl entrance2Meter : Meter entrance1Meter : Meter value : int SE 430: Lecture 7

38. Class diagram for example observers Subject Attach(Observer) Detach(Observer) Notify() Observer Update() 1 0..* for all o in observers { o->Update() } ConcreteObserver observerState Update() ConcreteSubject subjectState GetState() observerState = subject->GetState(); return subjectState • Some patterns are described using class diagram notation • In this example, the Subject and Observer classes are abstract classes • Each ConcreteObserver object (like Meter) needs to register by calling the Attach() operation on a ConcreteSubject object (like Car counter) SE 430: Lecture 7

39. Idiomatic patterns • Idiomatic patternsare low-level patterns specific to a particular programming language or class of languages • Rely upon features specific to the language • Provide guidance in implementing particular components or the relationships among components • Examples: • Use of loop-to-copy characters (in older procedural languages) while (*cp++ = *sp++){}; vs. strcpy(src,dest) in C/C++ SE 430: Lecture 7

40. Coupling and Cohesion SE 430: Lecture 7

41. Coupling • Usually not considered a pattern, per se, but rather a design principle or qualitative metric • Definition: A measure of the strength of the inter-connections between system components SE 430: Lecture 7

42. Coupling Some usable metrics: • Number of collaborators • A class which has a large number of collaborators (>3) is usually considered to possess higher strength coupling than one with one or two collaborators • If high number of collaborators needed, use a suitable design pattern such as Information Expert or Façade • Strength of associations • Use of operation (a service) is considered low strength coupling • Use of an instance variable (a state element) is considered higher strength coupling • Example: An operation on a TrafficSignal flowIndicator() which yields ‘go’ or ‘stop’ leads to less coupling than use of the ‘color’ instance variable Other factors influence the strength of coupling, as well SE 430: Lecture 7

43. Coupling Tight coupling • Tight coupling occurs when one entity depends implicitly on another • Example: Object instances are tightly coupled to their classes because they share both public and protected information. A change in the class definition affects every instance of the class. Contrast this with specialization and implementation of interfaces. • Shared variables or control information exchange lead to tight coupling SE 430: Lecture 7

44. Coupling Loose Coupling • Loose coupling means component changes are unlikely to affect other components • Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing • Loose coupling occurs when one entity references another indirectly through a public interface • Example: Client/server relationship using HTTP • Loose coupling is exemplified by layers architectural pattern. • Looser coupling usually increases reusability and decreases maintenance costs SE 430: Lecture 7

45. Class relationships and coupling • Association (unnamed) • Very weak coupling (which is good), but coveys little information (so not very useful) • Composition/aggregation (To be discussed in later lecture) • Ordinary aggregation: very good (containment relationship) • Composition: good (ownership relationship) • Using (indicated by named association ‘uses’ or ‘used-by’) • Client/server model • Provides very loose coupling • Good-to-excellent reusability • Epitomizes concept of ‘collaboration’: independent entities working together to achieve a well-defined goal • Generalization • Strong, but often useful form of coupling • Consider using composition/aggregation (delegation) instead SE 430: Lecture 7

46. Levels of Coupling Data Coupling • Data is passed from one module to another using arguments Stamp Coupling • More data than necessary is passed via arguments e.g. pass the whole record instead of just the field being changed Control Coupling • A flag is passed from one module to another affecting the functionality of the second module • modules are not independent and so reuse is limited • violates principle of ‘information hiding’ • calling module must ‘know’ how the called module works SE 430: Lecture 7

47. Cohesion • Cohesion – each class should represent a single abstraction. [A class does one thing and does it well.] • From Object-Oriented Systems Analysis: Modeling the World in Data, Shlaer and Mellor, ISBN 0-13-629023-X) SE 430: Lecture 7

48. Cohesion and responsibilities • Like coupling, cohesion is not really a pattern but a design principle or metric that measures how well-focused are the properties of a class • Properties include attributes, operations, and relationships • The responsibilities of a class and its cohesion go hand-in-hand • A cohesive class is responsible for one aspect of the system and all of its properties support this responsibility [A class does one thing and does it well.] • Implication: We can talk about the cohesion of individual properties, typically operations • Cohesion can also be thought of as a ‘just right’ principle: a cohesive class has just the properties needed to fulfill its responsibilities, no more and no less SE 430: Lecture 7

49. Cohesion and responsibilities • Beware of classes that have ‘multiple personalities’ • Example: Consider the challenge of describing the interface for a Swiss Army Knife or Leatherman Tool • Spectrum of cohesion ranges from functionalcoincidental • Cohesion metrics can be static or dynamic • Example: One static metric measures how many times a class references instance variables from the same class • Example: The dynamic counterpart to the static metric measures the number of times instance variables in the same class are referenced during actual execution SE 430: Lecture 7

50. Cohesion example – Date class • Java class which measures the date in milliseconds since the 1 Jan 1970 00:00:00 (sometimes known as ‘the epoch’) • Current interface: • Strongly functional cohesion: • void setTime(long time) • long getTime() • String toString() • Somewhat weaker functional cohesion: • boolean before(Date when) • boolean after(Date when) SE 430: Lecture 7