Page 144 - Software and Systems Requirements Engineering in Practice

C h a p t e r 4 :
R e q u i r e m e n t s M o d e l i n g
C h a p t e r 4 : R e q u i r e m e n t s M o d e l i n g 111 111
A Concrete Class Must Be Instantiated
If a concrete class is not instantiated, it means that the class is not
used in any processes; e.g., it does not appear on a sequence, activity
or collaboration diagram. The question then arises, if it is not used,
why is it in the model?

A Boundary or Interface Class Is Properly Defined If and Only If It
Has Public Methods, and Each of These Methods Is Shown on a
Sequence or Collaboration Diagram
This heuristic is self-explanatory. Missing public methods (services)
in a boundary or interface are typically an oversight.
Every Business Object Service (i.e., Class Method)
Should Be Defined
Class methods are typically defined using a state or activity diagram.
A state diagram is used when the logic is “event driven,” and an
activity diagram is often used when the logic is procedural.

Every Actor in the Model Should Communicate
with Use Cases Through Boundaries
At the context level we identify all the actors associated with the
domain being modeled. However, in order to adequately explain
the nature of the communication, at some point every actor–use case
interaction must take place through a boundary.

Using Boundaries as Proxies for External Objects
During a project to create a medical billing system for a hospital, we
observed that the scheduling function was out of scope, yet scheduling
services were needed. A “scheduling system” boundary was created as
a catchall, and in any scenario where scheduling was needed, a message
would be sent to the scheduling system requesting a service, along
with the supplied and returned information. As the modeling effort
neared completion, the project manager for the scheduling system
development effort approached our team and inquired about what
scheduling services the billing system would need. She was shocked
when within five minutes we were able to generate a complete report
showing all scheduling services needed by medical billing, which
billing system actors used the service, and what scenarios (context)
they were used in. Even though the model had over eight hundred use
cases and several thousand diagrams, such complex queries were
a relatively simple matter as the model had been designed with scale
in mind.