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

2. What is wrong with this diagram? Seems like a lot of similarity between Task and UnplannedTask Can use inheritance to reduce the clutter UnplannedTask is a special class of Task  …or is it the other way around? Make Task extend UnplannedTask

3. Example: object diagram for Scheduler, v0.0.1

4. What are we going to do with this CurrentTask object? Is it a different kind of object than Task and UnplannedTask?  No, any Task or UnplannedTask can play the role of CurrentTask  So, cannot use inheritance It seems to be in a relationship with TaskList  TaskList contains a CurrentTask

5. Cardinality of associations in object diagrams It is often useful to specify how many objects can participate in an association  E.g., a task list can contain any number of tasks, but a task can appear in only one task list Indicated by putting numbers and symbols on association edges TaskListTask 1 * Can be omitted

6. Example: object diagram for Scheduler, v0.0.2

7. Hmm, this reveals some problems… This diagram says that TaskList can contain only one task How to fix it?  Can add another aggregation association between TaskList and Task, or  Can change the inheritance hierarchy and introduce a task type that both Task and UnplannedTask inherit from  This is what we are going to do

8. Example: object diagram for Scheduler, v0.0.3

9. Example: object diagram for Scheduler, v0.0.5

10. Working in boundary and control objects An object diagram including only entity objects is nice because it  Gives a good intuitive idea of how the entities depend on each other  Doesn’t have to deal with objects that may be confusing to the users  Is less cluttered than diagrams including also boundary and control objects Introducing boundary objects into object diagrams helps with identifying which objects are accessed through which user interfaces in which ways Introducing control objects explicitly shows the way that control connects objects together

11. Example: object diagram for Scheduler, v0.0.12

12. Are Time and TimePeriod important enough to stay separate classes? Have an alternative for Time and TimePeriod  Leave them as separate classes  Represent important user-level concepts  Since they are only used by Task, consider them attributes of Task, not separate classes  Makes the diagram smaller and higher-level  Select this option

13. Example: object diagram for Scheduler, v0.0.13

14. Putting in control objects Do not have to do it  In many cases, clutter the diagram without adding much value May be helpful if the way in which they use entity and boundary objects is non-trivial

15. Example: object diagram for Scheduler, v0.0.15

16. Example: object diagram for Scheduler, v0.0.16

17. Showing dynamic interactions between objects using sequence diagrams Use cases are not precise about interactions  Say what needs to be done, but not  What objects are involved  Who is responsible Object diagrams show interactions, but not in terms of a specific use case  May be hard to define the role of an object in a specific use case if this object participates in many other use cases Sequence diagrams show a single use case (or even scenario) in terms of:  The sequence of actions and  The participating objects

18. Sequence diagram notation All participating objects and actors have vertical timelines Interactions between objects are shown as messages sent from one object to another Duration of an interaction from the point of view of an object is shown by a vertical box  “return” events may be shown Deletion of an object is shown with an “X” Object 1Object 2Object 3 message1 message2 message3

19. Example:sequence diagram for timing a task, Scheduler, v0.0.0

33. What is missing from this diagram? After the task has been timed, the elapsed time is changed for the Task object, but this does not mean that the UI interface object reflects this change  Need to send a message to the TaskBoundary object

34. Example:sequence diagram for timing a task, Scheduler, v0.0.1

35. This diagram does not satisfy the use case timeTask! This use case says: Preconditions: No task is being timed Normal flow: (1) The user makes the chosen task current in the list of all tasks (2) Use case startTimer is triggered (3) The display of the elapsed time of the current task is updated in real time (4) Use case stopTimer is triggered Postconditions: (1) No task is being timed (2) The elapsed time of the task that has been timed is incremented by the duration of the time interval between the start and the end of timing

36. This diagram does not satisfy the use case timeTask! This use case says: Preconditions: No task is being timed Normal flow: (1) The user makes the chosen task current in the list of all tasks (2) Use case startTimer is triggered (3) The display of the elapsed time of the current task is updated in real time (4) Use case stopTimer is triggered Postconditions: (1) No task is being timed (2) The elapsed time of the task that has been timed is incremented by the duration of the time interval between the start and the end of timing

37. Example:sequence diagram for timing a task, Scheduler, v0.0.2

38. Are there some relationships among objects that are missing from the object diagram? TimingControl object needs to get the current task from ActivatorControl object TimingControl object needs to access TaskBoundary object to update the view of the elapsed time The object diagram, v0.0.16, does not show these relationships

39. Example: object diagram for Scheduler, v0.0.17

40. Example:sequence diagram for changing date, Scheduler, v0.0.0

41. Let’s compare it against the chooseDate use case This use case says: Preconditions: no tasks are being created, notified, or timed Normal Flow: (1) The user modifies the field containing the date for which tasks are shown (2) The user activates the change Alternate Flow: If the date entered is not in the correct format, (1) An error dialog window appears, describing the error (2) The user acknowledges the error, which causes the error dialog to appear (3) The date is reset to the previous value Postconditions: (1) The list of tasks for the chosen date is displayed (2) If the chosen date is different from the previous date, the list of tasks for the previous date is not shown

42. Let’s compare it against the chooseDate use case This use case says: Preconditions: no tasks are being created, notified, or timed Normal Flow: (1) The user modifies the field containing the date for which tasks are shown (2) The user activates the change Alternate Flow: If the date entered is not in the correct format, (1) An error dialog window appears, describing the error (2) The user acknowledges the error, which causes the error dialog to appear (3) The date is reset to the previous value Postconditions: (1) The list of tasks for the chosen date is displayed (2) If the chosen date is different from the previous date, the list of tasks for the previous date is not shown

43. Who is right? The use case says that the user first changes the date and then confirms the change  Two explicit steps The sequence diagram says only that the user enters the new date  Implies one step There may be different ways to design the GUI for the date change  The use case is probably too specific  We will change the use case

44. New use case chooseDate, v0.1.0 Preconditions: no tasks are being created, notified, or timed Normal Flow: (1) The user requests the date change through the GUI Alternate Flow: If the date entered is not in the correct format, (1) An error dialog window appears, describing the error (2) The user acknowledges the error, which causes the error dialog to appear (3) The date is reset to the previous value Postconditions: (1) The list of tasks for the chosen date is displayed (2) If the chosen date is different from the previous date, the list of tasks for the previous date is not shown

45. Now this use case is incomplete! The user only requests the change, but there is nothing in this use case that says that the new date will be shown  Use case chooseDate, v0.1.1: Preconditions: no tasks are being created, notified, or timed Normal Flow: (1) The user requests the date change through the GUI Alternate Flow: If the date entered is not in the correct format, (1) An error dialog window appears, describing the error (2) The user acknowledges the error, which causes the error dialog to appear (3) The date is reset to the previous value Postconditions: (1) The list of tasks for the chosen date is displayed (2) If the chosen date is different from the previous date, the list of tasks for the previous date is not shown (3) The new date is displayed

46. Example:sequence diagram for changing date, Scheduler, v0.1.0=v0.0.0

47. The activity of displaying a new date is missing from this diagram Because of the change in the use case, DateChooser does not have to send the new date to ChooseDateControl in the string format ChooseDateControl object knows what the new date is, so it just has to send it to the object that displays it.  Which one?  To figure this out, let us look at the object diagram again

48. Example: object diagram for Scheduler, v0.1.0 = v0.0.17

49. A problem! Obviously, DateChooser boundary object should be made responsible for displaying the date But the object diagram does not show the relationship between ChooseDateControl and DateChooser that accomplishes that  We have to add this relationship

50. Example: object diagram for Scheduler, v0.1.1

51. Example:sequence diagram for changing date, Scheduler, v0.1.1

52. Modeling dynamic behavior of a single object with statechart diagrams Use case, object, and sequence diagrams do not specify what the conditions on the ability of an object to perform actions are  E.g., an object may be in a state where it cannot perform a certain service Statechart diagrams model an object’s behavior:  Show states of the object  Show transitions between the states, including  Guards --- conditions on when the transition can take place  Events --- what causes the transition  Side-effects --- events produced as a result of the transition

53. Example: statechart diagram for PlannedTask object of Scheduler, v0.1.0

54. Suggestions for improvement? Does a task enter a special state when it is timed?  Yes.

55. Example: statechart diagram for PlannedTask object of Scheduler, v0.1.1

56. Suggestions for improvement? Does a task enter a special state when it becomes current?  No, because a task can be timed and current at the same time  Also, completed and current, incomplete and current, etc. Still, there is a way to represent the task being in two states at the same time  The two states are hierarchically composed – one contains the other State 1 State 2

57. Example: statechart diagram for PlannedTask object of Scheduler, v0.1.2

58. Example: statechart diagram for PlannedTask object of Scheduler, v0.1.3

59. A big step: from analysis to design Analysis  Goals:  Understand the system to be built  Map out the general functionality  Reach agreement with users  The system is looked at from the users’ point of view Design  Goal:  Map the functionality of the analysis model onto concepts that can be implemented  The system is looked at from the developers’ point of view The transition from analysis to design is not trivial!

60. Design stages System (or high-level or architectural) design  Decomposes the system into parts that can be comfortably designed in separation  Designs interfaces for interactions between subsystems Object (or low-level) design  Designs objects for each subsystem

61. End products of system design A list of design goals  The specific non-functional qualities that the system must have  E.g. performance characteristics  Often deals with trade-offs, e.g. space for time Software architecture  Decomposition into subsystems  Including dependencies among them and control flow  Mapping of the system onto hardware  Access control  Data storage issues

62. System design issues Hardware/software mapping  What part of the system resides where Data management  Dealing with persistent data Access control  Security issues Control flow  The type of control flow in the system  Multithreading Boundary conditions  Handling of exceptional situations (on the system level)  Initialization and shutdown

63. Subsystems Why do we need them?  To reduce the complexity of the system --- divide-and-conquer  To enable concurrent development  Several groups working in parallel on different subsystems How many subsystems do I need?  Totally depends on the system

64. Two alternative ways of decomposing systems Top-down  Produce subsystems that logically map onto the general functionality (use case model) of the system  Fit the analysis classes into this model  Don’t need to fit in all of them Bottom-up  Analyze the object diagram and separate it into subsystems to limit the degree of coupling between subsystems and increase the degree of coherence within subsystems In reality, somewhere in between  And iterative…

65. Reminder: Use case diagram for Scheduler

66. Example: top-down subsystem decomposition for Scheduler DayPlan – manages the list of tasks for the current date PersistentStorage – persistently stores all tasks Editing – deals with modifying the list of tasks for the current date PerformanceView – computes and displays performance characteristics Timing – handles timing tasks