4. oose analysis

Object-Oriented Software Engineering

Chapter 4

Object Oriented Analysis

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

An Overview of Analysis

Analysis focuses on producing a model of thesystem, called the analysis model, which iscorrect, complete, consistent, and

verifiable.Developers focus on structuring and

formalizing the requirements elicited fromusers

In object-oriented analysis, developers build amodel describing the application domain.


Products of requirements elicitation and analysis (UML activity diagram).




Analysis Model

The analysis model is composed of threeindividual models:• Functional model

– represented by use cases and scenarios,

• Analysis object model– represented by class and object diagrams,

• Dynamic model• represented by state chart and sequence

diagrams



Analysis Model

Stereotype Mechanism• Stereotype mechanism is used to

distinguish between differenttypes of objects in UML .enables the developer toattach meta info

• Boundary objects may have thesuffix <<Boundary>> appendedto their name;

• Control objects may have thesuffix <<Control>> appended totheir name;

• Entity objects usually do not haveany suffix appended to theirname sometimes <<entity>>


Analysis ConceptsEntity, Boundary, and Control Objects

• Entity objects represent the persistent informationtracked by the system. The main responsibilities of entityclasses are to store and manage information in the system

• Boundary objects represent the interactions between theactors and the system.

• Control objects represent the tasks that are performed bythe user and supported by the system

• The interface to the system (represented by boundaryobjects) is more likely to change than its basicfunctionality (represented by the entity and controlobjects).





Role of boundary class


Modeling the system with entity, boundary, andcontrol objects has several advantages.

1. First, It provides developers with simple heuristics todistinguish different, but related concepts bydifferentiating between boundary and entityobjects

2. Second, the three object type approach results insmaller and more specialized objects.

3. Third, the three object type approach leads tomodels that are more resilient to change:


Analysis ConceptsEntity, Boundary, and Control Objects

Analysis classes for the 2Bwatch example.


Association Multiplicity Revisited• In Modeling with UML, the end of an association can

be labeled by a set of integers called multiplicity.• Multiplicity indicates the number of links that can

legitimately originate from an instance of the classconnected to the association end


An example of multiplicity of associations (UML class diagram). A 2B watch has two buttons and one LCD Display.

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

A one-to-one association between two classes (e.g., PoliceOfficer and BadgeNumber), means that

exactly one link exists between instances of eachclass (e.g., a PoliceOfficer has exactly oneBadgeNumber, and a BadgeNumber denotes exactlyone PoliceOfficer).


A one-to-many association has a multiplicity 1on one end and 0..n (also represented by * astar) or 1..n on the other.

A one-to-many association between two classes(e.g., a FireUnit owns one or more FireTrucks, aFireTruck is owned exactly by oneFireUnit).


One-to-Many Association

A many-to-many association has a multiplicity 0..n or 1..non both ends.

A many-to- many association between two classes (e.g.,FieldOfficer and IncidentReport) denotes that an arbitrarynumber of links can exist between instances of the twoclasses

(e.g., a FieldOfficer can write for many IncidentReport, anIncidentReport can be written by many FieldOfficers).

Adding multiplicity to associations increases theamount of information we capture from theapplication or the solution domain


Many-to-Many Association




Qualified Associations –Text Example 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. For example, in a hierarchical file system,

Each file belongs to exactly one directory.

Each file is uniquely identified by a name in the context of adirectory.

Many files can have the same name in the context of the filesystem;

however, two files cannot share the same name within the samedirectory.


Without qualification, the association betweenDirectory and File has a one multiplicity on theDirectory side and a zero-to-many multiplicity on theFile side.

We reduce the multiplicity on the File side by usingthe filename attribute as a key, also called a qualifier

The relationship between Directory and File is calleda qualified association


Qualified Associations

Generalization Generalization enables us to organize concepts into

hierarchies.At the top of the hierarchy is a general concept (e.g.,

an Incident)At the bottom of the hierarchy are the most

specialized concepts (e.g., CatInTree,TrafficAccident, BuildingFire, EarthQuake,ChemicalLeak).

There may be any number of intermediate levels inbetween, covering more-or-less generalized concepts(e.g., LowPriorityIncident, Emergency, Disaster). .



Generalization



Analysis Activities: From Use Cases to Objects

Analysis activities include: identifying entity objects identifying boundary objects identifying control objects mapping use cases to objects identifying associations among objects identifying object attributes reviewing the analysis model




Identifying Entity ObjectsHeuristics for identifying entity objects

Developers or users need entity objects to clarify inorder 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) Use cases (e.g., ReportEmergency) Data sources or sinks (e.g., Printer)


Use case name ReportEmergency

Entry condition The FieldOfficer activates the “Report Emergency” functionof her terminal

Flow of events FRIEND responds by presenting a form to the officer The FieldOfficer fills the form, by specifying minimally

the emergency type and description fields. Once the formis completed, the FieldOfficer submits the form bypressing the “Send Report” button, at which point, theDispatcher is notified.

The Dispatcher reviews the information submitted by theFieldOfficer and creates an Incident in the database byinvoking the OpenIncident use case. acknowledges theemergency report by sending a FRIEND gram to theFieldOfficer

Exit condition The FieldOfficer receives the acknowledgment and the selected response.

Entity objects for the ReportEmergency use case

Dispatcher Police officer who manages Incidents,documents, and closes Incidents in response toEmergency Reports and other communicationwith FieldOfficers.

Dispatchers are identified by badge numbers.

EmergencyReport Initial report about an Incident from aFieldOfficer to a Dispatcher.

An EmergencyReport usually triggers thecreation of an Incident by the Dispatcher.

An EmergencyReport Is composed of aemergency level, a type (fire, road accident, orother), a location, and a description.



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 an interface neutralform that can be used by the entity objects and alsoby the control objects.

Boundary objects model the user interface. They do not describe in detail the visual aspects

of the user interface.


Heuristics for identifying boundary objects

Identify forms and windows the users needs to enter data intothe system (e.g.,EmergencyReportForm, ReportEmergencyButtonForm).

Identify notices and messages the system uses to respond to theuser (e.g.,AcknowledgmentNotice).

Do not model the visual aspects of the interface with boundaryobjects [ user mock-ups are better suited for that).

Always use the user’s terms for describing interfaces as opposedto terms from the implementation technology.


Boundary objects for the ReportEmergency use case


Identifying Control Objects Control objects are responsible for coordinating

boundary and entity objects. There is often a close relationship between a use case

and a control object. 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. For example, control objects describe the behavior

associated with the sequencing of forms, undo andhistory queues, and dispatching information in adistributed system


Heuristics for identifying control objects

• Identify one control object per use case or more if theuse case is complex and if it can be divided intoshorter flows of events.

• 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 usecase may not have a well-defined entry and exitcondition.


Control objects for the ReportEmergency use case

ReportEmergencyControl

Manages the report emergency reporting function onthe FieldOfficer Station.

This object is created when the FieldOfficer selects the“Report Emergency” button.

It then creates an EmergencyReport Form and presentsit to the FieldOfficer.

After submission of the form, this object then collectsthe information from the form, creates anEmergencyReport, and forwards it to the Dispatcher.

The control object then waits for an acknowledgmentto come back from the DispatcherStation.

When the acknowledgment is received, theReportEmergency Control object creates anAcknowledgmentNotice and displays it to theFieldOfficer.


Modeling Interactions Between Objects Sequence Diagrams

A sequence diagram ties use cases with objects shows how the behavior of a use case (or scenario) is

distributed among its participating objects. usually not a good medium for communication with the

user.allow the developers to find missing objects or grey

areas in the system specification.are used to help identify new participating objects and

missing behavior. focus on high-level behavior, and, thus, implementation

issues such as performance should not be addressed atthis point.


Heuristics for drawing sequence diagrams

• The first column should correspond to the actor whoinitiated the use case.

• The second column should be an boundary object (that theactor used to initiate the use case).

• The third column should be the control object thatmanages the rest of the use case.

• Control objects are created by boundary objects initiatinguse 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.


Sequence diagram for the ReportEmergency use case (initiation from the FieldOfficer Station side).


The columns of a sequence diagram represent the objects thatparticipate in the use case.

The leftmost column is the actor who initiates the use case. Horizontal arrows across columns represent messages, or stimuli,

which are sent from one object to the other. Time proceeds vertically from top to bottom. For example, the arrow in Figure represents the press message sent

by a FieldOfficer to an ReportEmergencyButton The receipt of a message triggers the activation of an operation. The activation is represented by a rectangle from which other

messages can originate. The length of the rectangle represents the time the operation is

active


Sequence diagram for the ReportEmergency use case (initiation from the FieldOfficer Station side).

Sequence diagram for the ReportEmergency usecase (Acknowledgement on FieldOfficerStation).


Sequence Diagram – Student Example


52

Sequence Diagrams

• Show classifier roles only (no association roles).• The vertical dimension is the time and the messages

are drawn from top to bottom, in the order they are sent.

• Each role has a lifeline:– indicating the period of time during which objects playing

that role exist.– Syntax: vertical dashed line below the classifier role.

• Messages are shown as arrows leading from the lifeline of the message’s sender to that of the receiver.

53

Sequence Diagrams

• The period of time during which an object is processing a message is called activation.– Syntax: narrow rectangle whose top is connected to a message.

• When an object finishes processing a message, the control returns to the sender of the message.– Syntax: dashed arrow from the bottom of activation rectangle back

to lifeline of the role that sent the message.

• The messages with solid arrowhead denote synchronousmessages, such as normal procedure calls (the object that sends the message is suspended until the called object returns the control to the caller).

54

Sequence Diagram: Simple Example

• Suppose statements are to be printed for bank accounts:– Bank passes the relevant Account to a Statement object

for printing.

Sequence Diagram

Identifying Associations• An association shows a relationship between

two or more classes.• For example, a FieldOfficer writes an

EmergencyReport


First, it clarifies the analysis model by makingrelationships between objects explicit (e.g., an EmergencyReport can be created by a FieldOfficer

or a Dispatcher).

Second, it enables the developer to discoverboundary cases associated with links.

Boundary cases are exceptions that need to beclarified in the model.


Advantages of identifying Associations

Properties of Associations A name, to describe the association between the two classes Association names are optional and need not be unique

globally.

A role at each end, identifying the function of each class withrespect to the associations (e.g.,author is the role played by FieldOfficer in the

Writesassociation).

A multiplicity at each end, identifying the possible number ofinstances (e.g., * indicates a FieldOfficer may write zero or more

EmergencyReports, 1 indicates that each EmergencyReporthas exactly one FieldOfficer as author.


Heuristics for identifying associations1. Examine verb phrases.2. Name associations and roles precisely.3. Use qualifiers as often as possible to identify

namespaces and key attributes.4. Eliminate any association that can be derived from

other associations.5. Do not worry about multiplicity until the set of

associations is stable.6. Avoid ravioli models: Too many associations make a

model unreadable


We identified two relationships: the first between an Incident and the EmergencyReport that

triggered its creation; the second between the Incident and the reporting FieldOfficer.

Given that the EmergencyReport and FieldOfficer already have anassociation modeling authorship, the association between Incidentand FieldOfficer is not necessary.

Adding unnecessary associations complicates the model, leading toincomprehensible “ravioli models” and redundant information.


An Example - identifying associations

Identifying AttributesAttributes are properties of individual objects. Attributes have:

a name identifying them within an object. For example, an EmergencyReport may have a reportType attribute and

an emergencyType attribute.The reportType describes the kind of report being filed (e.g., initial

report, request for resource, final report).The emergencyType describes the type of emergency (e.g., fire,

traffic, other). To avoid confusion, these attributes should not be both called type.

A type describing the legal values it can take. For example, the description attribute of an EmergencyReport is a

string. The emergencyType attribute is an enumeration that can take one of

three values : fire, traffic, other.


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.


Reviewing the Analysis Model The analysis model is built incrementally and iteratively

Once the analysis model becomes stable (i.e., when thenumber of changes to the model are minimal and the scopeof 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 systemspecification is correct, complete, consistent, and realistic.

Note that developers should be prepared to discover errorsdownstream and make changes to the specification.


Analysis Model correct or not ..?The following questions should be asked

to ensure that the model is correct1. Is the glossary of entity objects understandable by the user?2. Do abstract classes correspond to user-level concepts?3. Are all descriptions in accordance with the users’ definitions?4. Do all entity and boundary objects have meaningful noun

phrases as names?5. Do all use cases and control objects have meaningful verb

phrases as names?6. Are all error cases described and handled?7. Are the start-up and the shut-down phases of the system

described?8. Are the administration functions of the system described?


The following questions should be asked to ensure that the model is complete

1. For each object: Is it needed by any use case? In which use case is it created?

modified? destroyed? Can it be accessed from an boundary object?

2. For each attribute: When is it set? What is its type? Should it be a qualifier?

3. 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?4. For each control object:

Does it have the necessary associations to access the objectsparticipating in its corresponding use case?


Analysis Model complete or not ..?

The following questions should be asked to ensure that the model is consistent

1. Are there multiple classes or use cases with the samename?

2. Do entities (e.g., use cases, classes, attributes) withsimilar names denote similar phenomena?

3. Are all entities described at the same level of detail?4. Are there objects with similar attributes and associations

that are not in the same generalization hierarchy?


Analysis Model consistent or not ..?

The following questions should be asked to ensure that the 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?


Analysis Model Realistic or not ..?

Date post:	07-Aug-2015
Category:	Documents
Upload:	ashenafi-workie
View:	58 times
Download:	6 times

4. oose analysis

Documents