Object-Oriented Analysis and Design
Study Notes

Reposted with permission from the original author:
Ezequiel Cuellar of CrossLogic Corporation http://www.crosslogic.com

Actor

• Is something with behavior such as person, computer system or organization.
• Actors are classified as:
  • Primary actor has user goals fulfilled through using services of the system under development.
  • Supporting actor provides a service to the system under development.
  • Offstage actor has "somehow" an interest in the behaviour of the use case.
• Actor is a role that a user plays with respect to the system.
• When dealing with actors is important to think about roles rather than people or job titles.
• Actors carry out use cases.
• A single actor may perform many use cases and many roles.

Scenario

• Is a specific sequence of actions and interactions between actors and the system.
• A scenario is also called use case instance.

Use Case

• Is a collection of related success and failure scenarios that describe an actor using a system to satisfy a specific goal. It must return an observable result of value to a particular actor.
• Use cases drive the whole development process.
• Use cases are not object-oriented.
• Use cases represent an external view of the system.
• Use case types:
  • Fully Dressed: The most elaborate.
  • Causal: Informal paragraph format.
  • Brief: One paragraph summary.
• Black-box Use cases are the most recommended type to write during analysis, they don't describe the internal workings of the system, its components or design. Rather the system is described as having responsibilities.
• Black-box behaviour is a description of "what" the system does, without explaining "how" it does it.
• Use cases should be written and named at the domain level in requirements.
• EBP (elementary business processes) guideline:
  • A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.
  • Higher-level user goals are discovered using the EBP guideline in order to define use cases.
  • A common use case mistake is defining many use cases at too low level; that is as single step, sub-function, or subtask within the EBP.
  • Many use cases can exist that fail the EBP test, they potentially exist at lower level.

• A use case should be defined for each user goal.
• A low-level user goal is called sub-function goal. Use cases should only occasionally be written for these sub-function goals.
• The system boundary can be found by defining what is outside (the external primary and supporting actors).
• The recommended procedure to write use cases is:
  • Choose the system boundary.
  • Identify the primary actors. Those that have user goals fulfilled through using services of the system.
  • Identify user goals. Raise them to the highest user goal level that satisfies the EBP guideline.
  • Define use cases that satisfy user goals.
• Use case names should start with a verb and should match the user's goal name.
• CRUD requirements should be in a single use case named Manage <X>.
• During early requirements work the use cases should be written in an "Essential Style" keeping the user interface out and focus on the actor's intent.
• During later steps use cases may be written in a "Concrete Style" embedding UI details in the use case text.
• The "System Analyst" is responsible for requirements definition and the "Requirements Specifier" who usually are end users and developers help writing use cases.
• Include Relationship represents some partial behaviour that is common across several use cases. Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition.
• Use Case Generalization occurs when you have one use case that is similar to another use case but does a bit more.
• Use Extend when you are describing a variation on normal behaviour and you wish to use a more controlled form declaring extension points in your base use case. The extending use case can't be modified so is necessary to create a sub use case that extends it.
• Factor out sub-function use cases and use the include relationship when:
  • They are duplicated in other use cases or a use case is very complex and long
  • and separating it into subunits adds comprehension.
• A System Use Case is an interaction with the software whereas a business use case discusses how a business responds to a customer or an event.
• The extending use case is divided in two sections:
  • the name section and
  • the extension points section. A <<extend>> stereotype may be used.
• Use Cases sections:
  • Preface Elements: Contains preface elements.
  • Stakeholders (Actors) and Interests List: Provides the interests of each Actor, i.e. Salesperson: Wants sales commissions updated.
  • Preconditions: State what must always be true before beginning a scenario in the use case. Preconditions are not tested within the use case, rather they are assumed to be true.

• The scenario records the following steps:
  • An interaction between actors.
  • A validation (usually by the system).
  • A state change by the system.

• Extension (or Alternate Flows):

Special Requirements

• Contains any non-functional requirement, quality attribute or constraint that relates to a use case it must be recorded here.

Technology and Data Variations List

• Contains any technical variations in how something must be done.

Operation Contacts

• Contracts are defined for system operations and help define system behaviour in terms of state changes to objects in the Domain Model.
• Contracts are helpful to record fine-grained details and complexity of required state changes that are awkward to capture in Use Cases.
• Contracts are written during elaboration phase.
• Contract sections are:
  • Operation: Name of operation and parameters.
  • Cross References: (optional) Use cases this operation can occur within.
  • Preconditions: Assumptions about the state of the system or objects in the Domain Model before execution of the operation. These will not be tested, are assumed to be true.
  • Post-conditions: Describe changes in the state of objects in the Domain Model after the system operation was executed. Post-conditions are not actions to be performed during the operation; rather they are declarations about the Domain Model objects that are true when the operation has finished.

• Guidelines: Contracts.
  • Identify system operations for the SSDs.
  • For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract.
  • To describe the post-conditions use the following categories:
    • Instance creation and deletion.
    • Attribute modification.
    • Associations formed and broken.
    • Post-conditions must be written in past sense.

Design by Contract

• An assertion is a boolean statement that should never be false an therefore will only be false because of a bug.
• Design by Contract uses three kinds of assertions:
  • Pre-condition is a statement of how we expect the world to be before we execute an operation.
  • Post-condition is a statement of what the world should look like after the execution of an operation.
  • An invariant is an assertion about a class. The invariant is always true for all instances of the class. In essence this means that the invariant is added to pre-conditions and post-conditions associated with all public operations of the given class.

Glossary (Data Dictionary)

• Is a list of noteworthy terms and their definitions. The goal is not to record all possible terms but those that are unclear, ambiguous or which require some kind of noteworthy elaboration such as format information rules.

Credits:

Reposted with permission from the original author:
Ezequiel Cuellar of CrossLogic Corporation http://www.crosslogic.com

Contributors:

• cfw
• SZ