CSCE 431: Design

1. CSCE 431: Design Some material from B. Meyer, M. Oriol, B. Schoeller at ETH Zürich

2. Outline • From requirements to design • UML class diagrams • From analysis classes to implementation classes • More of UML CSCE 431 Design

3. From Requirements to Design • S, DR • S= specification • D = domain properties • R = requirements • Come up with a design that satisfies S CSCE 431 Design

4. Semantic Gap • A requirements specification • IEEE Std 830-1998, UML use cases,…  Semantic Gap  • A complete description of the design CSCE 431 Design

5. How to Bridge the Semantic Gap • Lots of advice available • But hard to give concrete methods or truly endorse most of it • Our advice focuses on going from OO analysis to OO design, and then implementation • Not all languages are OO, but OO seems to give a usable starting point for understanding systems and designs CSCE 431 Design

6. Role of Object-Oriented Analysis • Analysis object model later refines to object model • Analysis object and dynamic models basis of system design CSCE 431 Design

7. Analysis • Developers formalize requirements specification • Examine exceptional cases, boundary conditions • Clients engaged • OO Analysis • Developers build an object model of the application domain • Extend model with how actors and system interact with the application domain objects CSCE 431 Design

8. Trade-Offs • Create design that matches requirements as closely as possible? • Or reuse existing designs/implementations as much as possible, at expense of less direct match to requirements? • Create class hierarchy that closely matches problem domain? • Or create class hierarchy that supports extensibility, reuse, etc. and uses abstractions from implementation domain? CSCE 431 Design

9. Outline • From requirements to design • UML class diagrams • From analysis classes to implementation classes • More of UML CSCE 431 Design

10. Basic UML Models • Functional model • Functionality of the system from the user’s point of view • Use case diagrams • Object model • Structure of the system • objects, attributes, associations, operations • analysis object model → system design object model →design object model • Dynamic model • Describes the behavior of objects (states and state transitions, control and data flow) • Interaction diagrams • State machines • Activity diagrams CSCE 431 Design

11. Describing Static Structure of a System • What kind of objects are in the system • Representing classes • Representing relations between classes • Many notations exist • ER models • Purely about entities and their relations • UML class diagrams • Clear OO flavor, and a mapping to implementation using OO technologies CSCE 431 Design

12. ER Diagrams CSCE 431 Design

13. Using UML Class Diagrams • Used • During requirements analysis to model application domain concepts (taxonomies) • During system design to model subsystems • During object design to specify classes in detail, including their methods and attributes • Thus used by both analysts and developers CSCE 431 Design

14. Object vs. Class • An object (instance): exactly one thing • Aclass describes a group of objects with similar properties object diagram a graphical notation for modeling objects and their relationships class diagram template for describing many instances of data; useful for taxonomies, patterns, and schemata instance diagram a particular set of objects relating to each other; useful for discussing scenarios, test cases and examples CSCE 431 Design

15. UML Class Diagrams: Features • Classes: name, attributes, operations • Associations • navigation arrows • multiplicities • qualifications • roles • Association classes • Aggregations • Inheritance CSCE 431 Design

16. Outline • From requirements to design • UML class diagrams • From analysis classes to implementation classes • More of UML CSCE 431 Design

17. Object Modeling • One of the motivations of object-orientation is that one can model reality with objects • Goal of object modeling: find important abstractions • Classes • Primarily to understand the system • Secondarily to serve as the blueprint of an implementation • Analysis class hierarchy does not have to match with the implementation class hierarchy • Some classes might be represented as relations, relations as classes, classes as attributes, attributes as classes, etc. • Perhaps a useful guideline: implementation should be a refinementof analysis classes CSCE 431 Design

18. Basic Process of Class Design • Iterate in some order, until convergence • Identify classes • Find attributes • Find operations • Find associations between classes • Above too vague • Some guidance exists CSCE 431 Design

19. Some Methods • Abbott • R. Abbott, “Program design by informal English descriptions,” CACM, vol. 26, no. 11, 1983 • Analyze textual descriptions of flows of events in scenarios and use cases • e.g., nouns are candidates for objects/classes • e.g., verbs are candidates for operations • Booch • Data flow analysis, followed by identifying concrete and abstract objects (e.g., from data stores) • Coad and Yourdon • Look for things or events remembered, devices, roles, sites, and organizational units • Shlaer-Mellor • Tangible entities, roles, incidents, interactions, and specifications CSCE 431 Design

20. Example, Abbott’s Technique The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 euros. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is 3 years old. The assistant recommends another type of toy, a boardgame. The customer buys the game and leaves the store. CSCE 431 Design

21. Example, Abbott’s Technique The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 euros. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is 3 years old. The assistant recommends another type of toy, a boardgame. The customer buys the game and leaves the store. CSCE 431 Design

22. Mapping Grammatical Constructs to Model Components CSCE 431 Design

23. Class Diagram The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 euros. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is 3 years old. The assistant recommends another type of toy, a boardgame. The customer buys the game and leaves the store. CSCE 431 Design

24. Class Diagram The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 euros. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is 3 years old. The assistant recommends another type of toy, a boardgame. The customer buys the game and leaves the store. CSCE 431 Design

25. Discussion Is the previous technique useful? • At best, use with caution • Nouns can • Suggest notions that do not yield classes • Fail to suggest notions that should yield classes • Explicit use of Abbott’s technique seems like a game/toy CSCE 431 Design

26. Many Other Criteria for Identifying Classes • Existing designs, reuse • Domain knowledge and solution knowledge • General world knowledge • Extensibility, variation points • Find key abstract data types CSCE 431 Design

27. No Fool-Proof Methodology • Must settle for some hints and warnings CSCE 431 Design

28. How Directly to Follow Requirements Specification? • Not too directly • Crucial abstractions may not be directly deducible from the requirements • Tends to suggest a specific, non-reusable solution • Implies we do not refactor code • Remember: good requirements do not prescribe a solution CSCE 431 Design

29. What Classes to Reject? • Abstract data types that are not semantically rich enough • Know the business domain and what is relevant to it • We concretize by observing shortcomings of grammar-based techniques: The elevator will close its door before it moves to another floor. • Should door be a class? • Might just be a Boolean member of an elevator class • Might be important enough to warrant its own class • Clear that grammar games next to useless –question to ask: Is door a separate data type with its own clearly identified operations, or are all the operations on doors already covered by operations on other data types, such as elevator? CSCE 431 Design

30. What Classes to Reject? The elevator will close its door before it moves to another floor. • Should floor be a class? • Likely integers is a sufficiently close abstraction • Possible reasons for a proper floor class • properties, such as floor access rights • integers support too many operations (what operations do not make sense? • What would it mean to add or multiply to floors? CSCE 431 Design

31. What Classes to Accept? A database record must be created every time the elevator moves from one floor to another. • Important class move easily missed with grammar-based method class move { initial, final: floor // or int record (database& d) { . . . } } CSCE 431 Design

32. What Classes to Reject? • Mixed abstractions • E.g., MFC’s coordinate functions tied to DCs • Should be split into several classes, one per abstraction • Premature classification • “taxomania” • Use “ADT view”: a new class should add or modify a feature, or strengthen the invariant • Known examples of bad/poor class choices for the specific domain • Antipatterns – commonly used, but ineffective patterns CSCE 431 Design

33. Other Danger Signals • Class with a verb name (infinitive or imperative) • Perhaps better modeled as a routine • Class described as “performing something” • May not be a proper data abstraction • Class with a single public routine • Maybe again better modeled as a routine • Using objects as lambdas useful, but such classes not likely to appear during analysis • Class with no routines • Maybe some routines missing, or maybe not an ADT at all CSCE 431 Design

34. Class Elicitation Principle • Class elicitation is a dual process: • class suggestion • class rejection CSCE 431 Design

35. Meyer’s “Ideal Class” Typical Properties • Clearly associated abstraction, which can be described as a data abstraction (or abstract machine) • Class name is a noun or adjective, adequately characterizing the abstraction • Class represents set of possible run-time objects - its instances (some classes have only one instance during an execution) • Several queries available for instance properties • Several commands available to change instance state (in some cases, instead of commands there are functions producing objects of the same type, e.g. integer operations) • Abstract properties can be stated, (preferably formally, describing: how the results of the various queries relate to each other (this will yield the invariant); under what conditions features are applicable (preconditions); how command execution affects query results (postconditions). CSCE 431 Design

36. What to Consider? • Analysis classes • Belong to the problem space • Describe data abstractions directly drawn from the domain model • Design classes • Belong to the solution space • Describe architectural choices • Implementation classes • Belong to the solution space • Describe data abstractions introduced for the internal needs of the algorithms CSCE 431 Design

37. Finding the Design Classes • Understand the importance of reuse: beware of the NIH (Not Invented Here) syndrome • Reuse previous known designs in the same domain • Avoid bugs! • Know standard design patterns • Avoid reinvention! • Consider describing abstractions as “machines” rather than “objects” CSCE 431 Design

38. Finding the Implementation Classes • Reuse! • Know and use the classical data structures and algorithms • Know and use existing libraries of your language • Standard libraries • Company/group libraries • A waste to write your own string, array, tree, … class CSCE 431 Design

39. Different Kinds of Objects • Often the following categories can be identified • Suggested in: Jacobson, Booch, Rumbaugh: The Unified Software Development Process. Addison-Wesley, 1999 • Entity objects • Represent the persistent information tracked by the system • Application domain objects, also called “Business objects” • Boundary objects • Represent the interaction between the user and the system • Control objects • Represent the control tasks performed by the system • Somewhat related to a model-view-controller architecture CSCE 431 Design

40. Object Kinds in Digital Watch Year Button Entity Objects Control Objects Boundary Objects ChangeDate Month LCDDisplay Day CSCE 431 Design

41. Identifying Entity Objects • Recurring nouns in requirements • Real-world entities that system must track • Real-world processes that system must track • Data sources or sinks CSCE 431 Design

42. Identifying Boundary Objects • Boundary objects collect information from user • Boundary objects translate information into format for entity and control objects • User interface controls to initiate actions • Forms to enter data • Messages the system uses to respond CSCE 431 Design

43. Identifying Control Objects • Control objects coordinate boundary and entity objects • Control objects do not have a concrete counterpart in the real world • Identify one control object per business task CSCE 431 Design

44. Outline • From requirements to design • UML class diagrams • From analysis classes to implementation classes • More of UML CSCE 431 Design

45. Sequence Diagrams • Ties use cases with objects • Shows how behavior of use case distributed among its participating objects • More concise (and possibly more precise) than textual use case descriptions CSCE 431 Design

46. Sequence Diagrams: Notation • Each column represents an object • Horizontal arrows are messages or stimuli • Vertical rectangle is an activation of an operation • Length represents time of being active • Triggered by a message • Messages can originate from operations • Time proceeds from top to bottom • Lifetime also depicted • Objects on top row exist from start • Other objects created with «create» messages • Vertical dashed line expresses object’s life time • Time span an object can receive messages • Cross depicts destruction CSCE 431 Design

47. Sequence Diagram Conventions • First column: initiating actor • Second column: boundary object • Third column: control object managing the rest of the use case • Control objects created by boundary objects • Boundary objects created by control objects • Entity objects accessed by control and boundary objects • Entity objects never access control or boundary objects • Entity objects stay reusable across use cases CSCE 431 Design

48. Example CSCE 431 Design

49. Example (cont.) CSCE 431 Design

50. State Machine Diagrams • State machines represent a system’s behavior from a single object’s perspective • (Sequence diagrams represent a system’s behavior from a single use case’s perspective) • Cross-checking (which actions trigger which transitions) between both views useful • Can reveal new use cases • Can reveal missing states • Can reveal ambiguities, incoherencies CSCE 431 Design