Information Technology Reference
In-Depth Information
Stakeholders and Interests:
Cashier: wants fast and accurate payment, does not want errors in
processing of transactions as it costs them personally.
Salesperson: desires commissions processing.
Fig. 13.7
Stakeholders and interests list adapted from Larman ( 2005 )
scenarios are explored, but some of the more remote cases are normally omitted. In
a casual scenario the outline form is translated to well-structured English para-
graphs. This setup requires slightly more detail to be added to create a compre-
hensive flow of a written scenario. The final version is what is called fully dressed.
After several brief and casual use cases are identified, this version is constructed.
Trying to increase the verbosity of the system explanation, preconditions and
success guarantees should be added (Larman 2005 ). The following is an extract of
a use case from ''Applying UML and Patterns'', by Craig Larman (Fig. 13.8 ).
13.3.3 Use Case Diagrams
The use case diagram is a powerful diagram in automated code generation tools.
For practical purposes use case diagrams extract the pertinent and necessary
information from use case scenarios and present it in a fashion that is not only
extremely simple to understand, but is also very easily converted to code through
the use of UML code tools. As use case models are described heavily elsewhere in
this text, the following example will briefly enumerate the cashier actor from
Fig. 13.9 in a use case diagram in order to demonstrate how a written scenario, as
shown in Fig. 13.8 , can be turned into a graphical representation.
13.3.4 Class and Object Diagrams
No specification would be complete without a modeling of the objects and classes
that are going to be used to compose the software. A comprehensive set of class
and object diagrams are the last specification tasks before coding begins. Class and
object diagrams are more valuable than maybe first expected. Besides from the fact
that they are invaluable when you begin coding, if you are developing a system in
one of the many object oriented languages supported, there are multiple tools that
are capable of rendering your diagrams as source code. This eliminates many of
the trivial tasks of typing what is deemed to be shell code (the classes, method and
attributes), allowing for directly proceeding to inner workings of the methods and
classes. Class diagram notation has been covered in great detail later, but to keep
Search WWH ::




Custom Search