Page 141 - Software and Systems Requirements Engineering in Practice

108 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

• There will be at least one message on a defining sequence
diagram with the same name as each extending use case.
• Every actor interface or boundary communication will
appear on at least one sequence diagram.
• Any entities shown attached to a use case will appear as an
item being passed (message argument) on at least one
sequence diagram or as an object on an activity diagram.

Extending Use Case Relationships Can Only Exist
Between Like Use Cases
The extending relationship is a specialized extension to a well-defined
process. As such, both the extending and extended use cases must be
of the same type. Using the extending relationship where one of the
use cases is abstract and the other is concrete leads to ambiguity. For
example, extending “manage documents” with “place document
under configuration management” is ambiguous, as we don’t know
whether a new or existing document is being placed under
configuration management.

A Concrete Use Case Cannot Include an Abstract Use Case
The rationale is the same as for the extending relationship. A concrete
use case that includes an abstract use case is ambiguous; e.g., it cannot
be defined.

Avoid Realization Relationships and Artifacts
in the Analysis Model
Realization relationships have different meanings, depending on the
context in which they are used. This can lead to ambiguity and
confusion. A realization relationship between two use cases means
that one of the use cases “implements” the other use case. Realization
of a use case by a sequence diagram indicates that the sequence
diagram explains the use case process.

Business Object Modeling
Business object modeling is the process of describing behavior in a
domain. By describing the behavior of the subject areas associated
with feature-level requirements, we expose details of the subject area,
and by doing so we elicit requirements and business rules. During
the analysis modeling effort, classes are sometimes referred to as
“business objects,” not to be confused with the objects on sequence
and collaboration diagrams that are class instances. Defining classes
for objects as they are discovered will keep the effort focused on the
domain processes (as opposed to data).