1 / 66

Example: object diagram for Scheduler, v0.0.0

Example: object diagram for Scheduler, v0.0.0. 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.

tien
Télécharger la présentation

Example: object diagram for Scheduler, v0.0.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Can be omitted 1 TaskList * Task 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

  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 1 Object 2 Object 3 message1 message2 message3

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

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

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

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

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

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

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

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

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

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

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

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

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

  32. 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

More Related