and flesh out the logic of a usage scenario. A usage scenario is exactly what its name indicates -
the description of a potential way that your system is used.The logic of a usage scenario may be part of a use case, perhaps an
alternate course; one entire pass through a use case, such as the logic
described by the basic course of action or a portion of the basic course of
action plus one or more alternate scenarios; or a pass through the logic
contained in several use cases, for example a student enrolls in the
university then immediately enrolls in three seminars.
your design because they provide a way for you to visually step through
invocation of the operations defined by your classes.
detect bottlenecks within an object-oriented design.By looking at what messages are being sent to an object, and by
looking at roughly how long it takes to run the invoked method, you quickly
get an understanding of where you need to change your design to distribute
the load within your system.In
fact some CASE tools even enable you to simulate this aspect of your
you a feel for which classes in your application are going to be complex,
which in turn is an indication that you may need to draw state chart
diagrams for those classes.
Important: Naming conventions for operation signatures,
guidelines that are pertinent to naming messages, parameters, and return values,
are described in detail in
Guidelines for UML Class Diagrams.
Justify Message Names Beside the Arrowhead
Create Objects Directly
Apply Operation Signatures for Software Messages
Use Prose for Messages Involving Human and Organization Actors
Prefer Names Over Types for Parameters
Indicate Types as Parameter Placeholders
Messages to Classes are Implemented as Static Operations
Apply the <<include>> Stereotype for Use Case Invocations