Upload
sharlene-jacobs
View
234
Download
0
Tags:
Embed Size (px)
Citation preview
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