3-System Design_software_design_algo .pptx

3-System Design_software_design_algo .pptx

• 1.
  System Design By Dr.Maryam Kausar
• 2.
  Why is Designso Difficult? • Analysis: Focuses on the application domain • Design: Focuses on the solution domain • The solution domain is changing very rapidly • Halftime knowledge in software engineering: About 3-5 years • Cost of hardware rapidly sinking Design knowledge is a moving target • Design window: Time in which design decisions have to be made.
• 3.
  The Scope ofSystem Design • Bridge the gap • between a problem and an existing system in a manageable way Problem Existing System System Design • How? • Use Divide & Conquer: 1) Identify design goals 2) Model the new system design as a set of subsystems 3) Address the major design goals.
• 4.
  System Design • Asystem is decomposed into subsystems. • System Decomposed: • A subsystem provides a set of services to the system. • A set of related operations that share a common purpose • The set of services available to other systems form the subsystem interface • System design focuses on defining services 1-4
• 5.
  1-5
• 6.
  Activity • System Designof Café Management System 1-6
• 7.
  Analysis Sources: Requirements andSystem Model 1-7
• 8.
  How the AnalysisModels influence System Design • Nonfunctional Requirements => Definition of Design Goals • Functional model => Subsystem Decomposition • Object model => Hardware/Software Mapping, Persistent Data Management • Dynamic model => Identification of Concurrency, Global Resource Handling, Software Control • Finally: Hardware/Software Mapping => Boundary conditions
• 9.
  1-9
• 10.
  Example of DesignGoals • Reliability • Modifiability • Maintainability • Understandability • Adaptability • Reusability • Efficiency • Portability • Traceability of requirements • Fault tolerance • Backward-compatibility • Cost-effectiveness • Robustness • High-performance  Good documentation  Well-defined interfaces  User-friendliness  Reuse of components  Rapid development  Minimum number of errors  Readability  Ease of learning  Ease of remembering  Ease of use  Increased productivity  Low-cost  Flexibility
• 12.
  Typical Design Trade-offs •Functionality v. Usability • Is a system with 100 functions usable? How about a large scale menu? • Cost v. Robustness • A low cost system does not check for errors when the user is entering wrong data • Efficiency v. Portability • Can you build a portable real-time game? How do you get high frame rates. Special graphics routines that access the display buffer! That is usually not portable. •
• 13.
  Typical Design Trade-offs •Rapid development v. Functionality • Let’s say your development time is 5 weeks, you have 5 programmers, your design window is 2 weeks, after design 3 programmers are leaving your company, and your delivery deadline cannot be moved. You are going to reduce the functionality. • Cost v. Reusability • Nowadays, with design patterns, this trade-off is changing a little bit. You can get reusability pretty cheap if you use design patterns! • Backward Compatibility v. Readability • Nowadays, again with the use of design patterns, for example, the bridge pattern, you can keep a system backward compatible and still keep it readable 1-13
• 14.
  Subsystem Decomposition • Subsystem •Collection of classes, associations, operations, events and constraints that are closely interrelated with each other • The objects and classes from the object model are the “seeds” for the subsystems • In UML subsystems are modeled as packages • Service • A set of named operations that share a common purpose • The origin (“seed”) for services are the use cases from the functional model • Services are defined during system design.
• 16.
  Properties of Subsystems: Layersand Partitions • A layer is a subsystem that provides a service to another subsystem with the following restrictions: • A layer only depends on services from lower layers • A layer has no knowledge of higher layers • A layer can be divided horizontally into several independent subsystems called partitions • Partitions provide services to other partitions on the same layer • Partitions are also called “weakly coupled” subsystems.
• 17.
  Relationships between Subsystems • Twomajor types of Layer relationships • Layer A “depends on” Layer B (compile time dependency) • Example: Build dependencies (make, ant, maven) • Layer A “calls” Layer B (runtime dependency) • Example: A web browser calls a web server • Can the client and server layers run on the same machine? • Yes, they are layers, not processor nodes • Mapping of layers to processors is decided during the Software/hardware mapping! • Partition relationship • The subsystems have mutual knowledge about each other • A calls services in B; B calls services in A (Peer-to-Peer) • UML convention: • Runtime dependencies are associations with dashed lines • Compile time dependencies are associations with solid lines.
• 18.
  Example of aSubsystem Decomposition
• 19.
  Tournament Component Management User Management Tournament Statistics User Directory UserInterface Session Management Advertisement ARENA Subsystem Decomposition
• 20.
  Example of aBad Subsystem Decomposition Advertisement User Interface Session Management User Management Tournament Statistics Component Management Tournament
• 21.
  Activity • Make Subsystemdiagram for Café Management System. 1-21
• 22.
  Project • Group 1:Abstract Factory, Adaptor, Bridge, Chain of Responsibility • Group 2: Builder, Composite, Decorator, Interpreter • Group 3: Factory Method, Façade, Flyweight, Mediator • Group 4: Prototype ,Proxy, Observer, State • Group 5: Singleton, Strategy, Template Method, Interpreter • Group 6: Abstract Factory, Adaptor, Iterator, Command • Group 7: Builder, Composite, Memento, Visitor • Group 8: Prototype ,Proxy, Template Method , State • Group 9: Singleton, Strategy, Bridge, Chain of Responsibility • Group 10: Factory Method, Proxy, Template Method, Mediator • Group 11: Builder, Adaptor, Observer ,Flyweight • Group 12: Composite, Decorator, Iterator, Command • Group 13: Façade, Flyweight, Proxy, Command • Group 14: Builder, Strategy, Adaptor, Chain of Responsibility • Group 15: Abstract Factory, Factory Method, Iterator, Command