1. INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker

2. INFO 620Lecture #62 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!

3. INFO 620Lecture #63 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)

4. INFO 620Lecture #64 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”

5. INFO 620Lecture #65 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

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

7. INFO 620Lecture #67 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)

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

9. INFO 620Lecture #69 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

10. INFO 620Lecture #610 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

11. INFO 620Lecture #611 The First Five GRASP Patterns Information Expert Creator High Cohesion Low Coupling Controller

12. INFO 620Lecture #612 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 responsibility or Whoever has the data is responsible for managing and sharing it!

13. INFO 620Lecture #613 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

14. INFO 620Lecture #614 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

15. INFO 620Lecture #615 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

16. INFO 620Lecture #616 Information Expert

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

18. INFO 620Lecture #618 Information Expert So each SalesLineItem can get the subtotal of that line; and the Sale will get those subtotals But each line item needs the price of each item; get from ProductDescription

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

20. INFO 620Lecture #620 Information Expert The class diagram becomes:

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

22. INFO 620Lecture #622 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

23. INFO 620Lecture #623 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

24. INFO 620Lecture #624 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

25. INFO 620Lecture #625 Creator The sequence diagram would be:

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

27. INFO 620Lecture #627 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

28. INFO 620Lecture #628 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?

29. INFO 620Lecture #629 “Stair” Object Structure

30. INFO 620Lecture #630 “Fork” Object Structure

31. INFO 620Lecture #631 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

32. INFO 620Lecture #632 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”

33. INFO 620Lecture #633 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

34. INFO 620Lecture #634 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”

35. INFO 620Lecture #635 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

36. INFO 620Lecture #636 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

37. INFO 620Lecture #637 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

38. INFO 620Lecture #638 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

39. INFO 620Lecture #639 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

40. INFO 620Lecture #640 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 <> =

41. INFO 620Lecture #641 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

42. INFO 620Lecture #642 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)

43. INFO 620Lecture #643 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)

44. INFO 620Lecture #644 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)

45. INFO 620Lecture #645 Façade Controller

46. INFO 620Lecture #646 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

47. INFO 620Lecture #647 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

48. INFO 620Lecture #648 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

49. INFO 620Lecture #649 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

50. INFO 620Lecture #650 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

51. INFO 620Lecture #651 Model-View Separation Non-GUI objects should not be involved in output tasks This reinforces the Boundary/Control/Entity object distinction earlier Controllers should know the information to be displayed in output, but actual output is a boundary object’s purpose

52. INFO 620Lecture #652 More UML Notation Constraints are tagged with curly brackets {}. An algorithm may be shown if needed. Notes are in text boxes which also have the upper right corner dog-eared <- Constraint <- Note

53. INFO 620Lecture #653 Object Constraint Language UML supports using a formal Object Constraint Language (OCL) to show constraints on execution of messages –http://www.omg.org/docs/ad/97-08-08.pdfhttp://www.omg.org/docs/ad/97-08-08.pdf –A newer version of the OCL is under development as of July 2003 Any notation may be used, however

54. INFO 620Lecture #654 Iteration 2 The text’s second iteration assumes that in iteration 1 everything was done through development of the design class diagram, and major architecturally important parts of the system have been coded and tested Iteration 2 is refining the design through additional patterns (which we aren’t covering)

55. INFO 620Lecture #655 Iteration 2 Iteration 2 also adds more scenarios to the foundation already established Additional lower priority use cases may be fully defined The system sequence diagram may be expanded to include external systems (p. 324)