Chapter 7 – Design and Implementation part 1

1. Chapter 7 – Design and Implementation part 1 Credits to Sommerville book, Dr. Chays and Russell C. Bjork of Gordon College in MA Chapter 7 Design and implementation

2. Topics covered • Object-oriented design using the UML • Design patterns • Implementation issues • Open source development Chapter 7 Design and implementation

3. Design and implementation • Design and Code and Unit Test • Software design and implementation activities are invariably inter-leaved. • Design: process of identifying software components and their relationships at a detailed level • Implementation: process of realizing the design as a program. • Build or Buy – COTS • Design involves understanding COTS • Configuration plus Changes from given COTS Chapter 7 Design and implementation

4. Common activities in these processes include: Define the context and modes of use of the system; Design the system architecture; Identify the principal system objects; Develop design models; Specify object interfaces. Process illustrated here using a design for a wilderness weather station. An object-oriented design process Chapter 7 Design and implementation

5. System context and interactions (part of req) • Goals • Understanding the relationships between the software that is being designed and its externalenvironment • Understanding of the context also lets you establish the boundaries of the system. • Models: • A system context model is a structural model that demonstrates the other systems in the environment of the system being developed. • An interaction model is a dynamic model that shows how the system interacts with its environment as it is used. Chapter 7 Design and implementation

6. System context for the weather station Chapter 7 Design and implementation

7. Weather station use cases (Interaction) Chapter 7 Design and implementation

8. Use case description—Report weather Chapter 7 Design and implementation

9. Once interactions between the system and its environment have been understood, you use this information for designing the system architecture. You identify the major components that make up the system and their interactions, and then may organize the components using an architectural pattern such as a layered or client-server model. The weather station is composed of independent subsystems that communicate by broadcasting messages on a common infrastructure. Architectural design – part of req Chapter 7 Design and implementation

10. High-level architecture of the weather station Chapter 7 Design and implementation

11. Architecture of data collection system Chapter 7 Design and implementation

12. Identifying object classes is often a difficult part of object oriented design. There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers. Object identification is an iterative process. You are unlikely to get it right first time. Object class identification – Design! Chapter 7 Design and implementation

13. Use a grammatical approach based on a natural language description of the system (used in Hood OOD method). Base the identification on tangible things in the application domain. Use a behavioural approach and identify objects based on what participates in what behaviour. Use a scenario-based analysis. The objects, attributes and methods in each scenario are identified. Approaches to identification Chapter 7 Design and implementation

14. Weather station description A weather station is a package of software controlled instruments which collects data, performs some data processing and transmits this data for further processing. The instruments include air and ground thermometers, an anemometer, a wind vane, a barometer and a rain gauge. Data is collected periodically. When a command is issued to transmit the weather data, the weather station processes and summarises the collected data. The summarised data is transmitted to the mapping computer when a request is received. Chapter 7 Design and implementation

15. Object class identification in the weather station system may be based on the tangible hardware and data in the system: Ground thermometer, Anemometer, Barometer Application domain objects that are ‘hardware’ objects related to the instruments in the system. Weather station The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model. Weather data Encapsulates the summarized data from the instruments. See the grammatical and tangible parts method at play Weather station object classes Chapter 7 Design and implementation

16. Weather station object classes Chapter 7 Design and implementation

17. Entity objects Persistent information used by the system Does not include “helper” objects, which are usually transient Control objects Encapsulated functionality of various parts of the system Boundary objects Interaction between the actors and the system Analyze by Types of analysis objects Normally, the analysis objects are closely tied to use cases

18. Example: use case diagram for the Scheduler, version 0.0.3

19. Task A unit of work that is performed by group members List of tasks Contains all tasks for a specific date Scheduled time The time period during which the task is supposed to be performed; represented by the start and end times Elapsed time The actual amount of time spent on the task … Example: Initial analysis objects for the Scheduler from the requirements phase

20. Often identified by analyzing nouns in the use cases Have to be careful, because some of those may not be appropriate E.g. fields, not separate objects Real-world entities that the system has to deal with Data repositories But be careful not to use objects to represent actors Additional terms that are used to clarify functionality in use cases Some objects are not mentioned in the use cases because of the level of granularity In all cases, it is important to use the user terminology The developer terminology will come in during design stages Entity objects

21. Task – tasks that are scheduled and timed UnplannedTask – task representing activities that are not planned for TaskList – all tasks that are scheduled for a specific date, including the unplanned task Date – a date Time – a point in time TimePeriod – duration between two Time points Statistics – performance characteristics computed for all tasks for day, week, or a month Week – representation of a week for statistics Month – representation of a month for statistics Timer – responsible for measuring time CurrentTask – representation of the task activated by the user Example: Design stage entity objects in the Scheduler

22. Activity for removing unnecessary or incorrect objects Done by asking a lot of questions: Are all objects cohesive? Are any of the objects redundant? Are any of the objects irrelevant? Are any of the objects vague? Are any of the objects really attributes of other objects? Are there objects that do not correspond to entity objects? Refining objects

23. All objects seem cohesive Week and Month objects are redundant They represent very similar concepts, which characterize periods of time in terms of days they contain Replace by DateRange All objects seem relevant Statistics object is vague Replace by PerformanceSummary Time object may seem like an attribute, but it is an attribute of many objects, so it’s important enough to be an object Example: refining objects for the Scheduler

24. Represent the interface between the actors and the system In other words, UI, without specifying the details and layout At least one boundary object is needed for accessing each use case But the same boundary object can be used to access several use cases Identified by analyzing the ways the users are going to enter data into, give commands to, and get output from the system As much as possible, the user’s terms must be used Boundary objects

25. CreateTaskDialog EditTaskDialog ErrorDialog CreateTaskActivator EditTaskActivator DeleteTaskActivator DateChooser TaskCompletionActivator TaskIncompletionActivator TimerStarter TimerStopper ExitActivator StatisticsDisplay TaskActivator Example: boundary objects in the Scheduler

26. There is no way around it - there have to be user interface components to manipulate the tasks in all these different ways During design, it may be possible to reduce the number of boundary objects E.g., EditTaskDialog and CreateTaskDialog could be one object But the number of boundary objects is as likely to increase… Hey, aren’t there too many of them?

27. That’s where the logic of the system resides Coordinate the other types of objects Often, a control object per use case Because a user case represents a specific kind of functionality, which needs to be controlled For complicated use cases, more than one control object may be needed One control object may control several simple related use cases Control objects

28. CreateTaskControl EditTaskControl DeleteTaskControl ChooseDateControl CompletionControl Controls both completing and un-completing a task TimingControl Controls both starting and stopping timing a task StatisticsDisplayControl ExitControl PersistenceControl Example: control objects in the scheduler

29. Yes and no Yes: some of these control objects are very closely related and so can be fused into one E.g., CreateTaskControl, EditTaskControl, and DeleteTaskControl can be replaced by TaskControl object E.g., ExitControl doesn’t have to do much except for saving the task data, so its functionality could be rolled into PersistenceControl No: we are looking at the system from the user’s perspective Having different control objects for creating, editing, and deleting tasks makes these operations explicit in the analysis model Hey, aren’t there too many of them?

30. Example: object diagram for Scheduler, v0.0.0

31. Performance Response time, memory requirements, etc. Dependability Robustness, availability, fault tolerance, safety Security Cost factors Development, deployment, upgrade, maintenance, administration costs Maintenance factors Extensibility, modifiability, portability, understandability End user factors Utility and usability Types of design goals

32. There are many trade-offs Execution time can be reduced for the cost of higher memory usage (and vice versa) Improving usability of the system increases development cost More careful development increases development cost but decreases maintenance cost There are many positive co-dependencies Improved usability and portability reduce deployment costs Improved security reduces maintenance costs Are design goals dependent on each other?

33. CRC Cards • Ward Cunningham and Kent Beck to help teach OO, turning data oriented thinkers into OO thinkers • http://c2.com/doc/oopsla89/paper.html • Extreme programmers are advocates of the CRC card • Used as a tool for design, not something to be kept updated or published • A good recent discussion: http://www.coderanch.com/t/98511/patterns/indentifying-classes Chapter 7 Design and implementation

34. CRC Cards – How to Create Them • First do an initial analysis to determine a set of starting classes, usually a bunch of boundary and entity objects and their controllers. • Then, make one card for every class. Write the class (object) name at the top of the card. Draw a line down the middle and write the responsibilities and collaborators on each side. Chapter 7 Design and implementation

35. CRC Card - Example • Not every little detail Chapter 7 Design and implementation

36. CRC Card – Use them to walk through • After writing initial cards • walk through scenarios and use cases • A set of cards in front of you • Hold up the cards as you talk about the situation • Add cards or responsibilities as needed. • Keep placing them back on the table in ways that make sense. • Cards that are closely related may overlap • Cards that oversee other objects should be on top • Aggregation and inheritance should be reflected by having parts below the whole. • This will probably come naturally. Just place the cards where they make the most sense to the team Chapter 7 Design and implementation

37. ATM Example • Class exercise: What classes will you need to handle a typical ATM machine? The ATM will handle withdrawals, deposits, transfers and inquiries. • Requirements statement: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/Requirements.html • First basic use case, then first pass analyze classes and finally create CRC cards and then class, state and sequence diagrams Chapter 7 Design and implementation

38. ATM Example – Use Cases • We have done a few already, but let’s do one more quickly for practice. • Everyone quickly write a use case on paper from the requirements page: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/Requirements.html • When you are done: • See Bjork’s suggestion when you are done http://www.math-cs.gordon.edu/courses/cps211/ATMExample/UseCases.html • Click on an action to see a worded use case • Click on the related sequence diagram, especially transaction sequence diagram • Click on withdrawal to see a collaboration diagram – just for info Chapter 7 Design and implementation

39. ATM Example – first pass analyze classes • First, lets analyze classes, looking for entity, control and boundary objects AND considering grammatical, tangible and behavior concepts AND also looking at use cases • Consider • Requirements def: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/Requirements.html • use cases: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/UseCases.html • Functional tests (we skipped these): http://www.math-cs.gordon.edu/courses/cps211/ATMExample/InitialFunctionalTests.html • Don’t look at Bjork’s suggestions until we get past the CRC cards and writing our own class diagrams Chapter 7 Design and implementation

40. ATM Example – Time for CRC Cards • Create the cards from your analysis classes • One set of cards for each half of the class (split not along our class project lines) • Talk through one scenario – making a withdrawal perhaps, picking up the cards needed and placing them on the table. • Take turns so that everyone talks through at least one scenario. • Add if you need Chapter 7 Design and implementation

41. Static – model structure Subsystem models that show logical groupings of objects into coherent subsystems. Sequence models that show the sequence of object interactions. Dynamic – model behavior State machine models that show how individual objects change their state in response to events. Other models include use-case models Reminder - Design model types Chapter 7 Design and implementation

42. ATM Example diagrams practice • Create a class diagram from your classes. • It should be very similar to how your cards are arranged. • Quickly done on paper • Include cardinality (1/1 or 1 / * or */*) • Include inheritance big arrows – arrow points to the whole • Create some state diagrams • ATM Machine state diagram – off, serving customer, waiting • ATM Session state diagram – what states occur in a session? • Create some sequence diagrams • customer start session diagram – using our classes • Customer transaction (after logon) – using our classes Chapter 7 Design and implementation

43. ATM – check Bjork’s design • http://www.math-cs.gordon.edu/courses/cps211/ATMExample/ClassDiagram.html • Class diagram Annotations • Diamond • Diamond attached to the class that contains another class. • Often read as “has a “ from the diamond side to the non-diamond, and “is part of” from the non-diamond to the diamond. • Filled diamond means the part cannot exist without the container. If the container is deleted, delete the parts. Chapter 7 Design and implementation

44. ATM – check Bjork’s design – more annotations • http://www.math-cs.gordon.edu/courses/cps211/ATMExample/ClassDiagram.html • Class diagram Annotations • Triangle • Triangle attached to the whole in an “is a “ relationship. • The class not touching the triangle “is a “ the class touching the triangle. • The class touching the triangle “can be a “ the class not touching the triangle (“but it will not always be one”) Chapter 7 Design and implementation

45. ATM – check Bjork’s design – more annotations • http://www.math-cs.gordon.edu/courses/cps211/ATMExample/ClassDiagram.html • Class diagram Annotations • Small arrow • Two classes are related, but only one knows the relationship exists • The class without the arrow knows the one with the arrow exists • Solid line – the arrow side is contained inside the other side • Dotted line – just has a weak relationship with (maybe creates it during a method) Chapter 7 Design and implementation

46. ATM – check Bjork’s design – more annotations • http://www.math-cs.gordon.edu/courses/cps211/ATMExample/ClassDiagram.html • Class diagram Annotations • Dotted line - association • To small arrow – depends on the small arrow side • Non-arrow side “somehow depends upon” arrow side • (small arrow side may be an interface) • Maybe “uses’ , calls, creates, sends, instead of “depends upon” • To large arrow - realizes (implements or executes) • Non arrow side implements or executes arrow side Chapter 7 Design and implementation

47. ATM – check Bjork’s design – other • CRC Cards: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/CRCCards.html • State diagrams: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/Statecharts.html • Sequence diagrams: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/Interactions.html Chapter 7 Design and implementation

48. Shows how the design is organised into logically related groups of objects. In the UML, these are shown using packages - an encapsulation construct. This is a logical model. The actual organisation of objects in the system may be different. http://www.math-cs.gordon.edu/courses/cps211/ATMExample/Package.html Bjork’s Subsystem model Chapter 7 Design and implementation

49. Objects Object interfaces have to be specified so that the objects and other components can be designed in parallel. Designers should avoid designing the interface representation but should hide this in the object itself. Objects may have several interfaces which are viewpoints on the methods provided. The UML uses class diagrams for interface specification Subsystems Interfaces between systems or subsystems need careful documenting so that development teams can work independently towards common goal Interface specification – for independent work Chapter 7 Design and implementation

50. One step lower – Detailed Design of Classes • Class definition document for each class • Purpose of class • Roles it will play and when it will be alive in those roles • Instance and class variables • Static and non-static methods, with their parameters and return value, purpose, pre-conditions and post-conditions • Constructor definitions Example: http://www.math-cs.gordon.edu/courses/cps211/ATMExample/DetailedDesign.html Chapter 7 Design and implementation