analysis & design modeling cop4331 and eel4884 oo processes for software development © dr....

Analysis & Design Modeling

COP4331 and EEL4884 OO Processes for Software Development

© Dr. David A. WorkmanSchool of Computer Science

University of Central FloridaFebruary 1, 2009

February 23, 2010

February 23, 2010 (c) Dr. David A. Workman 2

Overview of USP

RequirementsElaboaration

(OO-Analysis)

RequirementsElaboaration

(OO-Analysis)

Object-OrientedDesign

Object-OrientedDesign

Object-OrientedImplementation(Programming)

Object-OrientedImplementation(Programming)

Problem Statement& User NeedsUse Case

Model

The process of defining and modeling the Problem Space

The process of defining and modeling the Solution Space

Design & DeploymentModels

Code in anOOPL (Ada95)(C++)(Java)ComponentModel

Mapping design to Implementation Space

RequirementsElicitation

(Definition)

RequirementsElicitation

(Definition)

Analysis Model


Overview of USP

• 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

Inception Elaboration Construction Transition

Birth Death

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion… …

Itera-tion

Itera-tion

Arch. Design Design Refinement

(Analysis Model) (Design Model)


Requirements Elicitation vs Elaboration (USP)

Use-case Model Analysis Model Described using the language of the customer.

Described using the language of the developer.

External view of the system. Internal view of the system.

Structured by Use cases; gives structure to external view

Structured by sterotypical classes and packages; gives structure to internal view

Used primarily as a contract between client and developer as to what the system should do.

Used primarily by developers to understand how the system should be shaped; that is, designed and implemented.

May contain redundancies and inconsistencies among requirements

Should be complete, precise, consistent, and testable.

Captures functionality of the system including architecturally significant functionality.

Outlines how to realize functionality within the system; works as the first cut at design.

Defines use cases further analyzed in the analysis model.

Defines Use-case realizations, each one representing the analysis of a use case from the Use Case model.


UML Process and Artifacts

1: RequirementsElicitation(Capture)

2: RequirementsElaboration(Analysis &

Specification)

3: SoftwareDesign

SoftwareDevelopment

Plan

SoftwareRequirements

Spec

AnalysisModel

Use CaseModel

Use CaseDiagram

CommunicationDiagram

StateChart

ModelSystem/Gui

behavior

Model Use CaseInternal behavior

Define SystemBoundary;

Identify ActorsAnd External

Interfaces;Identify Use Cases

Define InternalView of System

Identify SubsystemsIdentify Classes & Objects

Allocate FunctionalResponsibilities

ClassDiagram

ArchitectureDiagram

Identify Boundary, ControlEntity Classes and their

Relationships

Identify Packagestheir Interfaces &

Relationships

PartitionSoftware into

Work packages.Estimate cost, resources,

Size, and schedule.

ActivityDiagram

ModelUse Case

Flow

CommunicationDiagram

Model Use CaseExternal behavior


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 ClassesFor 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) – design of dynamic interaction flow for each use case– Statecharts/Diagrams (UML) – dynamic behavior of key control objects and subsystems– Use Case Coverage Table – architecture completeness; basis for integration and system testing– Traceability Matrix – ensures all requirements have been allocated to solution elements


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.

• ActivitiesRefine 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)


Use Case Coverage Table

Data members & Methods

UC1 UC2 UCk UCn-1 UCn

Class-1

Class-2

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.


Requirements Mapping Table

FunctionalRequirements

UC1 UC2 UCk UCn-1 UCn

Class-1

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.


Software Requirements Specification1

• Title• TOC

1. Introduction1.1 Purpose

1.2 Scope

1.3 Definitions. Acronyms, and Abbreviations

1.4 References

1.5 Overview

2. Overall Description

3. Specific Requirements

4. Appendices

5. Index

1 IEEE Std 830-1998

•Purpose of this SRS.•Intended audience.

This sections defines the vocabulary of the SRS. Itmay reference an appendix.

Reference all documents and SMEs used to write the SRS. E.g. Use Case Model and ProblemStatement; Experts in the field.

• Describe the content of the rest of the SRS.• Describe how the SRS is organized.

•Identify the software product.•Enumerate what the system will and will not do.•Describe user classes and benefits to each.

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.


Software Requirements Specification1

• Title• TOC1. Introduction

2. Overall Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 Constraints

2.5 Assumptions and Dependencies3. Specific Requirements4. Appendices5. Index

1 IEEE Std 830-1998

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

Describes and justifies technical skills and capabilities of each user class.

Describes other constraints that willlimit developer’s options; e.g., PL, target platform, database, network software and protocols, developmentstandards requirements.

States assumptions about availability of certainresources that, if not satisfied, will alter systemrequirements and/or effect the design.

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


Software Requirements Specification

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

Specifies software requirements in sufficient detail to enable designers to design to satisfythose requirements and testers to verify requirements.

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 thesystem, every output (response) from the system, and all functions performed by thesystem in response to an input or in supportof 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.


Software Requirements Specification

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 Additional Comments

• Index

• Appendices

Should detail description of all inputs and outputs,but should complement, not duplicate, informationpresented in section 5.2. Examples: ( GUI screens, File formats)

Should include detailed specifications of eachuse case (analysis view) , including collaboration and other diagrams useful for this purpose.

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 ina variety of possible ways.

(a) Architecture Specification(b) Class Diagram(c) State and Collaboration Diagrams(d) Activity Diagram (concurrent/distributed)


Software Requirements Specification3.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

Clerk

Grocery Conveyor

Conveyor Controller

CoveyorBelt

Sales Terminal

POSS

CashDrawer

Waiting Line

Queue MgrShopperQueue

Shopper


Requirements Analysis (USP)• Artifacts

– Analysis ClassesAbstractions 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.



– Entity ClassesUsed 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 ClassesUsed 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).



– Use-case RealizationsA 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 scenarionotes:(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)



– Analysis PackageProvides 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 DescriptionAn 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.

Name

package


Software Development Plan (SDP)2

• Front Matter (Title, Toc, Lof, Lot)

1. Overview1.1 Project Summary

1.2 Evolution of Plan

2. References

3. Definitions

4. Project Organization

5. Managerial Process Plans5.1 Start-up Plan

5.2 Work Plan

5.3 Control Plan

5.4 Risk Management Plan

5.5 Closeout Plan

6. Technical Process Plan

7. Supporting Plans

2 IEEE Std 1058-1998


Analysis Modeling ProcessInputs:Customer Requirements DocumentsCustomer/User Mtng MinutesUse Case Model

See NotesBelow

2.0 StartAnalysisModeling

Use CaseCoverage Table

Ordered byPriority

Work PackageSpecifications

and Dependencies

Next

Activity DiagramDefining work

flow for WPAnalysis

2.1 PrioritizeUse Cases

2.2 FormWork Pkgs

2.3 Prioritize,Schedule & Staff

Work Pkgs


Analysis Modeling Process

NextSlide

Use CaseCoverage

Table

AnalysisControl Class

Spec.

AnalysisEntity Class

Spec.

AnalysisBndry Class

Spec.

[more WPs to Analyze]

See NotesBelow

Use CaseCommunication

Diagram

Analysis Class

Diagram

2.4Select Next

WP to Analyze

2.4.1 PrioritizeUse Cases for

this WP

2.4.2 SelectHighest priorityUse case from

This WP[more UCs to Analyze in this WP]

2.4.3Define/Assign

Control ObjectTo this UC

2.4.4Analyze all

UC InteractionScenarios

2.4.5Define/AssignEntity Objects

To this UC

2.4.6Define/AssignBndry Objects

To this UC

2.4.7Update Use CaseCoverage Table

For this UC

2.4.8Update SystemClass Diagram

2.4.9Review/Revise

Use CaseArtifacts

Use CaseInterface

Spec.


Analysis vs Design (USP)

Analysis Model Design Model

Satisfies functional requirements. Satisfies both functional and non-functional requirements.


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


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 ModelAn 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)


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/class – 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.


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 AggregationsThe 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 (if any) 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)&(requires-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.


• Step 5: Identifying GeneralizationsGeneralizations 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

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

!

Designing a Class


Designing Classes & Methods

Method to be DesignedInputs: Functional responsibilities from clients (already designed)Outputs: Desired results or changes to the object to which the method applies, and perhaps changes to parameters passed to the method.

Functional requirements

generated by all clientsWithin the current

design –

> Add new classes> Add new methods to existing

classes> Add new calls to existing

methods

Extend the Design


• Step 7: Describing StatesObject (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 CompletenessAfter 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.

Designing a Class


UML Modeling Concepts

Use Case Diagram

Use Case Model

Communication Diagram

Analysis Model

Communication Diagram

*

Design Model

Customer

Int dataMoney cash

Customer()Method1()Method2()…


OO Modeling Concepts in UMLWHOLE-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]

Whole

Part1 Part2

UML Representation


OO Modeling Concepts in UMLWHOLE-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.

Container

Containee

UML Representation

*


OO Modeling Concepts in UMLWHOLE-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.

Organization

Member

UML Representation

*


OO Modeling Concepts in UMLASSOCIATION

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.

VendorHolds contracts with

Customerassociationrole role

Buyer Seller

Contract

Buyer Seller

UML Representation

1 1

*1


OO Modeling Concepts in UMLINHERITANCE

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

Subclass1 Subclass2

UML Representation


UML Class Diagrams


Design Modeling Process

3.3 DesignClass A

3.3.1 Select AMethod, M

from Class A

Use CaseCoverage

Table

3.3.2 IdentifyAll Methods, {C}

that Call M

3.3.3 Using {C} and Aallocate functional

responsibilitiesto M (See Note1)

3.3.4 DesignInterface to M

(See Note2)

{C} and A imposefunctional reqmtson M. This step insures M satisfiesAll functional demands currentlyDefined for M.

{C} must supplyvalues of all parmsdefined for M. M must deliverall data expectedBy {C}

Note1

Note2

3.3.5 DesignBody of M(See Note3)

Choose algorithms and data structures for M. Decide onany 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 foreach X::P() and Y::Q().

Note3

CallerList for

M

CallerList for X::P()

CallerList for Y::Q()

M

[ design of A not complete]

3.3.6 DesignTest Plan

for M

Test PlanFor M

DesignSpec forClass A

3.3.7 ProduceDesign

Spec for A

3.3.8Develop Test

Plan for A

3.3.9Review/ReviseDesign & Test

Plans for A

Test Planfor

Class A

ReturnTo PreviousSlide

analysis & design modeling cop4331 and eel4884 oo processes for software development © dr....

Documents

usecase realizations

detailed use cases

implementation model

deployment model

sterotypical classes

control entity classes

external viewstructured

internal viewused