System Decomposition PDF

System Decomposition SE3352 - by Shaimaa Ali, PhD 1  Requirements The objective Elicitation Implementation & Analysis...

System Decomposition SE3352 - by Shaimaa Ali, PhD 1  Requirements The objective Elicitation Implementation & Analysis & testing Real System Computerized System of SE System & Object Very specific, Vaguely / Design written in ambiguously programming described in plain language human language SE3352 - by Shaimaa Ali, PhD 2  What Verify it’s needs to doing Requirement be done? what it is Elicitation supposed to Testing Analysis Software Development Life Cycle Do it. (SDLC) Implementation System Design Object Design How would it be done? SE3352 - by Shaimaa Ali, PhD 3  Software Lifecycle Activities...and their models Requirements System Detailed Implemen- Analysis Testing Elicitation Design Design tation Implemented by Expressed in Structured Realized by Verified terms of by By class... class... ? class... ? class.... Use Case Application Solution Domain Sub- Source Test Model Domain Objects systems Code Cases Objects Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 4  Software Lifecycle Activities...and their models Requirements System Detailed Implemen- Analysis Testing Elicitation Design Design tation Implemented by Expressed in Structured Realized by Verified terms of by By class... class... ? class... ? class.... Use Case Application Solution Domain Sub- Source Test Model Domain Objects systems Code Cases Objects Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 5  Activities:  Identify design goals  Identify and prioritize the qualities of the system that they should optimize. System Design  Design the initial subsystem decomposition. Transformation of an  Decompose the system into smaller parts based on the use case and analysis models. analysis model into a  Developers use standard architectural styles as a starting point system design model. during this activity.  Refine the subsystem decomposition to address the design goals.  The initial decomposition usually does not satisfy all design goals. Developers refine it until all goals are satisfied. SE3352 - by Shaimaa Ali, PhD 6 SE3352 - by Shaimaa Ali, PhD 7 Designing a Residential House Analogy SE3352 - by Shaimaa Ali, PhD 8   After agreeing with the client on the number of rooms and floors, the size of the living area, and the location of the house.  The architect must design the floor plan, that is, where the walls, doors, and windows should be located.  The design must be done according to some functional requirements: Designing a  the kitchen should be close to the dining room and the garage, residential  the bathroom should be close to the bedrooms  … etc. house  The architect can also rely on some standards when establishing the dimensions of each room and the location of the door:  kitchen cabinets come in fixed increments and  beds come in standard sizes.  The architect does not need to know the exact contents of each room and the layout of the furniture. SE3352 - by Shaimaa Ali, PhD 9  We set out to satisfy the following constraints: 1. This house should have two bedrooms, a study, a kitchen, and a living/dining room area. 2. The overall distance the occupants walk every day should be minimized. 3. The use of daylight should be maximized. Designing a residential To satisfy the above constraints, we assume that: house  Most of the walking will be done  between the entrance door and the kitchen, when groceries are unloaded from the car,  between the kitchen and the living/dining area, when dishes are carried before and after the meals.  from the bedrooms to the bathrooms.  The occupants of the house will spend most of their time in the living/dining area and in the master bedroom. SE3352 - by Shaimaa Ali, PhD 10 Designing a residential house  In the first version of our floor plan, we find that the dining room is too far from the kitchen.  To address this problem, we exchange it with bedroom 2 (see gray arrows).  In the second revision, we find that the kitchen and the stairs are too far from the entrance door.  To address this problem, we move the entrance door to the north wall.  This allows us to reorient bedroom 2 and move the bathroom closer to both bedrooms.  The living area is increased, and we satisfied all original constraints. SE3352 - by Shaimaa Ali, PhD 11 Designing a residential house  In the first version of our floor plan, we find that the dining room is too far from the kitchen.  To address this problem, we exchange it with bedroom 2 (see gray arrows).  In the second revision, we find that the kitchen and the stairs are too far from the entrance door.  To address this problem, we move the entrance door to the north wall. At this point, we can position the doors and the windows of  This allows us to reorient bedroom 2 and move the bathroom closer to both bedrooms.each room to meet localized requirements.  The living area is increased, and weOnce this satisfied is done, we have completed the design without all original constraints. detailed knowledge of the layout of each individual room. Plans for plumbing, electrical lines, and heating ducts can proceed. SE3352 - by Shaimaa Ali, PhD 12 The design of a floor plan in architecture is similar to system design in software engineering. The whole is divided into simpler components and interfaces, while taking into account non- functional and functional requirements. SE3352 - by Shaimaa Ali, PhD 13 System Design Concepts SE3352 - by Shaimaa Ali, PhD 14 Subsystems SE3352 - by Shaimaa Ali, PhD 15  To reduce the complexity of the solution domain, we decompose a system into simpler parts, called “subsystems,” which are made of a number of solution domain classes.  Concurrent teams can work on individual subsystems with minimal communication overhead.  In the case of complex subsystems, we recursively apply this Subsystems principle and decompose a subsystem into simpler subsystems SE3352 - by Shaimaa Ali, PhD 16   A replaceable part of the system with well-defined interfaces that A Subsystem encapsulates the state and behavior of its contained classes.  Drawn in UML as rectangles with component icon with in a ‘Components Diagram’ SE3352 - by Shaimaa Ali, PhD 17 UML Component Diagram SE3352 - by Shaimaa Ali, PhD 18 UML Component Diagram SE3352 - by Shaimaa Ali, PhD 19 Services and Subsystem Interfaces SE3352 - by Shaimaa Ali, PhD 20   A service is a set of related operations that share a common purpose.  A subsystem is characterized by the services it provides to other subsystems.  A subsystem providing a notification service, for example, Services & defines operations to send notices, look up notification channels, and subscribe and unsubscribe to a channel. Interfaces  The subsystem interface includes the name of the operations, their parameters, their types, and their return values. SE3352 - by Shaimaa Ali, PhD 21   System design focuses on defining the services provided by each subsystem, that is, enumerating the operations, their parameters, and their high-level behavior. Services & Interfaces  Object design focuses on the application programmer interface (API), which refines and extends the subsystem interfaces. SE3352 - by Shaimaa Ali, PhD 22  Provided and required interfaces can be depicted in UML with assembly connectors, also called ball-and-socket connectors.  The provided interface is shown as a ball icon (also called lollipop) with its name next to it.  A required interface is shown as a socket icon.  The dependency between two subsystems is shown by Component connecting the corresponding ball and socket in the Interfaces component diagram. (required vs. provided) SE3352 - by Shaimaa Ali, PhD 23 SE3352 - by Shaimaa Ali, PhD 24 During the early stages of system design, we may not have such a clear understanding of the allocation of functionality to subsystems, in which case we use the dependency notation (dashed arrows) SE3352 - by Shaimaa Ali, PhD 25 Coupling and Cohesion SE3352 - by Shaimaa Ali, PhD 26   Coupling is the number of dependencies between two subsystems.  If two subsystems are loosely coupled, they are relatively independent, so modifications to one of the subsystems will have little impact on the other.  If two subsystems are strongly coupled, Coupling modifications to one subsystem is likely to have impact on the other.  A desirable property of a subsystem decomposition is that subsystems are as loosely coupled as reasonable. This minimizes the impact that errors or future changes in one subsystem have on other subsystems. SE3352 - by Shaimaa Ali, PhD 27  Low/Loose Coupling Coupling High/Tight Coupling SE3352 - by Shaimaa Ali, PhD 28  Low/Loose Coupling Coupling An objective of a good design is to minimize the coupling High/Tight Coupling SE3352 - by Shaimaa Ali, PhD 29  High dependency on the database (high-coupling) Coupling lower dependency on the database (lower-coupling) SE3352 - by Shaimaa Ali, PhD 30   Cohesion is the number of dependencies within a subsystem.  If a subsystem contains many objects that are related to each other and perform similar tasks, its Cohesion cohesion is high.  If subsystem contains a number of unrelated objects, its cohesion is low.  A desirable property of a subsystem decomposition is that it leads to subsystems with high cohesion. SE3352 - by Shaimaa Ali, PhD 31  High Cohesion Cohesion  A good design maximizes the cohesion Low Cohesion SE3352 - by Shaimaa Ali, PhD 32 Cohesion (Low cohesion example) SE3352 - by Shaimaa Ali, PhD 33 Cohesion (higher cohesion example) SE3352 - by Shaimaa Ali, PhD 34