Scribd
Upload
56 views19 pages

Chapter 5 - Analysis

Uploaded by

Ayano Boresa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
56 views19 pages

Chapter 5 - Analysis

Uploaded by

Ayano Boresa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 19

Hawassa University Bensa Daye

Campus
DEPARTMENT OF COMPUTER
SCIENCE

Software Engineering (InSy3033)

Chapter five

Analysis

Compiled by Talegeta G.
1
Topics Covered

 Analysis Concepts
 Entity, Boundary, and Control Objects
 Association Multiplicity Revisited
 Qualified Associations
 Generalization
 Analysis Activities: From Use Cases to Objects
 Identifying Entity Objects
 Identifying Boundary Objects
 Identifying Control Objects
 Modeling Interactions between Objects: Sequence Diagrams
 Identifying Associations.
 Identifying Attributes
 Reviewing the Analysis Model
 Documenting Analysis
Analysis Concepts(Entity, Boundary, and Control
Objects)
3

 The analysis object model consists of entity, boundary, and control


objects.

Entity objects
 Represent the persistent information tracked by the system.

Boundary objects
 represent the interactions between the actors and the system.

Control objects
 Represent the tasks that are performed by the user and supported
Analysis Concepts(Association Multiplicity
Revisited)
4

 Modeling with UML the end of an association can be labeled by a


set of integers called multiplicity.
 The multiplicity indicates the number of links that can legitimately
originate from an instance of the class connected to the association
end.

There are three types of associations:

1.A one-to-one Association: has a multiplicity 1 on each end.


 A one-to-one association between two classes means that exactly
Analysis Concepts(Association Multiplicity
Revisited)
5

2.A one-to-many association: has a multiplicity 1 on one end and 0..n


(also represented by a star) or 1..n on the other.

3.A many-to-many association has a multiplicity 0..n or 1..n on both


ends.
Analysis Concepts(Qualified Associations: Reducing
Multiplicity)
6

 Qualification is a technique for reducing multiplicity by using keys.


 Associations with a 0..1 or 1 multiplicity are easier to understand than
associations with a 0..n or 1..n multiplicity.
 Often, in the case of a one-to-many association, objects on the “many”
side can be distinguished from one another using a name.
 E.g
Analysis Concepts(Generalization)
7
 Generalization enables to organize concepts into hierarchies.
 At the top of the hierarchy is a general concept and at the bottom of
the hierarchy are the most specialized concepts.
 There may be any number of intermediate levels in between,
covering more-or-less generalized concepts.
Analysis Activities: From Use Cases to Objects
8

The activities that transform the use cases and scenarios produced
during requirements elicitation into an analysis model.
 Identifying entity objects

 Identifying boundary objects

 Identifying control objects

 Mapping use cases to objects

 Identifying associations among objects

 Identifying object attributes

 Modeling generalization relationships

 Reviewing the analysis model


Analysis Activities: Identifying Entity Objects
9

 During Requirements Elicitation, participating objects are found by examining


each use case and identifying candidate objects.
 Natural language analysis [Abbott, 1983] is an intuitive set of heuristics for
identifying objects, attributes, and associations from a system specification.
Analysis Activities: Identifying Boundary Objects
10

 Boundary objects represent the system interface with the actors.


 In each use case, each actor interacts with at least one boundary
object.
 The boundary object collects the information from the actor and
translates it into an interface neutral form that can be used by the
entity objects and also by the control objects.
Analysis Activities: Identifying Control Objects
11

 Control objects are responsible for coordinating boundary and


entity objects.
 Control objects usually do not have a concrete counterpart in
the real world.
 There is often a close relationship between a use case and a
control object.
 Control objects is responsible for collecting information from
the boundary objects and dispatching it to entity objects
Analysis Activities: Interactions Between Objects:
Sequence Diagrams
12

 A sequence diagram ties use cases with objects.


 It shows how the behavior of a use case (or scenario) is distributed
among its participating objects.
 They represent, however, another shift in perspective and allow the
developers to find missing objects or grey areas in the system
specification.
Identifying Associations

 An association shows a relationship between two or more classes.


Associations have several properties:
 Name: to describe the association between the two classes.
 Association names are optional and need not be unique globally.
 Role at each end, identifying the function of each class with respect to the
associations (e.g., author is the role played by FieldOfficer in the Writes
association).
 A multiplicity at each end, identifying the possible number of instances
Identifying Attributes

 Attributes are properties of individual objects.

Attributes have:
 A name identifying them within an object
 A brief description.
 A type describing the legal values it can take.
Analysis Activities: Modeling Generalization
Relationships Between Objects
15

 Generalization is used to eliminate redundancy from the analysis


model.
 If two or more classes share attributes or behavior, the similarities
are consolidated into a superclass.
Reviewing the Analysis Model

 The analysis model is built incrementally and iteratively.


 The analysis model is seldom correct or even complete on the first
pass.
 Several iterations with the client and the user are necessary before
the analysis model converges toward a correct specification usable
by the developers for design and implementation.
Documenting Analysis

 The RAD(Requirement Analysis Documenting ), once completed


and published, will be baseline and put under configuration
management.
 The revision history section of the RAD will provide a history of
changes including the author responsible for each change, the date
of the change, and brief description of the change.
Cont.…
19

You might also like