ECEN5053 University of ColoradoSoftware Engineering of Distributed SystemsDesign IssuesI. Role of Use CasesA. Requirements model -- functional requirements defined in terms of actors and use cases in a narrative description.B. Analysis model -- use case is refined to describe objects that participate in the use case and their interactions (CRC cards, for example)C. Design model -- software architecture developed addressing issues of concurrency, information hiding, etc. Use cases are used to verify the design models.Combined collaboration diagrams can be used to discover all associations between classes in an initial class diagram.II. Role of Test CasesA. Create test cases by selecting sets of values to test use cases1. Need multiple test cases for success scenario as well as alternative flows and error flows.2. Based on test case value criteria such as boundary conditions, equivalenceclasses, etc.B. Use these to test models developed in analysis and designC. Use these for basis of increment testing and system testingIII. Requirements ModelsA. Define functional requirements in terms of narrative use cases and actors.1. Requirements for certain functionality to be provided remotely should be made explicit. Otherwise the distribution of functionality is a design choice.B. Based on elicitation information, clarify quality attribute requirements also.C. A throwaway prototype of some kind may be another useful model.D. Domain model 1. Describes main real-world objects and relationships relevant to this application2. May also include additional objects that are needed for understanding the domain3. Distributed nature of the real world does not necessarily suggest which items will be remote and which will be local in the design solution.IV. Analysis Models -- emphasis on problem domainA. Static Models1. Structural relationships among domain classes2. Class and relationships depicted in a class diagrama. Subject objects to object structuring criteriaB. Dynamic Models1. Use cases are refined a. To show objects that participate in each use case b. How they interact with each other2. Notation used -- either (these are equivalent)a. Sequence diagramsb. Collaboration diagrams2/2003 from Designing Concurrent, Distributed, and Real-Time Applications with UML 1by Hassan Gomaa, Addison Wesley, ISBN 0-201-65793-7ECEN5053 University of ColoradoV. Design Models -- emphasis on solution domainA. Software architecture designed1. Map the analysis models to an operational environment2. Apply subsystem structuring criteria clarifying interfacesa. Consider subsystems as aggregate or composite objectsb. If concurrent in a single CPU, shared memory environment, must allocate subsystems as configurable components (programs) that communicate probably via shared data, possibly via messages (both shared data and message formats are interfaces that are external to thesubsystem)B. Design the subsystems1. Sequential ones -- emphasize information hiding, classes, inheritance2. Concurrent ones -- also emphasize concurrent tasking and interfacesC. Note: If use cases are prioritized in the requirements stage, incremental development work can proceed when the relevant subsystems are designed.1. Mapping the System Sequence Diagrams to subsystem (component) sequence diagrams (rather than classes within subsystems) 2. Mapping to Sequence Diagrams (indicating classes within the subsystem) VI. Incremental Software ConstructionA. Based on approved functional prioritiesB. Select subset of system to be constructed for each increment1. Choose uses cases to be implemented in the increment2. Identify the objects that participate in those use casesC. Steps of an increment1. Confirm requirements and models that support selected use cases2. Detailed design 3. Review for consistency with models/use cases and quality attributes4. Code5. Unit testing6. Integration testing -- test new functionality based on use cases -- a. Emphasis on interface verificationb. Responsibility of development team because of importance of maintaining consistency of subsystem interfaces7. System testing -- not done by development teama. When enough functionality is implemented to test from “outside” the system -- should be early increments if system use cases are implementedb. Regression testing on previous use cases from prior incrementsc. Regression testing on previous release’s functionality, if anyd. Test cases can be those created earlier in development to test models; plus additional test cases deemed appropriate.e. If this can be done at the end of each increment, resulting time to fix bugs has been shown to be the fastest vs. other times when system testing can be performed. That is, minimizing the time from bug insertion to bug detection and correction reduces impact on 2/2003 from Designing Concurrent, Distributed, and Real-Time Applications with UML 2by Hassan Gomaa, Addison Wesley, ISBN 0-201-65793-7ECEN5053 University of Coloradodevelopment team’s overall time spent correcting bugs vs. implementing new functionality.f. Adequate test coverage -- see McGregor & SykesVII. Multiprogramming considerations in Use Case ModelingA. Actors may be other programs including legacy systems that are now going to be part of a multiprogram system, external devices, a timer, etc. (If a human uses an external device in order to interact with the system, the human is the actor, not the external device such as a keyboard.)B. In a periodic use case, a timer triggers the use case’s activity and is therefore an actorC. Especially important to give careful thought to the stated preconditions and postconditions which will be refined when the use case is implemented1. Needed to prove desirable attributes associated with mutual exclusion2. May not know which subsystem the functionality will be assigned to until architecture defined D. In large or multiprogram systems, there can be a large number of use cases causing the model to become unwieldy.1. Group use cases in use case packages2. A use case package can represent high-level requirements that address major subsets of the functionality of the system3. Sometimes appropriate to group use case packages by the primary actor that uses them (Operator use cases; Field tech use cases; etc.)VIII. Multiprogramming considerations in Analysis ModelingA. Relationships1. Association is a relationship between two classes that is static and