0% found this document useful (0 votes)
7 views46 pages

Object Orented Activitys

The document provides an overview of Object Oriented Analysis (OOA), detailing its concepts, activities, and management. It emphasizes the importance of creating a comprehensive analysis model to capture system requirements, distinguishing between analysis and design phases. Key components include identifying entity, boundary, and control objects, as well as developing functional, dynamic, and object models through various diagrams.

Uploaded by

hgenet71
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views46 pages

Object Orented Activitys

The document provides an overview of Object Oriented Analysis (OOA), detailing its concepts, activities, and management. It emphasizes the importance of creating a comprehensive analysis model to capture system requirements, distinguishing between analysis and design phases. Key components include identifying entity, boundary, and control objects, as well as developing functional, dynamic, and object models through various diagrams.

Uploaded by

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

Activity#5: Object Oriented Analysis/OOA

•Analysis concepts
•Analysis Activities
Compiled by Samuel.A
Learning Outcomes

• In this activity, you should be able to define and


understand
– What object oriented analysis is
– The analysis activities
– Analysis management

BiT, O-O Software Engineering


Overview of Analysis

• The first step in finding an appropriate solution to a given


problem is to understand the problem and its domain.

• Analysis capture a complete, unambiguous and consistent


picture of requirements of system and what the system
must do to satisfy the user’s requirements and needs.

BiT, O-O Software Engineering


Cont’d

• Analysis focuses on producing a model of the system,


called the analysis model, which is correct, complete,
consistent, and verifiable.
– Translating a system specification into a formal or semiformal
model forces developers to identify and resolve difficult issues
early in the development

• Analysis is different from requirements elicitation in that


developers focus on structuring and formalizing the
requirements elicited from users

BiT, O-O Software Engineering


Object Oriented Analysis

• Object-oriented analysis emphasizes the building


of real-world models, using an object-oriented view
of the world:
• The goal of OOA is to understand the domain of the
problem and the system’s responsibilities by
understanding how the users use or will use the system.

BiT, O-O Software Engineering


How OOA & OOD related

• OOA
– Emphasizes on finding and describing the objects or
concepts in the problem domain

• OOD
– Emphasizes a conceptual solution that fulfills the
requirements and define objects, their responsibilities and
how they collaborate to fulfill the requirement.

BiT, O-O Software Engineering


Cont’d

• Analysis • Design
– Focuses on understanding • Focuses on
the problem understanding the
– System model solution
– Small model of domain • System structure
concept • A large model of
system dynamic and
static view

BiT, O-O Software Engineering


Cont’d

• Analysis is about discovering what the system is going to


handle, rather than deciding how to do the handling.

• An analysis model has both static and dynamic parts.


– We can depict the static analysis model using a class diagram.
– For the dynamic analysis model, we can use interaction diagrams

BiT, O-O Software Engineering


Why analysis difficult

Three most common sources of requirement difficulties:-


– Fuzzy descriptions
– Incomplete Requirements
– Unnecessary features

BiT, O-O Software Engineering


Analysis Model

• it helps developers verify the system specification


produced during requirements elicitation.

• The analysis model is composed of three individual


models:
– The functional model, represented by use cases and scenarios,
– The analysis object model, represented by class and object
diagrams, and
– The dynamic model, represented by statechart and sequence
diagrams

BiT, O-O Software Engineering


BiT, O-O Software Engineering
Analysis Concepts

• The main analysis concepts used in this activity :


– Analysis Object Models and Dynamic Models
– Entity, Boundary, and Control Objects

BiT, O-O Software Engineering


Analysis Object models and Dynamic models
The analysis object model
• is a part of the analysis model and focuses on the
individual concepts that are manipulated by the system,
their properties and their relationships.
• The analysis object model, depicted with UML class
diagrams, includes classes, attributes, and operations.
• The analysis object model is a visual dictionary of the
main concepts visible to the user.

The dynamic model


• focuses on the behavior of the system.
• The dynamic model is depicted with sequence diagrams
and with state machines.
BiT, O-O Software Engineering
.
Static Analysis

• Static modeling involves deciding on the logical or


physical parts of the system and how they should be
connected together.

• it describes how we construct and initialize the system.

BiT, O-O Software Engineering


Dynamic analysis

• We perform dynamic analysis for the following reasons:


– To confirm that our class diagram is complete and
accurate, so that we can fix it sooner rather than later
– To gain confidence that our modeling can be
implemented in software
– To verify the functionality of the user interfaces that will
appear in the final system:

• According to Jacobson, the most important part of


dynamic analysis is use case realization

BiT, O-O Software Engineering


Entity, Boundary, and Control Objects

• 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 (interface
objects).
– Control objects represent the tasks that are
performed by the user and supported by the system.
• Represent the control tasks performed by the system

BiT, O-O Software Engineering


Identifying entity objects

• As described in Requirements Elicitation, participating


objects are found by examining each use case and
identifying candidate objects.

• Natural language analysis is an intuitive set of heuristics


for identifying objects, attributes, and associations from a
system specification.

• Abbott’s heuristics maps parts of speech (e.g., nouns,


Doing verbs, being verbs, adjectives) to model
components (e.g., objects, operations, inheritance
relationships, Attributes).

BiT, O-O Software Engineering


Abbott’s heuristics for mapping parts of speech to model components

BiT, O-O Software Engineering


Cont’d

• Heuristics for identifying entity objects


– terms that developers or users need to clarify in order to
understand the use case
– recurring nouns in the use cases (e.g., Incident)
– real-world entities that the system needs to keep track of
(e.g., FieldOfficer, Dispatcher, Resource)
– real-world activities that the system needs to keep track of
(e.g., EmergencyOperationsPlan)
– data sources or sinks (e.g., Printer)

BiT, O-O Software Engineering


Identifying Boundary Objects

• 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 form that can
be used by both entity and control objects.

BiT, O-O Software Engineering


• Heuristics for identifying boundary objects
– Identify user interface controls that the user needs to initiate
the use case( e.g.,ReportEmergencyButton)

– Identify forms and windows the users needs to enter data


into the system (e.g., EmergencyReportForm,
ReportEmergencyButtonForm).

– Identify notices and messages the system uses to responds


to the user

– When multiple actors are involved in a use case, identify


actor terminals to refer to the user under consideration

BiT, O-O Software Engineering


Example of boundary objects for the ReportEmergency use case

BiT, O-O Software Engineering


Identifying Control Objects
• It is a kind of algorithm or code that controls the
interaction between boundary and entity objects
• Control objects are responsible for coordinating
boundary and entity objects.
• Control objects usually do not have a concrete
counterpart in the real world.

• A control object is usually created at the beginning of


a use case and ceases to exist at its end.
• It is responsible for collecting information from the
boundary objects and dispatching it to entity objects.

BiT, O-O Software Engineering


• Heuristics for identifying control objects
– Identify one control object per use case
– Identify one control object per actor in the use case.
– The life span of a control object should be extent of the use
case or the extent of a user session. If it is difficult to identify
the beginning and the end of a control object activation, the
corresponding use case may not have a well-defined entry
and exit condition.

BiT, O-O Software Engineering


Mapping use cases to objects with sequence
diagrams/Modeling Interactions Between Objects: Sequence Diagrams
• 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 another shift in perspective and allow the developers
to find missing objects or grey areas in the system specification.

• In general, the second column of a sequence diagram represents the


boundary object with which the actor interacts to initiate the use case
(e.g., ReportEmergencyButton).

• The third column is a control object that manages the rest of the use
case (e.g., ReportEmergency–Control).

• From then on, the control object creates other boundary objects and
may interact with other control objects as well (e.g.,
ManageEmergencyControl) BiT, O-O Software Engineering
Sequence diagram for the ReportEmergency use case

BiT, O-O Software Engineering


Sequence diagram for the ReportEmergency use case
continued…
BiT, O-O Software Engineering
Sequence diagram for the ReportEmergency use case continued…

BiT, O-O Software Engineering


BiT, O-O Software Engineering
• Heuristics for drawing sequence diagrams
– The first column should correspond to the actor who initiated the
use case.
– The second column should be an boundary object (that the actor
used to initiate the use case).
– The third column should be the control object that manages the
rest of the use case.
– Control objects are created by boundary objects initiating use
cases.
– Boundary objects are created by control objects.
– Entity objects are accessed by control and boundary objects.
– Entity objects never access boundary or control objects, this
makes it easier to share entity objects across use cases.

BiT, O-O Software Engineering


Identifying Associations
• sequence diagrams allow developers to represent
interactions among objects over time where as class
diagrams allow developers to describe the
interdependencies of objects.
• An association shows a relationship between two or
more classes.
• For example, a FieldOfficer writes an EmergencyReport

BiT, O-O Software Engineering


• Identifying associations has two advantages. First, it
clarifies the analysis model by making relationships
between objects explicit
• Second, it enables the developer to discover boundary
cases associated with links.
• Boundary cases are exceptions that need to be clarified in
the model.
• For example, it is intuitive to assume that most
EmergencyReports are written by one FieldOfficer.
However, should the system support EmergencyReports
written by more than one? Should the system allow for
anonymous EmergencyReports?
• Those questions should be investigated during analysis by
discussing them with the client or with end users.

BiT, O-O Software Engineering


Identifying Attributes
• Attributes are properties of individual objects. For
example, an EmergencyReport has an emergency type, a
location, and a description property.
• These are entered by a FieldOfficer when he/she reports
an emergency and are subsequently tracked by the
system.

BiT, O-O Software Engineering


• Heuristics for identifying attributes
– Examine possessive phrases.
– Represent stored state as attributes of entity object.
– Describe each attribute.
– Do not represent an attribute as an object, use an association
instead
– Do not waste time describing fine details before the object
structure is stable.

BiT, O-O Software Engineering


Reviewing the analysis model
• The analysis model is built incrementally and iteratively.

• Once the analysis model becomes stable (i.e., when the


number of changes to the model are minimal and the
scope of the changes localized), the analysis model is
reviewed, first by the developers (i.e., internal reviews),
then jointly by the developers and the client.

• The goal of the review is to make sure that the system


specification is correct, complete, consistent, and
realistic.

BiT, O-O Software Engineering


• The following questions should be asked to ensure that the
model is correct:
– Is the glossary of entity objects understandable by the user?
– Do abstract classes correspond to user-level concepts?
– Are all descriptions in accordance with the users’ definitions?
– Do all entity and boundary objects have meaningful noun
phrases as names?
– Do all use cases and control objects have meaningful verb
phrases as names?
– Are all error cases described and handled?

BiT, O-O Software Engineering


• The following questions should be asked to ensure that the
model is complete:
– For each object: Is it needed by any use case? In which use
case is it created? Modified? destroyed? Can it be accessed
from a boundary object?
– For each attribute: When is it set? What is its type? Should it
be a qualifier?
– For each association: When is it traversed? Why was the
specific multiplicity chosen? Can associations with one-to-
many and many-to-many multiplicities be qualified?
– For each control object: Does it have the necessary
associations to access the objects participating in its
corresponding use case?

BiT, O-O Software Engineering


• The following questions should be asked to ensure that the
model is consistent:
– Are there multiple classes or use cases with the same
name?
– Do entities (e.g., use cases, classes, attributes) with
similar names denote similar phenomena?
– Are all entities described at the same level of detail?
– Are there objects with similar attributes and associations
that are not in the same generalization hierarchy?

BiT, O-O Software Engineering


• The following questions should be asked to ensure that the
system described by the analysis model is realistic:
– Are there any novel features in the system? Were there
any studies or prototypes built to ensure their feasibility?
– Can the performance and reliability requirements be met?
Were these requirements verified by any prototypes
running on the selected hardware?

BiT, O-O Software Engineering


Summary: Analysis
• 1. What are the transformations? Functional Modeling
– Create scenarios and use case diagrams
• Talk to client, observe, get historical records, do thought
experiments
2. What is the structure of the system? Object Modeling
Create class diagrams
Identify objects.
What are the associations between them? What is their
multiplicity?
What are the attributes of the objects?
What operations are defined on the objects?
3. What is its behavior? Dynamic Modeling
Create sequence diagrams
Identify senders and receivers
Show sequence of events exchanged between objects. Identify
event dependencies and event concurrency.
Create state diagrams
Only for the dynamically interesting objects.
BiT, O-O Software Engineering 42
Do Analysis
1. Analyze the problem statement
– Identify functional requirements
– Identify nonfunctional requirements
– Identify constraints (pseudo requirements)
2. Build the functional model
– Develop use cases to illustrate functionality requirements
3. Build the dynamic model:
– Develop sequence diagrams to illustrate the interaction
between objects
– Develop state diagrams for objects with interesting
behavior
4. Build the object model:
– Develop class diagrams showing the structure of the
system

BiT, O-O Software Engineering 43


Homework2
1. Consider a file system with a graphical user interface,
such as Microsoft’sWindows Explorer, or Linux’s GNOME.
The following objects were identified from a use case
describing how to copy a file from a Flash disk to a hard
disk: File, Icon, RecycleBin, Folder, Disk, Pointer.
Specify which are entity objects, which are boundary
objects, and which are control objects (if any).
2. Assuming the same file system as before, consider a
scenario consisting of selecting a file on a Flash, dragging
it to Folder (anywhere) and releasing the mouse. Identify
and define at least one control object associated with this
scenario.

BiT, O-O Software Engineering 44



3. Arrange the objects listed in Exercises 1 and 2 above
horizontally on a sequence diagram, putting actor to the
first column, then the boundary objects, then the control
object you identified, and finally, the entity objects. Draw
the sequence of interactions resulting from dropping the
file into a folder. For now, ignore the exceptional cases.

BiT, O-O Software Engineering 45


Possible Answer
1).
Entity objects: File, Folder, Disk
Boundary objects: Icon, Pointer, RecycleBin
Control objects: none in this example.
2).
CopyFile control object, which is responsible for:
1. Remembering the path of the destination folder
2. Checking if the file can be copied (access control and
disk space).
3. Remembering the path of the original file
4. To initiate the file copying.
BiT, O-O Software Engineering 46
3.

BiT, O-O Software Engineering 47


Question & Answer

BiT, O-O Software Engineering 48

You might also like