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 somewhere  Analysis 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 Timing Performance view Persistent storage

Example: bottom-up subsystem decomposition for Scheduler, v0.1.0b TaskSubsystem TimingPerformance View Persistent Storage 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 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

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

Deployment diagram notation myPC:Linux Hardware component Software component Stuff:database Dependency relationship (origin depends on destination)

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.

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

Are we done with the system design?

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

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