Information Systems Analysis and Design More Class Modeling; Patterns

1. Information Systems Analysis and DesignMore Class Modeling; Patterns INFO 620 Glenn Booker Lecture #6

2. Object Design • The rough steps followed so far include: • Define requirements and model with use cases • Create domain model (conceptual class diag.) • Now to design objects we need to: • Add methods to the classes and define messaging between objects to fulfill the requirements • But that last step isn’t trivial! Lecture #6

3. GRASP Patterns • GRASP patterns help define normal ways that objects interact with each other • GRASP is Larman’s term; “General Responsibility Assignment Software Patterns” • We’ll cover five of the patterns in the text • For all 23 standard patterns, see Erich Gamma’s classic Design Patterns(ISBN 0201633612 or 0201634988) Lecture #6

4. Responsibilities • The responsibilities for an object describe what behavior it needs to fulfill • Doing • Create an object • Perform a calculation • Start action in another object • Control activities in other objects • “Sale is responsible for creating SalesLineItem” Lecture #6

5. Responsibilities • Knowing • About private encapsulated data • About related objects • About things it can calculate or derive • “Sale is responsible for knowing its total” • Most ‘knowing’ responsibilities are apparent from the attributes and associations of the object Lecture #6

6. Responsibilities • Translating responsibilities into classes and methods depends on how detailed or general the responsibilities are • Methods are often implemented to fulfill responsibilities Lecture #6

7. Getters and Setters • Detailed object methods often include a lot of getters and setters • Getters ‘get’ some value for the outside world, e.g. getTotal (a ‘knowing’ responsibility) • Setters ‘set’ some value – like assignment statements, e.g. setSecurityLevel(a ‘doing’ responsibility) Lecture #6

8. Note Payment shifted down to show its creation makePayment implies Sale objects are responsible for creating Payments Responsibilities, Methods related Lecture #6

9. Defining Patterns • Patterns capture well established “best practices” for design • Some are very low level; others are architectural • Each Pattern is defined by its Name, a summary of the Pattern’s Solution, and a description of the Problem it solves Lecture #6

10. Defining Patterns • Patterns are not always the best solution • Good pattern descriptions include when the pattern may not apply, or the pros and cons of the pattern Lecture #6

11. The First Five GRASP Patterns • Information Expert • Creator • High Cohesion • Low Coupling • Controller Lecture #6

12. Information Expert • Problem: what is the general principle of assigning responsibilities to objects? • Solution: assign responsibility to the Information Expert – the class which has the information needed to fulfill the responsibilityor Whoever has the data is responsible for managing and sharing it! Lecture #6

13. Information Expert • The domain model should inspire expansion into design classes which will handle all of the data and use it to meet requirements • A key step is that we have to make up the classes we think we’ll need, based on the system characteristics, and see if they can work correctly Lecture #6

14. Information Expert • So if we have a class called Sale (like Shipment in the homework assignments), one responsibility might be to provide the total cost of the Sale • We know from a typical invoice that a Sale might consists of a bunch of line items, so we might call their class SalesLineItem Lecture #6

15. Information Expert • Each SalesLineItem may have a quantity • And each SalesLineItem needs someplace safe to store its description and price, so we’ll put that in a ProductSpecification • After defining the associations and multiplicity, we get Figure 16.3 (p. 222), shown on the next slide Lecture #6

16. Information Expert Lecture #6

17. Information Expert • So at the highest level, we need to get the total cost from SaleBut in order to get that, we need the subtotal of each line item – so get that from the information expert for each line item Lecture #6

18. Information Expert • So each SalesLineItem can get the subtotal of that line; and the Sale will get those subtotalsBut each line item needs the price of each item; get from ProductDescription Lecture #6

19. Information Expert • Omitting variable assignments we have:Where each object is responsible for providing the data it owns Lecture #6

20. Information Expert • The class diagram becomes: Lecture #6

21. Information Expert • Information Expert is used very frequently in object design • May not be suitable when coupling or cohesion dictate otherwise (see later) Lecture #6

22. Creator • Problem: Who is responsible for creating a new instance of a class? • Solution: Let B create instances of A if: • B aggregates (is made up of) A • B contains (holds) A objects • B records instance of A objects • B closely uses A objects • B has data needed when A is created Lecture #6

23. Creator • Creation of objects is also a very common activity • In the previous example, Sale aggregates (contains) many SalesLineItem objects (one object per line in the Sale), hence is makes sense for Sale to be a Creator of SalesLineItem instances Lecture #6

24. Creator • Hence a responsibility of the system is that a Sale needs a method to makeLineItem • If you want add X (quantity) widgets to a shopping cart, then Sale adds them to the cart Lecture #6

25. Creator • The sequence diagram would be: Lecture #6

26. Creator • If the creation of an object is very complex, then the Factory pattern would be better (see Ch. 23) Lecture #6

27. Low Coupling • Problem: How can we support low dependency among classes, low impact of changes, and increase reuse of classes? • Solution: Assign responsibilities so that coupling remains low • Coupling describes the extent of interconnection among classes Lecture #6

28. Low Coupling • Notice that some coupling is needed – otherwise the classes don’t interact • Too much coupling means that changes to one class might have unexpected changes elsewhere • Related to “visibility” – how many other objects does each one need to see? Lecture #6

29. “Stair” Object Structure Lecture #6

30. “Fork” Object Structure Lecture #6

31. Low Coupling • The Stair structure is generally preferred where possible • Might have to use Fork structure if • The sequence of operations may change, and/or • New operations may be needed frequently • Subclasses are, by definition, high levels of coupling between objects Lecture #6

32. Low Coupling • Particularly avoid high coupling for objects which may change interface, implementation, or existence frequently • Desire for low coupling may conflict with Expert or High Cohesion patterns • No firm measure of what level of coupling is “good” Lecture #6

33. High Cohesion • Problem: how do you keep complexity manageable? • Solution: Assign responsibilities so that cohesion remains high • Cohesion is a measure of how closely related an object’s responsibilities are • High cohesion means a closely related set of narrowly defined responsibilities Lecture #6

34. High Cohesion • In other words, don’t make an object do too much work! • Low cohesion generally results from remaining too abstract when defining responsibilities • Per Booch, high cohesion is when the elements of a class “all work together to produce some well-bounded behavior” Lecture #6

35. High Cohesion • An object which has a kitchen-sink function (it catches all the functions except the kitchen sink) generally has very low cohesion • A single complex function can result in low cohesion • Moderate cohesion would have similar, but not closely related, functions together Lecture #6

36. High Cohesion • High cohesion classes have some responsibilities in one set of functions, and use other objects to accomplish them • Modular design is a similar concept as ‘low coupling and high cohesion’ • Conversely, high coupling and low cohesion often appear together Lecture #6

37. High Cohesion • Deliberately violating high cohesion is rare • Might have to do it: • To isolate related functions (rare) • To distribute object to different servers • To manage an external interface Lecture #6

38. Controller • Problem: who is responsible for handling external input system events? • Solution: assign the responsibility to a Controller object • Façade controller represents the entire subsystem or interface • Session controller handles an entire use case where some events may occur Lecture #6

39. Controller • An ‘input system event’ is some event from an external actor (human or not) • The Controller object is responsible for deciding what to do with the input system event Lecture #6

40. Controller • So the Controller pattern applies to both management of external system interfaces (capture the entire interface in a single controller class), and managing inputs from user interfaces • User interface controllers generally end with <>Handler, <>Coordinator, or <>Session, where <> = <Use Case Name> Lecture #6

41. Controller • Note that user interfaces (e.g. windows, views, or documents) are NOT part of the Controller’s job – those belong to an object at the Interface (or Presentation) Layer • Controller acts as a façade between interface and the application • Controllers DELEGATE work to other objects – they don’t do it themselves Lecture #6

42. BCE Objects • We can break objects into three major types for many purposes • Boundary objects (user interface window, buttons, etc.) • Control objects (controllers who make decisions, here also called ‘use case handlers’) • Entity objects (persistent objects which contain data) Lecture #6

43. BCE Objects • These might be correlated to the kinds of computers involved in processing them • User interface might be at a PC level (e.g. web browser) • Controller objects might run on an application server (captures logic, e.g. web server) • Entity objects might run on a database server (stores data) Lecture #6

44. Façade Controller • Façade controllers hide an entire system or subsystem under one class, such as Register or System • Avoid except for simple external systems • Works well if only a few events to manage; otherwise may need use case controllers to break down system functions into smaller sets (p. 241) Lecture #6

45. Façade Controller Lecture #6

46. Avoiding Bloated Controllers • Even a façade controller should generally have more than one class • Beware of controllers which perform work without calling another class • Controllers should have few or no attributes • Fix bloat by adding more controller classes, and/or redesign to delegate more work Lecture #6

47. Use Case Realization • Every scenario in a use case can become a ‘use case realization,’ which shows how the design model meets the requirements for that use case • Use Case Realization is UP term, not UML • Interaction diagrams help express Use Case Realization Lecture #6

48. Use Case Realization • Use case suggests system events shown in system sequence diagram • Effect of operations may be documented in operation contracts • Events represent messages which initiate interaction diagrams • Interaction diagrams describe communication between classes Lecture #6

49. Interaction Diagrams • Recall the collaboration diagrams are specific to one use case • Sequence diagrams generally show one scenario for one use case; might show extensions • Operations contracts describe the conditions for one event in one use case Lecture #6

50. Models Don’t Start Perfect • Expect that early requirements, and the initial domain model (conceptual class diagram) will not be perfect • But that doesn’t mean do them poorly! • Maintain contact with customer and subject experts to keep improving models • Conceptual classes inspire design classes • But many additional classes likely needed Lecture #6