Download
1 / 50
630 likes | 1.16k Vues
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
E N D
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 somewhere • Analysis objects present break-down of the functionality of the system
Reminder: object diagram (entity objects only) for the Scheduler
Performance view Timing Editing DayPlan Persistent storage Example: top-down subsystem decomposition for Scheduler, v0.1.0a (cont.)
TaskSubsystem Performance View Timing Editing DayPlan CalendarSubsystem Persistent Storage Example: bottom-up subsystem decomposition for Scheduler, v0.1.0b
So, which way is better? Bottom-up Top-down
So, which way is better? • Combination of both • E.g. • Top-down decomposition into subsystems • Map analysis objects to subsystems • Iterate • Split some subsystems • Create additional subsystems
What do we do for really complicated systems • Problem: the number of subsystems may be too large • Solution1: hierarchical decomposition (subsystems inside other subsystems) • Solution2: architectural styles
Architectural styles • Architectural pattern • A common type of architectures that is well understood • E.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
Is the top-down Scheduler architecture of any specific architectural style? Layered? Repository? Model-view-controller?
Is the bottom-up Scheduler architecture of any specific architectural style? Model-view-controller? Layered? Repository?
Hardware/software mapping: deployment diagrams • Show 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
myPC:Linux Hardware component Stuff:database Software component Dependency relationship (origin depends on destination) Deployment diagram notation
Scheduler-on-steroids • A beefed-up version of Scheduler • Data for all group members and all groups stored centrally • Group members and managers have to log in using password • Managers can view performance per group, department, etc.
Design goals • Wait, don’t we have requirements to give us the goals? • In many cases, these are too general • At the design stage, we can actually do something about these requirements • E.g., decide where performance bottlenecks are • Hardware/software mapping provides additional concerns • But 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 • Performance • Response time, memory requirements, etc. • Dependability • Robustness, availability, fault tolerance, safety • Security • Cost factors • Development, deployment, upgrade, maintenance, administration costs • Maintenance factors • Extensibility, modifiability, portability, understandability • End user factors • Utility and usability
Example: design goals for Scheduler-on-steroids • Response time should be faster than the monitor refresh rate • Should use so little memory that the whole RAM sector goes bust in 2 months • More dependable than AirForce 1 • Security 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 options • File system • One or more files • Hierarchy • Database systems • Relational • Object-oriented
Example: persistent data storage in Scheduler-on-steroids • File system is not an option • The volume of data may be high • There 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 security • E.g., may need to know what types of firewalls the servers run • In Scheduler-on-steroids, it even makes sense to define AccessSubsystem
Security subsystem in Scheduler-on-steroids • Will screen all requests for data • Defines security clearance levels for different people • Requires login for everybody • For group members, only allows access to their own data, no timeout • For group managers, also allows access to the data of the group members, times out • For 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 sequence • When 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-based • Upon receipt of an event, specific operations are carried out • Combinations are possible
Boundary conditions • Exceptional conditions • What happens when something unexpected takes place? • E.g., a manager wants to view group performance for a date in the future • Use cases help with some of this • Pre-conditions • Alternate 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 system • Initializations • 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 system • Saving data persistently • Saving the configuration • Often, identifying boundary conditions results in adding use cases to the use case diagram • And modifying other diagrams accordingly
The next step: defining interfaces of the subsystems • First will describe informally what services subsystems need and provide • Then will update the package diagram • Finally, will do object design to provide concrete interfaces
Informal interfaces for the subsystems of Scheduler • Timing • Provides • Operations of starting/stopping a single timer • A way to figure out if a timer is active • Time elapsed since the timer has been started • Needs • Only OS services
Informal interfaces for the subsystems of Scheduler (cont.) • TaskSubsystem • Provides • Abstractions 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 • Needs • Access to the timer for timing tasks
Informal interfaces for the subsystems of Scheduler (cont.) • Editing • Provides • A GUI for editing the fields of a task • Used in the activities of both editing and creating a task • Needs • Access to the fields of a task • An 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 • Provides • Composition of multiple tasks into a list of tasks for a specific date • Capabilities of inserting, deleting, sorting tasks and updating their contents (e.g. after editing) • Visual components for displaying the list of tasks and controlling it • Needs • Access to the task attributes and the interface of Editing subsystem
Informal interfaces for the subsystems of Scheduler (cont.) • CalendarSubsystem • Provides • Abstractions of dates, ranges of dates, points in time, and time periods • Needs • Calendar utilities from standard libraries (java.util)
Informal interfaces for the subsystems of Scheduler (cont.) • PersistentStorage • Provides • The abstraction of archive of all tasks, for different dates • Has to hide the way in which the data in the persistent storage are accessed • Needs • A representation of dates in order to search the archive
Informal interfaces for the subsystems of Scheduler (cont.) • PerformanceView • Provides • Data 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 characteristics • Needs • Access to tasks representing the periods that need to be characterized • Task attributes, for computing characteristics
Impact of informal subsystem interfaces on package diagrams • Informal 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 subsystems • If 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 • Reliability • Performance • 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 needed • It would be wasteful to code those from ground up • Will use Swing (Java light-weight GUI library) • Storing data persistently is required • Will use the serializability feature of Java • Part of the IO framework
