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

Is this decomposition any good?

How can we tell without trying to map the analysis objects on it?

But why should we use analysis objects if this is a design diagram?

We have to start somewhereAnalysis objects present break-down of the

functionality of the system

Reminder: object diagram (entity objects only) for the Scheduler

Example: top-down subsystem decomposition for Scheduler, v0.1.0a (cont.)

Editing

DayPlan

TimingPerformanceview

Persistentstorage

Example: bottom-up subsystem decomposition for Scheduler, v0.1.0b

TaskSubsystemTiming Performance

View

PersistentStorage

DayPlan CalendarSubsystem

Editing

Example: subsystem decomposition for Scheduler, v0.1.0

So, which way is better?

Top-down

Bottom-up

So, which way is better?

Combination of bothE.g.

Top-down decomposition into subsystems

Map analysis objects to subsystemsIterate

•Split some subsystems•Create additional subsystems

What do we do for really complicated systemsProblem: the number of subsystems

may be too largeSolution1: hierarchical decomposition

(subsystems inside other subsystems)Solution2: architectural styles

Architectural styles

Architectural patternA common type of architectures that is well

understoodE.g. server-client

Normally, these are simple and can be illustrated with just a couple of packages

In reality, a number of packages may need to be used in place of one

Multiple architectural styles used on different levels for the same system

Layered architectural style

Repository architectural style

Model-view-controller architectural style

Server-client architectural style

Pipe-and-filter architectural style

Is the top-down Scheduler architecture of any specific architectural style?

Repository?

Model-view-controller?

Layered?

Is the bottom-up Scheduler architecture of any specific architectural style?

Layered? Repository? Model-view-controller?

Hardware/software mapping: deployment diagramsShow the relationship between

hardware components and software run-time components

Software run-time components are not subsystems!

A component can be composed of several subsystems

Users’ requirements must be used to determine the hardware components

In most cases, this step is fairly easy

Deployment diagram notation

myPC:LinuxHardware component

Software componentStuff:database

Dependency relationship (origin depends on destination)

Scheduler-on-steroids

A beefed-up version of SchedulerData for all group members and all groups

stored centrallyGroup members and managers have to log

in using passwordManagers can view performance per group,

department, etc.

Example: deployment diagram for Scheduler-on-steroids

Design goals

Wait, don’t we have requirements to give us the goals?

In many cases, these are too generalAt the design stage, we can actually do

something about these requirementsE.g., decide where performance

bottlenecks areHardware/software mapping provides

additional concernsBut shouldn’t we do this before

dividing the system into subsystems?No, after we defined subsystems and

hardware/software mapping, we can see where the bottlenecks are

Types of design goals

PerformanceResponse time, memory requirements, etc.

DependabilityRobustness, availability, fault tolerance,

safetySecurityCost factors

Development, deployment, upgrade, maintenance, administration costs

Maintenance factorsExtensibility, modifiability, portability,

understandabilityEnd user factors

Utility and usability

Example: design goals for Scheduler-on-steroidsResponse time should be faster than

the monitor refresh rateShould use so little memory that the

whole RAM sector goes bust in 2 months

More dependable than AirForce 1Security so unbreakable that it detects

intrusion on computers not connected to the ones running it

So portable that you can run it on your wristwatch

Using the system is more natural than breathing

Are these goals good?

Is he kidding?Yes, he is

Goals that cannot be achieved are no good

Are design goals dependent on each other?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

Dealing with persistent data storage

Storing data persistently is often a bottleneck

Need to choose carefully what data needs to be persistent

Two major optionsFile system

One or more filesHierarchy

Database systemsRelationalObject-oriented

Example: persistent data storage in Scheduler-on-steroidsFile system is not an option

The volume of data may be highThere is a lot of sharing of data

E.g., a group member may access data concurrently with several managers

Should use a commercial database system

Use JDBC to connect the application with the database system

Access control

Different types of actors need to access different data

E.g., a group member cannot access performance characteristics of the group, but a manager can

Different instances of actors need to access different data

E.g., a group member cannot view tasks of another group member

Closely related to securityE.g., may need to know what types of

firewalls the servers runIn Scheduler-on-steroids, it even makes

sense to define AccessSubsystem

Security subsystem in Scheduler-on-steroidsWill screen all requests for dataDefines security clearance levels for

different peopleRequires login for everybodyFor group members, only allows access to

their own data, no timeoutFor group managers, also allows access to

the data of the group members, times outFor higher-level managers, allows access to

multiple (defined) groups, requires password for each access

Etc.Encrypts all data for transfers

Global control flow

Defines possible sequences of actions in the system

Three major types Procedural

Operations are carried out in a sequenceWhen a method is called, the caller waits for the

result before proceeding Multi-threaded

Multiple threads of procedural threads, operating in parallel• May communicate with each other, either synchronously

or asynchronously

Event-basedUpon receipt of an event, specific operations are

carried out

Combinations are possible

Boundary conditions

Exceptional conditionsWhat happens when something unexpected

takes place?E.g., a manager wants to view group

performance for a date in the futureUse cases help with some of this

Pre-conditionsAlternate flow

But additional exceptional conditions may be discovered on the design level

E.g., what if the server does not respond?

Boundary conditions (cont.)

Starting the systemInitializations

E.g., for Scheduler-on-steroids, loading tasks for the current date into cache for faster access

Networking stuff to get different hardware nodes talking

Shutting down the systemSaving data persistentlySaving the configuration

Often, identifying boundary conditions results in adding use cases to the use case diagram

And modifying other diagrams accordingly

Are we done with the system design?

The next step: defining interfaces of the subsystemsFirst will describe informally what

services subsystems need and provideThen will update the package diagramFinally, will do object design to provide

concrete interfaces

Informal interfaces for the subsystems of SchedulerTiming

ProvidesOperations of starting/stopping a single

timerA way to figure out if a timer is activeTime elapsed since the timer has been

startedNeeds

Only OS services

Informal interfaces for the subsystems of Scheduler (cont.)TaskSubsystem

ProvidesAbstractions of different kinds of tasks

•The ability to create a task, set and query its fields•Mark the task as (in)complete•Mark the task as (non-)current

NeedsAccess to the timer for timing tasks

Informal interfaces for the subsystems of Scheduler (cont.)Editing

ProvidesA GUI for editing the fields of a task

•Used in the activities of both editing and creating a task

NeedsAccess to the fields of a taskAn object that triggers editing

operations•E.g., opens an edit dialog and passes it a task

Informal interfaces for the subsystems of Scheduler (cont.)DayPlan

ProvidesComposition of multiple tasks into a list

of tasks for a specific dateCapabilities of inserting, deleting,

sorting tasks and updating their contents (e.g. after editing)

Visual components for displaying the list of tasks and controlling it

NeedsAccess to the task attributes and the

interface of Editing subsystem

Informal interfaces for the subsystems of Scheduler (cont.)CalendarSubsystem

ProvidesAbstractions of dates, ranges of dates,

points in time, and time periodsNeeds

Calendar utilities from standard libraries (java.util)

Informal interfaces for the subsystems of Scheduler (cont.)PersistentStorage

ProvidesThe abstraction of archive of all tasks,

for different dates•Has to hide the way in which the data in the

persistent storage are accessed

NeedsA representation of dates in order to

search the archive

Informal interfaces for the subsystems of Scheduler (cont.)PerformanceView

ProvidesData representations and algorithms for

various performance characteristics•Need to be set up in a general way, so that new

characteristics can be easily added

GUI for viewing these characteristicsNeeds

Access to tasks representing the periods that need to be characterized

Task attributes, for computing characteristics

Impact of informal subsystem interfaces on package diagramsInformal descriptions of system interfaces

help clarify the dependencies between subsystems

Can suggest combining several subsystems into one

If the provides-needs relationships of the two subsystems have a lot of overlap

Can suggest splitting a subsystem into several

If the provides relationship suggests that the provided functionality can be naturally decomposed

Can suggest additional subsystemsIf some high-level functionality is not reflected

in the provides relationships

Using off-the-shelf (OTS) components

Off-the-shelf components refer to industrial-strength reusable component libraries

Whenever possible, have to use them Generally these are high quality

ReliabilityPerformance

It’s all about reuse Sometimes, unappropriate

May be too cumbersome to reconcile the differences in functionality

OTS components are written in a general way, so performance may suffer

Usually, investment in OTSs is well worth it Identifying OTSs is both system design and

object-level design activity

Example: OTS components for Scheduler

Many GUI components are neededIt would be wasteful to code those from

ground upWill use Swing (Java light-weight GUI

library)Storing data persistently is required

Will use the serializability feature of JavaPart of the IO framework

Example:Timing subsystem of Scheduler, v0.1.0

Example:Task subsystem of Scheduler, v0.1.0

Example:Calendar subsystem of Scheduler, v0.1.0

Example:PersistentStorage subsystem of Scheduler, v0.1.0