SRE Lecture 10

Requirements Analysis
Lecture 10
Lecture Outline
• Analysis concepts
• Analysis object models
• Entity
• Boundary
• Control Objects
• The analysis model represents the system under development from
the user’s point of view.
• The analysis object model is a part of the analysis model
• It focuses on the individual concepts that are manipulated by:
• the system,
• their properties
• their relationships
• The analysis object model, depicted with UML class diagrams,
includes classes, attributes, and operations
Entity Objects
• Entity objects represent the persistent information tracked by the
system.
• In the 2Bwatch example, Year, Month, and Day are entity objects;
Boundary objects
• Boundary objects represent the interactions between the actors and
the system.
• Button and LCDDisplay are boundary objects;
Control Objects
• Control objects are in charge of realizing use cases.
• ChangeDateControl is a control object that represents the activity of
changing the date by pressing combinations of buttons.
• The threeobject-type approach also leads to models that are more
resilient to change:
• the interface to the system (represented by the boundary objects) is
more likely to change than its basic functionality (represented by the
entity and control objects).
• By separating the interface from the basic functionality, we are able
to keep most of a model untouched when, for example, the user
interface changes, but the entity objects do not.
UML representation of analysis objects
Analysis classes for the 2Bwatch example

Analysis Activities: from Use Cases to
Objects
1. Identifying Entity Objects
2. Identifying Boundary Objects
3. Identifying Control Objects
4. Mapping Use Cases to Objects with Sequence Diagrams
5. Modeling Interactions among Objects with CRC Cards
6. Identifying Associations
7. Identifying Aggregates
8. Identifying Attributes
9. Modeling State-Dependent Behavior of Individual Objects
Identifying entity objects
• 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 track (e.g., FieldOfficer,
Dispatcher, Resource)
• Real-world activities that the system needs to track (e.g.,
EmergencyOperationsPlan)
• • Data sources or sinks (e.g., Printer)
Identifying entity objects contd..
• Developers name and briefly describe the objects, their attributes,
and their responsibilities as they are identified.
• For entity objects we recommend always to start with the names
used by end users and application domain specialists.
• Describing objects, even briefly, allows developers to clarify the
concepts they use and avoid misunderstandings.
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 a form that can be used by both entity and control
objects.
• Boundary objects model the user interface at a coarse level.
• They do not describe in detail the visual aspects of the user interface.
Identifying Boundary Objects contd..
• For example, boundary objects such as “menu item” or “scroll bar”
are too detailed.
• Updating the analysis model for every user interface change is time
consuming and does not yield any substantial benefit.
Heuristics for identifying boundary objects
1. Identify user interface controls that the user needs to initiate the
use case (e.g., ReportEmergencyButton).
2. Identify forms the users needs to enter data into the system (e.g.,
EmergencyReportForm).
3. Identify notices and messages the system uses to respond to the
user (e.g., AcknowledgmentNotice).
4. When multiple actors are involved in a use case, identify actor
terminals (e.g., DispatcherStation) to refer to the user interface
under consideration.
Heuristics for identifying boundary objects
contd..
5. Do not model the visual aspects of the interface with boundary
objects (user mock-ups are better suited for that).
6. Always use the end user’s terms for describing interfaces; do not
use terms from the solution or implementation domains.
Identifying Control Objects
• Control objects are responsible for coordinating boundary and entity
objects.
• Control objects usually do not have a concrete counterpart in the real
world.
• Often a close relationship exists 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.
Identifying Control Objects contd..
• For example
control objects describe the behavior associated with the sequencing of forms,
undo and history queues, and dispatching information in a distributed system.
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 cover the 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 probably does not have well-defined
entry and exit conditions.

SRE Lecture 10

Uploaded by

Copyright:

Available Formats

SRE Lecture 10

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRE Lecture 10

Uploaded by

Copyright:

Available Formats

Requirements Analysis

Analysis classes for the 2Bwatch example

You might also like