Unified Software Process Requirements Analysis Software Design Elaboration

Unified Software Process Requirements Analysis & Software Design (Elaboration) CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science October 7, 2005 February 9, 2007 (c) Dr. David A. Workman

Overview of USP Requirements Elicitation (Definition) Use Case Model Requirements Elaboaration (OO-Analysis) Analysis Model The process of defining and modeling the Problem Space Object-Oriented Design & Deployment Models February 9, 2007 Problem Statement & User Needs The process of defining and modeling the Solution Space Object-Oriented Implementation (Programming) (c) Dr. David A. Workman Mapping design to Implementation Space Code in an OOPL (Ada 95) (C++)(Java) Component Model 2

Overview of USP Birth Death Inception Itera- Iteration • • Elaboration Iteration Construction Iteration Arch. Design Refinement (Analysis Model) (Design Model) … Iteration Transition … Itera- Iteration Inception Elaboration ( focus on “Do-Ability” )(Architecture + high-fidelity cost est. ) – Develop detailed use cases (80% of use cases). – Develop a stable architectural view of the system using the Analysis Model, Design Model, Implementation Model, and Deployment Model. – Create a baseline system specification (SRS). – Produce the Software Development Plan (SDP) which describes the next phase. • • Construction Transition February 9, 2007 (c) Dr. David A. Workman 3

Requirements Elicitation vs Elaboration (USP) February 9, 2007 (c) Dr. David A. Workman 4

UML Process and Artifacts 2: Requirements Elaboration (Analysis & Specification) 1: Requirements Elicitation (Capture) Use Case Model State Chart Communication Diagram Model System/Gui behavior Model Use Case Flow Model Use Case External behavior Activity Diagram Use Case Diagram Software Requirements Spec Analysis Model Define System Boundary; Identify Actors And External Interfaces; Identify Use Cases Architecture Diagram Identify Packages their Interfaces & Relationships February 9, 2007 3: Software Design Software Development Plan Partition Software into Work packages. Estimate cost, resources, Size, and schedule. Define Internal View of System Identify Subsystems Identify Classes & Objects Allocate Functional Responsibilities Communication Diagram Class Diagram Model Use Case Internal behavior Identify Boundary, Control Entity Classes and their Relationships (c) Dr. David A. Workman 5

Requirements Elaboration • Purpose – – – • Identify the Analysis classes and/or subsystems whose instances are needed to perform the use case’s flow of interactions. Allocate the functional responsibilities of use cases to interacting objects and/or to participating subsystems. Define functional requirements for operations and encapsulated data of analysis classes and/or subsystems and their interfaces. Capture detailed design requirements for each use case. Prioritize use cases and subsystems for further development Plan the design and construction activites, estimate size, effort, schedule and cost. Identify Participating Analysis Classes For each use case, identify the problem data that enters and leaves the system via that use case. Identify the problem data that must persist within the system to support other use cases; this is data that must be shared by use cases related on the Use Case Diagram. Assign boundary classes to handle problem data crossing the system boundary. • Describe Analysis Object Interactions – – • Construct communication diagrams containing participating actors, analysis objects, and message transmissions among them. If necessary, create separate diagrams for distinct sub-flows determined by the same use case. A use case should be invoked by a message from an actor to an analysis object. Messages flowing between objects should be labeled with the action requested of the receiving object; these messages define the functional responsibilities of the receiving object. Support the collaboration diagram with narrative to clarify details. Artifacts of Analysis – – – Analysis Class Diagrams (UML) – static architectural design Activity Diagram (UCM) – dynamic flow of use cases or sub- use cases Communication Diagrams (UML) – dynamic architectural design Statecharts/Diagrams (UML) – dynamic architectural design Use Case Coverage Table – architecture completeness; basis for integration and system testing February 9, 2007 (c) Dr. David A. Workman 6

Requirements Analysis & Specification • Inputs – Outputs from Requirements Elicitation ( Use Case Model ). – Technical documents or expertise relevant to problem domain, in general, and to the Client's problem, in particular. • Activities Refine requirements by eliminating inconsistencies and ambiguities. Formalize requirements by preparing a System Requirements Specification. Develop an initial software development plan. • Outputs – Software Requirements Specification (SRS)(Analysis Model) • • UML Use Case Specifications UML Activity Diagram for Use Case flow UML Class Model UML Communication and Sequence Diagrams UML State Diagrams Problem Glossary Other info. – Software Development Plan (SDP) February 9, 2007 (c) Dr. David A. Workman 7

Use Case Coverage Table UC 1 UC 2 UCk UCn-1 UCn Class-1 Class-2 Data members & Methods Class-m • Columns are labeled by Use Cases. • Rows are labeled by Analysis Classes. • Table entries identify the attributes and operations of a particular class, identified by the row, needed to support the use case corresponding to the column. The union across the row should define all the attributes and operations needed for that class to support ALL use cases. The union down a column should identify all the classes (their attributes and operations) required to realize a given use case. February 9, 2007 (c) Dr. David A. Workman 8

Requirements Mapping Table UC 1 UC 2 UCk UCn-1 UCn Class-1 Functional Requirements Class-2 Class-m • Columns are labeled by Use Cases. • Rows are labeled by Analysis Classes. • Table entries identify the Requirements met by a given class (row) relative to a given use case (column). These requirements should be identified by number as specified in your Use Case Model. The union of all table entries should yield all functional requirements. If not, then something is missing. February 9, 2007 (c) Dr. David A. Workman 9

Software Requirements Specification 1 • Title • TOC 1. Introduction 1. 1 1. 2 1. 3 1. 4 1. 5 2. 3. 4. 5. • Purpose of this SRS. • Intended audience. • Identify the software product. • Enumerate what the system will and will not do. • Describe user classes and benefits to each. Purpose Scope Definitions. Acronyms, and Abbreviations References Overview Overall Description Specific Requirements Appendices Index This sections defines the vocabulary of the SRS. It may reference an appendix. Reference all documents and SMEs used to write the SRS. E. g. Use Case Model and Problem Statement; Experts in the field. • Describe the content of the rest of the SRS. • Describe how the SRS is organized. NOTES: Info. from the USDP Use Case Model maps into the above outline as follows. 1. 2 Scope should summarize the main concepts and details presented in the System Concept and Vision of the UCM. 1. 3 corresponds to the Glossary of the UCM. 1 February 9, 2007 (c) Dr. David A. Workman IEEE Std 830 -1998 10

Software Requirements Specification 1 • Title • TOC 1. Introduction • Present the business case and operational concept of the system. • Describe how the proposed system fits into the business context. • Describe external interfaces: system, user, hardware, software, comm. • Describe constraints: memory, operational, site adaptation. 2. Overall Description • Summarizes the major functional capabilities. • Include the Use Case Diagram and supporting narrative; identify actors and use cases. • A Data Flow Diagram may be appropriate. 2. 1 Product Perspective 2. 2 Product Functions Describes and justifies technical skills and capabilities of each user class. 2. 3 User Characteristics 2. 4 Constraints 2. 5 Assumptions and Dependencies 3. Specific Requirements 4. Appendices 5. Index Describes other constraints that will limit developer’s options; e. g. , PL, target platform, database, network software and protocols, development standards requirements. States assumptions about availability of certain resources that, if not satisfied, will alter system requirements and/or effect the design. 1 February 9, 2007 (c) Dr. David A. Workman IEEE Std 830 -1998 11

Software Requirements Specification Specifies software requirements in sufficient detail to enable designers to design to satisfy those requirements and testers to verify requirements. 3. 0 Specific Requirements 3. 1 External Interfaces 3. 2 Functions 3. 3 Performance Requirements 3. 4 Logical Database Requirements 3. 5 Design Constraints 3. 6 Software System Quality Attributes 3. 7 Object Oriented Models 3. 8 Implementation Issues 4. Appendices 5. Index February 9, 2007 Every stated requirement should be externally perceivable by users, operators, or externally connected systems. Requirements should include, at a minimum, a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output. (a) Requirements should be stated in conformance with section 4. 3 of this standard. (b) Requirements should be cross-ref’d to their source. (c) All requirements should be uniquely identifiable. (d) They should be organized to maximize readability. (c) Dr. David A. Workman 12

Software Requirements Specification Should detail description of all inputs and outputs, but should complement, not duplicate, information presented in section 5. 2. Examples: ( GUI screens, File formats) 3. 0 Specific Requirements 3. 1 External Interfaces Should include detailed specifications of each use case (analysis view) , including collaboration and other diagrams useful for this purpose. 3. 2 Functions 3. 3 Performance Requirements 3. 4 Logical Database Requirements 3. 5 Design Constraints 3. 6 Software System Quality Attributes 3. 7 Object Oriented Models 3. 8 Additional Comments • Index • Appendices February 9, 2007 Should include: (a) Types of information stored in DB (b) Data entities and their relationships (c) Performance requirements Should include: (a) Standards compliance (b) Accounting & Auditing procedures The main body of requirements organized in a variety of possible ways. (a) Architecture Specification (b) Class Diagram (c) State and Collaboration Diagrams (d) Activity Diagram (concurrent/distributed) (c) Dr. David A. Workman 13

Software Requirements Specification 3. 7 Object Oriented Design 3. 7. 1 Software Architecture Package Diagram with narrative: decompose the software system into packages or subsystems; show the dependencies among subsystems; identify key classes and or subcomponents within Checkout Station Grocery Conveyor POSS Conveyor Controller Shopper Sales Terminal Coveyor Belt Cash Drawer Waiting Line Clerk February 9, 2007 (c) Dr. David A. Workman Queue Mgr Shopper Queue 14

Requirements Analysis (USP) • Artifacts – Analysis Classes Abstractions of one or several classes and/or subsystems in the design. Has the following characteristics: • Focuses on functional requirements • Seldom defines or provides any interface in terms of operations. Behavior is defined in terms of responsibilities on a more or less informal level. • Defines attributes, but at an abstract level. Attribute types are conceptual and have meaning in the problem domain. Attributes found during analysis commonly become classes in the design and implementation. • Class relationships are more informal and have less significance compared to design and implementation. • Fall into one of three categories: Boundary, Entity, and Control – Boundary Classes • Used to model interaction between the system and its actors! The interaction often involves receiving and presenting information and/or requests. They collect and encapsulate requirements defining external system interfaces - if these change, only boundary classes should be effected. • Boundary classes are often realized by windows, forms, panes, comm ports, etc. They are characterized by the content and granularity of information that they exchange at the system interface - not the form and style of the exchange. February 9, 2007 (c) Dr. David A. Workman 15

Requirements Analysis (USP) • Artifacts – Entity Classes Used to model information that is long-lived and often persistent. They model information and behavior of some phenomenon or concept such as an individual, a real-life object or event. • Normally derived from a business (or domain) entity class. However, entity classes differ from their corresponding business counterparts in that they express the developer's view of how a business entity should be represented in the system; i. e. , business entities may encapsulate information that is irrelevant to the system. • Entity object need not be passive. – Control Classes Used to represent coordination, sequencing, transactions, and control of other objects and are often used to encapsulate control (thread) related to a specific use cases. They are used to encapsulate complex computations or business logic that cannot be logically associated with an entity class. • They encapsulate high-level control flow. • They delegate work to boundary and entity classes where appropriate. • They do not encapsulate issues related to interactions with actors (boundary classes). • They do not encapsulate issues related to persistence (entity classes). February 9, 2007 (c) Dr. David A. Workman 16

Requirements Analysis (USP) • Artifacts – Use-case Realizations A collaboration within the analysis model that describes how a specific use case is realized and performed in terms of analysis class instances. A use-case realization traces directly to a system use case in the requirements model. A use-case realization includes the following: • Class diagrams that identify participating analysis classes ( names & responsibilities, may include important problem attributes ) • Interaction diagrams ( preferably communication diagrams ) that depict the particular interaction flow among analysis objects engaged in the use-case scenario notes: (1) boundary objects need not be specific to a given use case – many use cases may share the same boundary objects; (2) entity objects also persist beyond a single use case (3) control objects frequently created when the use case starts and are destroyed when the use case ends – but, like boundary objects, control objects may manage more than one use case • Flow-of-events analysis is narrative that accompanies the interaction diagram and explains details about the interaction sequence that may not be obvious from the diagram. This narrative explains the internal system view of events relating to a use case. • Special requirements (non-functional) February 9, 2007 (c) Dr. David A. Workman 17

Requirements Analysis (USP) • Artifacts – Analysis Package Name package Provides a means of organizing the artifacts of the analysis model into manageable pieces. Consists of: analysis classes, use-case realizations, and nested analysis packages. • Packages generally group related use cases that can share a thread of control, although they may cross use case boundaries. They encapsulate a coherent set of related functional requirements. • Packages are likely to become, or are likely to be distributed among, subsystems in the top application layers of the design model. • Packages are typically shared by multiple use-case realizations. – Architecture Description An identification and discussion of the architecturally significant artifacts of the analysis model. • Packages and their dependencies are architecturally significant • Key control, entity, and boundary classes are architecturally significant • Use-case realizations for critical functionality are architecturally significant Architectural descriptions are best presented in the form of communication diagrams that depict the architecturally significant packages, analysis classes, and use-case realizations. February 9, 2007 (c) Dr. David A. Workman 18

Analysis vs Design (USP) February 9, 2007 (c) Dr. David A. Workman 19

Design (USP) • Purpose The system is shaped to accommodate all functional and non-functional requirements. It contributes to a sound and stable architecture and creates a blueprint for the implementation model. – Acquire an in-depth understanding of non-functional requirements and constraints related to: programming languages, component reuse, operating systems, distribution topology, network and database technologies, user-interface technology, etc. – Define and harden the boundaries between subsystems. • Artifacts – Design Model An object model that describes the physical realization of use cases by focusing on how functional and non-functional requirements, together with other constraints related to the implementation environment, impact the system architecture and structure. • Design classes • Use-case realizations (design) • Detailed Interfaces February 9, 2007 (c) Dr. David A. Workman 20

Design (USP) • Artifacts – Architecture Description A view of the design model focusing on the following architecturally significant artifacts: • Subsystems, interfaces, and their dependencies • Key classes that trace to key analysis and active classes • Key use case realizations that are functionally critical and need to be developed early in the lifecycle. Ones that have coverage across subsystems are particularly important. – Deployment Model An object model that describes the physical distribution of the system in terms of how functionality is distributed among computational nodes. An essential input to the activities in design and implementation. It is a manifestation of the mapping between software architecture and system architecture. • Nodes that denote computational resources • Node processes and corresponding functional allocation • Node relationships and their types (internet, shared memory, ATM link, etc. ) • Network topology(ies) February 9, 2007 (c) Dr. David A. Workman 21

Designing Classes • Step 1: Outlining the Analysis Classes – – – • Boundary classes: decide on mode of input; e. g. command, gui, file, db, com Entity classes: capture and encapsulate persistent problem (user visible) information. Control classes: introduce to manage and encapsulate the interaction flow defined by use cases. Step 2: Allocating Functional Responsibilities – – – Input Boundary objects should be responsible for transforming raw input data to instances of entity classes that will be manipulated by a use case. Output Boundary objects should be responsible for writing internal data to some external device; e. g. gui and file objects. Entity classes should provide boundary methods for parsing their external image received from some input boundary object. Analogously, boundary methods for writing their image to some output boundary object. E. g. Extract(), Insert(), Get(), Put() Each functional step required to complete a use case should be allocated as a responsibility to some analysis object – this means that use cases should be decomposed into a sequence of triples ( sender, message, receiver ), “sender” denotes an object that requires an action to be performed by the “receiver” object. “Message” describes the action to be performed and contains the problem data that may need to be supplied by sender to enable the receiver to complete the operation; messages typically will be realized by method calls on the receiver. Control objects typically should have responsibility for creating objects that it exclusively manages or controls. Objects that persist beyond a given use case or that must be shared by use cases, should be passed as parameters to the use case control object, or should be provided by inspector methods. February 9, 2007 (c) Dr. David A. Workman 22

Designing a Class • Step 3: Defining Attributes – Control Classes: use case local objects, or objects created by the use case and shared with other use cases. – Entity Classes: encapsulated problem data, association and composition relationships with other classes. – Boundary Classes: encapsulated boundary objects and control parameters. • Step 4: Identifying Associations and Aggregations The interaction of objects implies some type of relationship - usually association or aggregation. – Association: a relationship between class instances suggesting that the instances involved must interact in some way, or that one provides access to the others. – Aggregation: a one-to-many Whole-Part relationship (contains-A, holds-A, manages-A) such as between a container and its containees. Expresses a loose functional coupling between the Whole and its Parts. Whole is not responsible for creating the Parts – they are created by clients of the Whole. – Composition: a one-to-many Whole-Part relationship (has-A) between an aggregate object and its components. Usually the relationship implies a strong functional coupling between Whole and its Parts – the Whole is not complete and will not function correctly without its Parts, AND the Whole is responsible for creating and initializing instances of its Part. February 9, 2007 (c) Dr. David A. Workman 23

Designing a Class • Step 5: Identifying Generalizations are formed by factoring common attributes and operations from an existing collection of related and similar analysis classes. The gen-spec (is-a) relation is normally realized via the mechanism of inheritance in the implementation language. If a suitable inheritance mechanism does not exist in the implementation language, then it can be simulated by defining the "factored superclass" as a part of each subclass - thus replacing generalization by whole-part. • Step 6: Describing Methods are the realization of operations defined for the class. ". . . they are not specified during design. Instead, they are created during implementation using the programming language directly. " – However, the designer should : • • ! – decide what information is required to implement the operation decide how the information is best obtained: (a) computed from instance attributes (data members) (b) computed from operation parameters (does caller always have this info? ) (c) computed from data obtained by operations on other objects created as local variables - decide what classes denote those objects, what operations are needed, and what data must be supplied as parameters to such operations. Observe that these decisions could: • • • create new associations with existing classes create new classes and associations cause redesign of the operation interface and all dependent methods February 9, 2007 (c) Dr. David A. Workman 24

Designing a Class • Step 7: Describing States Object (class instance) states should be introduced to realize and enforce constraints on operation sequences - that is, to realize operation protocols. For example, "open" must be issued on a file object before "read" or "write" operations can be successfully applied. One or more attributes may need to be defined to realize the object state. • Step 8: Check Completeness After completing a design pass – that is, after having analyzed all use cases and having reached the point where you “think” the design is adequate, you should formally verify completeness by constructing the Use Case Coverage Table and a Requirements Mapping Table. Not only will these tables help you ensure the completeness of your architectural design, it will be critically important in testing and integration and in defining incremental releases of the system. February 9, 2007 (c) Dr. David A. Workman 25

UML Modeling Concepts Use Case Model Analysis Model Communication Diagram Design Model Customer Int data Money cash Customer() Method 1() Method 2() … Use Case Diagram * Communication Diagram February 9, 2007 (c) Dr. David A. Workman 26

OO Modeling Concepts in UML WHOLE-PART (Composition) Objects relate to one another in a variety of ways, some relationships are of a physical nature, while others are of a more logical or conceptual nature. For example: Whole-Part: In this type of relationship, one or more objects are parts or components of a more complex composite object representing the whole. Relationships of this kind tend to model physical or geographic relationships involving tangible objects. For example, an Engine is part of an Automobile. Whole-Part is also referred to as the “Has-A(n)” relation, that is, an Automobile Has-An Engine. Whole-Part relationships tend to imply a strong functional interaction (high coupling) between constituent objects. Composition is usually implied when the “whole” has responsibility for creating its “parts” [Texel] February 9, 2007 (c) Dr. David A. Workman Part 1 Part 2 UML Representation 27

OO Modeling Concepts in UML WHOLE-PART (Aggregation) Container-Containee: This relationship is somewhat like the Whole-Part where the Whole is an object that plays the role of a “storage container” used to hold and organize instances of some class of “containee” objects. Normally, there is a very little interaction between the Container and its Containees. For example, a Bag of Groceries. The Bag denotes the container and the groceries are the containees. This relationship might also be called the “Holds-A(n)” relation. In contrast to Composition, seldom are there any functional dependencies or interactions between the Container and its Containees. Containers are normally not responsible for creating containees. February 9, 2007 (c) Dr. David A. Workman Container * Containee UML Representation 28

OO Modeling Concepts in UML WHOLE-PART (Affiliation ) Organization-Member: Affiliations are almost always logical in nature. The Organization may represent a loose collection of Members( people or things ) having a common purpose or interest or other reason for affiliation. The Member-Organization relationship might also be called the “Belongs-To” relation; conversely, the Organization-Member relationship could be called the “Includes” relation. This type of relationship may not be formal enough to define a class of objects - it is the type of relationship that can dynamically change its membership; that is, the type of objects that form the affiliation defined by this relationship can change with time. For example, members of a club or email interest group may have a common background, common interests, or a common hobby that forms the basis for their affiliation, but there may not be a need for a formal organization. February 9, 2007 (c) Dr. David A. Workman Organization * Member UML Representation 29

OO Modeling Concepts in UML ASSOCIATION This relationship is the most informal of all those mentioned above. This relationship is used to define an instance connections (Coad/Yourdon) between objects; that is, a weak relationship between objects necessary to model some property or “interest” they have in common. Or, objects that have some reason to interact. For example, a Customer holds a contract with a Vendor. In this association, the customer plays the role of Buyer while the Vendor plays the role as Seller. Both Customer and Vendor are associated with a Contract, but through different relationships. Also note the multiplicity constraints on these associations. Customer Buyer 1 role * Seller Holds contracts with role association 1 1 Seller Buyer 1 February 9, 2007 Vendor Contract 1 (c) Dr. David A. Workman UML Representation 30

OO Modeling Concepts in UML INHERITANCE Inheritance is a relationship between classes also known as the Generalization. Specialization (Gen-Spec) relation. A superclass is said to generalize its subclasses, conversley, a subclass is said to specialize its superclass. Inheritance implies the following: Objects of a subclass inherit all attributes defined by the superclass, and may define addtional ones; Objects of a subclass normally inherit all services (behavioral characteristics) defined by the superclass, and may re-define any subset of them; Objects of a subclass may define new services (behavior variation) not provided by the superclass. Superclass Subclass 1 Subclass 2 UML Representation February 9, 2007 (c) Dr. David A. Workman 31

UML Class Diagrams February 9, 2007 (c) Dr. David A. Workman 32

Analysis Modeling Process Inputs: Customer Requirements Documents Customer/User Mtng Minutes Use Case Model 2. 0 Start Analysis Modeling Use Case Coverage Table Ordered by Priority Work Package Specifications and Dependencies Activity Diagram Defining work flow for WP Analysis February 9, 2007 2. 1 Prioritize Use Cases See Notes Below 2. 2 Form Work Pkgs 2. 3 Prioritize, Schedule & Staff Work Pkgs (c) Dr. David A. Workman Next 33

Analysis Modeling Process See Notes Below 2. 4 Select Nest WP to Analyze Next Slide [more WPs to Analyze] 2. 4. 1 Prioritize Use Cases for this WP 2. 4. 2 Select Highest priority Use case from This WP [more UCs to Analyze in this WP] Analysis Control Class Spec. 2. 4. 3 Define/Assign Control Object To this UC 2. 4. 9 Review/Revise Use Case Artifacts Use Case Communication Diagram 2. 4. 4 Analyze all UC Interaction Scenarios 2. 4. 8 Update System Class Diagram Analysis Entity Class Spec. 2. 4. 7 Update Use Case Coverage Table For this UC Use Case Coverage Table 2. 4. 5 Define/Assign Entity Objects To this UC 2. 4. 6 Define/Assign Bndry Objects To this UC Analysis Bndry Class Spec. Use Case Interface Spec. February 9, 2007 (c) Dr. David A. Workman 34

Analysis Modeling Process From Previous Slide Software Requirements Specification 2. 5 Produce Software Reqmnts Spec Software Development Plan 2. 6 Produce Software Development Plan 2. 7 Review Plans with Customer 2. 8 Revise Plans [revisions necessary] February 9, 2007 (c) Dr. David A. Workman 2. 9 Place Plans Under Configuration Control Next 35

Design Modeling Process 3. 0 Select Next WP [ more WP To Design ] 3. 1 Select Highest Priority Use Case in WP [more Use Cases in WP] Test Plan For WP 3. 2 Select Highest Priority Class, A, in UC 3. 7 Rework/Revise [ Errors Detected] Use Case Design & Test Plans Return From next slide 3. 6 Review Use Case Design & Test Plans 3. 3 Design Class A 3. 4 Produce Class Test Plan for A Test Plan For A [more classes in UC] February 9, 2007 3. 5 Produce UC Test Plan [all WPs Complete ] 3. 9 Review WP Design & Test Plans 3. 8 Produce WP Integration Test Plan [ Errors Detected] 3. 10 Revise WP Design & Test Plans 3. 11 Develop/Review System Test Plan For UC (c) Dr. David A. Workman Design End 36

Design Modeling Process Note 1 {C} and A impose functional reqmts on M. This step insures M satisfies All functional demands currently Defined for M. Note 2 {C} must supply values of all parms defined for M. M must deliver all data expected By {C} Note 3 Choose algorithms and data structures for M. Decide on any existing methods, X: : P(), that must be called by M. Decide on any new classes and/ or methods, Y: : Q(), that must be called by M. Add these to the Use Case Coverage Table. Add M to the Caller list for each X: : P() and Y: : Q(). February 9, 2007 3. 3 Design Class A Use Case Coverage Table 3. 3. 1 Select A Method, M from Class A 3. 3. 2 Identify All Methods, {C} that Call M 3. 3. 3 Using {C} and A allocate functional responsibilities to M (See Note 1) 3. 3. 9 Review/Revise Design & Test Plans for A Return To Previous Slide [ design of A not complete] Caller List for M 3. 3. 8 Develop Test Plan for A Test Plan for Class A Design Spec for Class A Caller List for X: : P() 3. 3. 7 Produce Design Spec for A Caller List for Y: : Q() M 3. 3. 4 Design Interface to M (See Note 2) (c) Dr. David A. Workman 3. 3. 5 Design Body of M (See Note 3) 3. 3. 6 Design Test Plan for M Test Plan For M 37

Functional to Object-Oriented Architectures Class-A Use Case Flow X X Related computations on different objects. A Public Service Layer Y 1 A Y A B Data & Control Flow Control/ Boundary Object C (a) Functional Architecture February 9, 2007 Z 1 Y 2 Z B Messages Class-B B Z 2 C Class-C (b) Object-Oriented Architecture (c) Dr. David A. Workman 38

Functional Dependencies Among Methods B A 1 1 2 E 2 2 3 1 1 2 C 1 3 D February 9, 2007 (c) Dr. David A. Workman 39

Functional Threads (Use Cases) A B A 1 C D E B 1 A 2 D 2 E 1 D 1 E 2 A 3 C 1 B 2 D 3 February 9, 2007 (c) Dr. David A. Workman 40

Hierarchical View of Design main A: : One() A: : Two() B: : One() D: : Two() A: : Three() C: : One() Use Case #1 E: : One() B: : Two() Use Case #2 D: : One() D: : Three() Use Case #3 E: : Two() February 9, 2007 (c) Dr. David A. Workman 41

Design & Testing Principles Principle 1: Design should be performed “top-down” for each functional thread defined by a Use Case; that is, the interface and detailed design of a module should follow the design of all modules that functionally depend on it. A B C D Rationale: By performing interface and detailed design top-down, we ensure that all requirements flow from dependent modules toward the modules they depend on. This principle attempts to postpone detailed design decisions until all functional requirements for a module are known. Principle 2: Coding and Unit Testing should be performed “bottom-up” for a functional thread; that is, the unit testing of a module should precede the unit testing of all modules that functionally depend on it. Rationale: By performing unit testing bottom-up, we ensure that all subordinate modules have been verified before verifying the module that depends on them. This principle attempts to localize and limit the scope and propagation of changes resulting from unit testing. February 9, 2007 (c) Dr. David A. Workman 42

Design & Testing Schedules See Notes Development Layers for Detailed Design and Coding Development Layers for Unit Testing Effort Development Schedule Time Build #1 (Integration Test 1) Build #2 (Integration Test 2) Build #3 (System Test) February 9, 2007 (c) Dr. David A. Workman 43

Use Case Diagram: Simulator Simulation System Specify Input Simulation Input File Construct World Specify Output Simulation User Initialize Simulation Output World Objects Simulation Log File Simulate World Report Simulation Data February 9, 2007 (c) Dr. David A. Workman 44

Design Graph: 1 Use Case 1 Main() Use Case 2 Conversation() Conversation: : Initialize() * Players() Student: : Student() Student: : Extract() Student: : Name. Of() * Student: : Initialize() Players: : ~Players() Players: : set. Agent() Student : : Get() Event. Mgr: : post. Event() * Student: : Name. Of() Agent : : Get() Players: : get. Agent() * Players: : get. Other() Event() Student: : Accept. Question() ifstream: : >> string Speak. Msg() February 9, 2007 (c) Dr. David A. Workman 45

Design Graph: 2 Main() Use Case 4 Conversation: : Simulate() Use Case 5 Use Case 3 Conversation: : Put. State() Conversation: : ~Conversation() Conversation: : Wrap. Up() Event. Mgr: : more. Event() Message: : ~Message() Student: : ~Student() Event. Mgr: : get. Next. Event() Event: : get. Msg() Student: : Insert() Agent: : <<() 2 Event: : <<() Student: : Dispatch() Event: : get. Recvr() Student: : do. Answer() Speak. Msg: : get. Handler() Student: : Put() Message: : Insert() Student: : do. Question() Message: : <<() Student: : Accept. Answer() Agent: : Put() Message: : Put() Event. Mgr : : post. Event() String. Msg() February 9, 2007 (c) Dr. David A. Workman 46

Scheduling Agent: : Agent() Student: : Student() Agent: : Get() Agent: : Extract() Student: : Get() ifstream: : >> for Agent Conversation() Student : : Extract() Development Time Principle: Constructor for a class must be implemented before any methods for that class. February 9, 2007 (c) Dr. David A. Workman 47