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

Example: object diagram for Scheduler, v0.0.1

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 CurrentTaskSo, cannot use inheritance

It seems to be in a relationship with TaskList

TaskList contains a CurrentTask

Cardinality of associations in object diagramsIt is often useful to specify how many

objects can participate in an associationE.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

TaskList Task1 *

Can be omitted

Example: object diagram for Scheduler, v0.0.2

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, orCan change the inheritance hierarchy and

introduce a task type that both Task and UnplannedTask inherit from

This is what we are going to do

Example: object diagram for Scheduler, v0.0.3

Example: object diagram for Scheduler, v0.0.5

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

Example: object diagram for Scheduler, v0.0.12

Are Time and TimePeriod important enough to stay separate classes?Have an alternative for Time and

TimePeriodLeave them as separate classes

Represent important user-level conceptsSince they are only used by Task, consider

them attributes of Task, not separate classes

Makes the diagram smaller and higher-level

Select this option

Example: object diagram for Scheduler, v0.0.13

Putting in control objects

Do not have to do itIn many cases, clutter the diagram without

adding much valueMay be helpful if the way in which they

use entity and boundary objects is non-trivial

Example: object diagram for Scheduler, v0.0.15

Example: object diagram for Scheduler, v0.0.16

Showing dynamic interactions between objects using sequence diagramsUse cases are not precise about

interactionsSay what needs to be done, but not

What objects are involvedWho 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 andThe participating objects

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This diagram does not satisfy the use case timeTask!This use case says:

Preconditions: No task is being timedNormal 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

This diagram does not satisfy the use case timeTask!This use case says:

Preconditions: No task is being timedNormal 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

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

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

Example: object diagram for Scheduler, v0.0.17

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

Let’s compare it against the chooseDate use caseThis use case says:

Preconditions: no tasks are being created, notified, or timedNormal 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

Let’s compare it against the chooseDate use caseThis use case says:

Preconditions: no tasks are being created, notified, or timedNormal 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

Who is right?

The use case says that the user first changes the date and then confirms the change

Two explicit stepsThe sequence diagram says only that

the user enters the new dateImplies one step

There may be different ways to design the GUI for the date change

The use case is probably too specificWe will change the use case

New use case chooseDate, v0.1.0

Preconditions: no tasks are being created, notified, or timedNormal Flow:

(1) The user requests the date change through the GUIAlternate 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

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 timedNormal Flow:

(1) The user requests the date change through the GUIAlternate 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

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

The activity of displaying a new date is missing from this diagramBecause 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

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

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

Example: object diagram for Scheduler, v0.1.1

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

Modeling dynamic behavior of a single object with statechart diagramsUse 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 objectShow transitions between the states,

includingGuards --- conditions on when the

transition can take placeEvents --- what causes the transitionSide-effects --- events produced as a

result of the transition

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

Suggestions for improvement?

Does a task enter a special state when it is timed?

Yes.

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

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

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

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

A big step: from analysis to design

Analysis Goals:

Understand the system to be builtMap out the general functionalityReach 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!

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) designDesigns objects for each subsystem

End products of system design

A list of design goalsThe specific non-functional qualities that

the system must haveE.g. performance characteristicsOften deals with trade-offs, e.g. space

for timeSoftware architecture

Decomposition into subsystemsIncluding dependencies among them

and control flowMapping of the system onto hardwareAccess controlData storage issues

System design issues

Hardware/software mappingWhat part of the system resides where

Data managementDealing with persistent data

Access controlSecurity issues

Control flowThe type of control flow in the systemMultithreading

Boundary conditionsHandling of exceptional situations (on the

system level)Initialization and shutdown

Subsystems

Why do we need them?To reduce the complexity of the system ---

divide-and-conquerTo enable concurrent development

Several groups working in parallel on different subsystems

How many subsystems do I need?Totally depends on the system

Two alternative ways of decomposing systemsTop-down

Produce subsystems that logically map onto the general functionality (use case model) of the system

Fit the analysis classes into this modelDon’t need to fit in all of them

Bottom-upAnalyze 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 betweenAnd iterative…

Reminder: Use case diagram for Scheduler

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