Software EngineeringSoftware Engineering

Chapter 8Chapter 8

Fall 2001Fall 2001

AnalysisAnalysis

• Extension of use cases, use cases are Extension of use cases, use cases are converted into a more formal description converted into a more formal description of the system.of the system.

Why?Why? Use cases must be kept as independent of Use cases must be kept as independent of

each other as possible for simplicity.each other as possible for simplicity. Use cases must be described in the Use cases must be described in the

language of the customer.language of the customer. Each use case must be structured to form Each use case must be structured to form

a complete and intuitive specification of a complete and intuitive specification of functionality.functionality.

After getting the requirements from the After getting the requirements from the users and describing them as use cases, users and describing them as use cases,

these use cases need to be analyzed.these use cases need to be analyzed.

Resolve issues such as concurrency.Resolve issues such as concurrency. Multiple accesses to the same data at the Multiple accesses to the same data at the

same time.same time. Relationships and dependencies among Relationships and dependencies among

use cases.use cases. Other system requirements that are Other system requirements that are

transparent to the user.transparent to the user.

Structure the requirements to facilitate:

understanding them by the developersunderstanding them by the developers preparing thempreparing them changing themchanging them reusing themreusing them maintaining themmaintaining them

The analysis modelThe analysis model analysis classesanalysis classes packagespackages interaction diagramsinteraction diagrams handles shared resourceshandles shared resources

• See Table 8.1 page 175 (Use case model See Table 8.1 page 175 (Use case model vs. analysis model)vs. analysis model)

• The purpose of the analysis is to produce a precise and detailed understanding of the requirements. This goes beyond what the user is directly concerned with. We are still talking about the requirements from the user’s perspective, but in much more detail than the use cases. Although the analysis may bring up questions that need to be discussed with the user, the user is not necessarily involved in the analysis. After the users help specify the requirements as use cases, the developers analyze those requirements. In particular, they analyze how the pieces fit together into a system and what problems might arise.

For example, in the use case model:For example, in the use case model:• Use Case 1Use Case 1 The bank teller processes a deposit for the The bank teller processes a deposit for the

customer.customer. The deposit is added to an account.The deposit is added to an account.

• Use Case 2Use Case 2 The customer later withdraws money.The customer later withdraws money. The withdrawal is subtracted from an The withdrawal is subtracted from an

account.account.

In the analysis model:In the analysis model:

It is determined that the deposit and It is determined that the deposit and withdrawal are affecting the same withdrawal are affecting the same account if it is the same customer.account if it is the same customer.

The relationship between the deposit and The relationship between the deposit and withdrawal may be better defined.withdrawal may be better defined.

In the design model:In the design model:

It is determined how the deposit and It is determined how the deposit and withdrawal use cases will be converted withdrawal use cases will be converted into program modules or classes. into program modules or classes.

For example, deposit might be one class For example, deposit might be one class in the actual program, and withdrawal in the actual program, and withdrawal might be another class. might be another class.

As an alternative they might be combined As an alternative they might be combined into the same single class.into the same single class.

Artifact – Analysis ModelArtifact – Analysis Model

Analysis classAnalysis class

Boundary classesBoundary classes Entity classesEntity classes Control classesControl classes

Class DiagramClass Diagram

• (see Fig. 8.11 page 187 and page 45)(see Fig. 8.11 page 187 and page 45) realization of a use case in classesrealization of a use case in classes

Collaboration DiagramCollaboration Diagram

• (Interaction Diagram) (see Fig 8.12 page (Interaction Diagram) (see Fig 8.12 page 188)188)

puts actions on the lines of the class puts actions on the lines of the class diagram to show the interactions among diagram to show the interactions among the classesthe classes

Trace DiagramTrace Diagram

• (see Fig 8.9 page 186 and page 44)(see Fig 8.9 page 186 and page 44) shows which use cases are realized by shows which use cases are realized by

which classeswhich classes

Flow of EventsFlow of Events

• (see Example page 189)(see Example page 189) A text description that explains the A text description that explains the

collaboration diagramcollaboration diagram

Special RequirementsSpecial Requirements

• (see Example page 190)(see Example page 190) description of nonfunctional requirementsdescription of nonfunctional requirements

Analysis PackageAnalysis Package

a grouping of analysis classes into a a grouping of analysis classes into a packagepackage

a way to organize classes into different a way to organize classes into different groups and subgroupsgroups and subgroups

Service PackageService Package

a group of functionally related classesa group of functionally related classes this group of classes can be used this group of classes can be used

generally by several use casesgenerally by several use cases spell check might be an examplespell check might be an example service packages are reusableservice packages are reusable service packages are loosely coupledservice packages are loosely coupled

Architecture DescriptionArchitecture Description

Architecturally significant artifacts of the Architecturally significant artifacts of the Analysis ModelAnalysis Model

Analysis packages and their dependenciesAnalysis packages and their dependencies Key analysis classesKey analysis classes Use-case realizations that realize critical Use-case realizations that realize critical

functionalityfunctionality

WorkersWorkers

ArchitectArchitect

responsible for overall integrity of the responsible for overall integrity of the analysis modelanalysis model

ensures the analysis model as a whole is ensures the analysis model as a whole is correct, consistent, and readablecorrect, consistent, and readable

Use-Case EngineerUse-Case Engineer

make sure the diagrams and text are make sure the diagrams and text are correctcorrect

responsible for the integrity of one or responsible for the integrity of one or more use case realizationsmore use case realizations

and correctly realize the use case from and correctly realize the use case from the use case modelthe use case model

Component EngineerComponent Engineer

make sure each analysis class fulfills the make sure each analysis class fulfills the requirements made on it from the use requirements made on it from the use case realizations in which it participatescase realizations in which it participates

maintains the integrity of one or more maintains the integrity of one or more analysis packagesanalysis packages

WorkflowWorkflow

Activity – Architectural AnalysisActivity – Architectural Analysis

Identify analysis packagesIdentify analysis packages Handle commonality among analysis Handle commonality among analysis

packagespackages Define analysis package dependenciesDefine analysis package dependencies Identify service packagesIdentify service packages Identify obvious entity classesIdentify obvious entity classes Identify common special requirementsIdentify common special requirements

Activity – Analyze a Use CaseActivity – Analyze a Use Case

Identify analysis classesIdentify analysis classes Describe analysis object interactionsDescribe analysis object interactions Capture special requirementsCapture special requirements

Activity – Analyze a ClassActivity – Analyze a Class

Identify responsibilitiesIdentify responsibilities Identify attributesIdentify attributes Identify associations and aggregationsIdentify associations and aggregations Identify generalizationsIdentify generalizations Capture special requirementsCapture special requirements

Activity – Analyze a PackageActivity – Analyze a Package

Make sure the package contains the right Make sure the package contains the right classesclasses

Limit the dependencies to other packagesLimit the dependencies to other packages Define and maintain the dependencies Define and maintain the dependencies

that do existthat do exist

Summary of AnalysisSummary of Analysis

Analysis modelAnalysis model Analysis packages and service packagesAnalysis packages and service packages Analysis classes and their responsibilities, Analysis classes and their responsibilities,

attributes, relationships, and special attributes, relationships, and special requirements.requirements.

Use-case realizationsUse-case realizations Architectural view of the analysis modelArchitectural view of the analysis model