Analysis

Introduction

Use-case model vs. Analysis model

	Use-Case Model	Analysis Model
1	Described using the language of the customer	Described using the language of the developer

2	External view of the system	Internal view of the system

3	Structured by use cases; Gives structure to the external view	Structured by stereotypical classes and packages; gives structure to the internal view

4	Used primarily as a contract between the customer and the developer on what the system should and should not do	Used primarily by developers to understand how the system should be shaped, i.e. designed and implemented

5	May contain redundancies, inconsistencies, etc. among requirements	Should not contain redundancies, inconsistencies, etc. among requirements

6	Captures the functionality of the system, including architecturally significant functionality	Outlines how to realize the functionality within the system, including architecturally significant functionality; works as a first cut at design

7	Defines use cases that are further analyzed in the analysis model	Defines use-case realizations, each one representing the analysis of a use case from the use-case model

Why analysis
Yield a more precise specification of the requirements.
Introduce formalism and reasoning about the internal system using the developer’s language
Structure the requirements in a way to be ready for design and implementation.
First cut at a design model.
The role of analysis in the software life cycle

Most of analysis work is done in the elaboration phase.

Artifacts

Artifact: Analysis Model

Artifact: Analysis Class

Example:

An analysis class represents an abstraction of one or several classes and or subsystems in the system’s design
Characteristics
Focus on handling functional requirements (conceptual)
Define behavior as responsibility, not operations
Define conceptual attributes from problem domain
Define conceptual relationships
Boundary classes
Responsibility:

Model interaction between the system and its actors
Model the parts of the system that depend on its actors
Clarify and collect the requirements on the system’s boundaries
Isolate user interfaces with the system’s internal structure

Boundary classes represent abstractions of visual interface components
Each boundary class should be related to at least one actor

Example:

Entity classes
Responsibility

Model information that is long-lived and often persistent
Model information and associated behavior of some phenomenon or concept (e.g. individual, real-life object, real-life event)
Show logical data structure and contribute to the understanding of what information the system dependent upon.

Usually derived from business entities from business model
An entity object encapsulates its persistent data as attributes and behaviors or operations to manipulate the data.

Example:

Control classes

Responsibility

Model dynamics of the system, including coordination, sequencing, transactions and control of other objects
Encapsulate control related to a use case
Represent business logic, complex derivation and calculations

A control object coordinates the main actions and control flow of a use case, and delegate work to other (boundary, entity, as well as control) objects

Example:

Artifact: Use-case Realization – Analysis

What is a use-case realization – analysis
A collaboration within the analysis model
It describes how a specific use case is realized and performed in terms of analysis classes and their interacting analysis objects
It provides a straightforward trace to a specific use case in the use-case model.

What a use-case realization consists of
Class diagrams
Interaction diagrams
Flow of events - analysis

Class diagrams
For each use-case realization, show participating analysis classes and their collaboration through their relationships

Example: Class diagram for Pay Invoice use-case realization

Example: Class diagram for register course use-case realization

Interaction diagrams (collaboration diagrams)
Collaboration diagrams are used to describe how typical scenarios or use-case instances are realized with collaborations of objects from the participating analysis classes.
Life cycles of analysis objects

Boundary and control object

Created: beginning of use-case realization(s)

Terminate: end of use-case realization(s)

Entity object: relatively long-lived

Example: Collaboration diagram for a realization of the Pay Invoice

Example: collaboration diagram for Register Course use case

Flow of events – analysis

Rewrite in text the flow of events from the use-case model for each use-case realization using in terms of collaboration of analysis objects.

No reference to objects’ attributes, responsibilities, and associations.

Artifact: Analysis Package

What is an analysis package
Provide a means of organizing the artifacts of the analysis model in manageable pieces.
What an analysis package consists of
Analysis classes
Use-case realizations
Other analysis packages
What is a well-defined analysis package
Cohesive

Its contents should be strongly related

Loosely coupled

Its dependencies on others should be minimized

What characteristics an analysis package should have
Separation of concern
Created based on functional requirements and on the problem domain
Top-level layer(s) of design model
What is a service package
A service package represents a coherent set of functionally related actions that are employed in several use cases.
A service package contains a set of functionally related classes
Service packages are low-level elements in an analysis package’s aggregation hierarchy.
Service vs. Use Case

Service	Use Case
System functionality	Sequence of actions for an actor’s need and interaction
For customers (buyers) of the system	For users of the system

Artifact: Architecture Description (view of the analysis model)

Contains an architectural view of the analysis model
Depicting the architecturally significant artifacts of the model.
What artifacts are considered architecturally significant

The decomposition of the analysis model into analysis packages and their dependencies, for top-level design.
Key analysis classes
Important use-case realizations

Workers

Worker: Architect

Responsible for the integrity of the analysis model
Ensure that the analysis model as a whole is correct, consistent, and readable.

Worker: Use-case Engineer

Worker: Component Engineer

Responsible for analysis classes

Defines and maintains the responsibilities, attributes, relationships, and special requirements

Ensures that each analysis class fulfills the requirements made on it from the use-case realizations in which it participates.

Responsible for analysis packages

Maintains the integrity of analysis package(s)

Ensures correctness, cohesion, and loose coupling