ANALYSIS - II

REQUIREMENT

ANALYSIS

DESIGN

IMPLEMENTATIONTEST

Use Case Realization

Collaboration within the analysis model. Describes how a specific usecase is realized and

performed in terms of analysis classes and their interacting objects.

Focus is on the functional requirements. Postpones the handling of the non-functional

requirements until subsequent design and implementation activates by designating them as special requirements on the realization.

Use case realization - contains

Analysis Class

Use Case Realization - Analysis

Flow of Events-AnalysisClass Diagrams

Interaction DiagramsSpecial Requirements

Class Diagrams

Analysis classes and objects. The above can exist in several usecase

realizations. Responsibilities, attributes and associations of a

specific class are often relevant to only one usecase realization.

Coordinate all the requirements on a class and its objects that different use-case realization may have.

Class Diagram

Interaction Diagram

A Sequence of action in a usecase begins when an actor invokes the usecase by sending some form of message. To the System.

Actions (Collaboration Diagram): Focus on finding requirements requirements and

responsibilities on object and NOT to find detailed and chronological sequence of action. Boundary object receives message from actor. Boundary object sends a message to some other

object inside the system

Collaboration Diagram - Ex

Creation & Termination of analysis objects

Boundary Object: Need not be specific to one usecase realization. Boundary objects are often created and terminated

within a single usecase realization

Entity Objects Not Specific to one usecase realization Long Lived and participates in several usecase

realizations before it is terminated.

Creation & Termination of analysis objects

Control Objects: Encapsulates control related to a specific usecase. Hence created when the usecase starts and

terminated when the usecase ends. Exceptions :

Control Classes participate in more than one usecase_r. Several control classes participate in one usecase_r. Usecase_r does not use any control class at all.

Flow of Events

Additional text used to explain the Collaboration Diagram.

Pertains particularly to Control Objects Does not mention any of the object

responsibilities, attributes and associations.

Special Requirements

Textual description that collect all non-functional requirements.

Identified primarily during Requirements, however some may be new or derived requirements found during the analysis work flow.

Examples: When a buyer asks to see view received invoices, it

should not take more than 0.5 seconds to show the invoice on the Screen.

Invoice should using the SET Standard.

Analysis Packages

Means of organizing the artifacts of the analysis model in manageable pieces.

Consists of analysis classes, usecase realization-analysis and other service packages.

They are highly cohesive and loosely coupled.

Analysis Packages - Characteristics

Represent a separation of Analysis Concern.

Created based on functional requirements. Recognizable by people with domain

knowledge. Likely to become subsystems in two top

layers of Design Model.

Service Packages

Set of service to the customer. A customer requires a suitable mix of services to give its users the necessary usecase to carry out the business.

A service represents a coherent set of functionally related actions – a package of functionality.

Usecases are for users and services are for customers. Used at lower level of analysis package hierarchy to

structure the system according to the services it provides. Are reusable.

Architectural Description

Architectural description of the Analysis Model depicting its architecturally significant artifacts: Decomposition of Analysis Model into

analysis packages. Key analysis classes. Usecase realization that realizes some

important and critical functionality.

Workflow – Architectural Analysis

The purpose of the architectural analysis is to outline the analysis model and architecture by identifying analysis packages, obvious analysis classes and common analysis requirements.

Identifying Analysis Packages

An initial identification of analysis package is naturally done based on the functional requirement and problem domain.

They can either be identified initially by a way of dividing the analysis work or to be found as the model evolves and “grows” into a large structure which needs to be decomposed.

Identifying Analysis Packages

Since we capture functional requirements as usecases a straight way to analyze a analysis package is to allocate the main portion of a number of usecases to a specific package and realize the corresponding functionality within the package. Usecases required to support a specific business

process. Usecases required to support a specific actor of the

system. Usecases that are related.

Handling Commonality

It is often the case that commonalities can be found among packages as identified in the proceeding section. An appropriate way to handle this is to extract the shared class and put it into its own package or other packages and let other packages be dependent on this more general package or class.