1 / 50

Reminder: Use case diagram for Scheduler

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

nirav
Download Presentation

Reminder: Use case diagram for Scheduler

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Reminder: Use case diagram for Scheduler

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

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

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

  5. Performance view Timing Editing DayPlan Persistent storage Example: top-down subsystem decomposition for Scheduler, v0.1.0a (cont.)

  6. TaskSubsystem Performance View Timing Editing DayPlan CalendarSubsystem Persistent Storage Example: bottom-up subsystem decomposition for Scheduler, v0.1.0b

  7. Example: subsystem decomposition for Scheduler, v0.1.0

  8. So, which way is better? Bottom-up Top-down

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

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

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

  12. Layered architectural style

  13. Repository architectural style

  14. Model-view-controller architectural style

  15. Server-client architectural style

  16. Pipe-and-filter architectural style

  17. Is the top-down Scheduler architecture of any specific architectural style? Layered? Repository? Model-view-controller?

  18. Is the bottom-up Scheduler architecture of any specific architectural style? Model-view-controller? Layered? Repository?

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

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

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

  22. Example: deployment diagram for Scheduler-on-steroids

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

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

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

  26. Are these goals good? • Is he kidding? • Yes, he is • Goals that cannot be achieved are no good

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

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

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

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

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

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

  33. 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?

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

  35. Are we done with the system design?

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

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

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

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

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

  41. 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)

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

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

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

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

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

  47. Example:Timing subsystem of Scheduler, v0.1.0

  48. Example:Task subsystem of Scheduler, v0.1.0

  49. Example:Calendar subsystem of Scheduler, v0.1.0

  50. Example:PersistentStorage subsystem of Scheduler, v0.1.0

More Related