Google
 

 

up previous next contents
Up: 1. Day 1: Object-Oriented Previous: 1.6 The Rational Unified Next: 1.8 Agile Methods   Contents

Subsections

1.7 A sample process

The next several sections provide an outline of a sample object-oriented software development process. Specifically, this process is based on the text ``Use Case Driven Object Modeling with UML, A Practical Approach'' by Rosenberg and Scott[4]. This is a real process, based on the theory outlined in the Rational Unified Process.

1.7.1 Domain modeling

First guess at domain objects.

1.7.1.1 What is a class?

  • A class is a template for creating objects.
  • A class defines the attributes and behaviors an object will have.
  • An object is a specific instance of a class.
  • If an object has no attributes, is it really a valid object?

1.7.1.1.1 Attributes

  • A data variable with object scope.
  • Examples: book attributes: title, author, publisher, ISBN
  • The value of an object's attributes define its state.
  • Attributes should not be accessible to entities outside the object.
  • If an object has no attributes, is it really a valid object?

1.7.1.1.2 Behaviors

  • Method: a function with object scope.
  • Methods can operate on that object's attributes.
  • Defines the objects behaviors - how it does what it does.
  • Methods define the objects responsibilities.
  • If an object has no methods, is it really a valid object?

1.7.1.2 Discover classes

  • Work outward from data requirements to build a static model.
  • Jump start with grammatical inspection: Make a quick pass through the available material, making lists of the nouns, verbs, and possessive phrases.
  • Nouns become classes.
  • Noun phrases becomes class attributes.
  • Verbs become operations (behaviors) and associations.
  • Possessive phrases may indicate that nouns should be attributes rather than objects.
  • Create this list of "class candidates".
  • Best sources of classes: high-level problem statement, lower-level requirements, expert knowledge of the problem space.
  • Go through the candidate classes and eliminate the items that are unnecessary (redundant or irrelevant) or incorrect (too vague, represent concepts outside the model).

1.7.1.2.1 Where else do classes come from?

  • Tangible things - cars, telemetry data, pressure sensors
  • Roles - mother, teacher, politician, manager
  • Events - interrupt, request
  • Interactions - loan, meeting, intersection
  • People - humans who carry out some function
  • Places - areas set aside for people or things
  • Things - physical objects, devices
  • Organizations - formally organized collections of people
  • Concepts - principles or ideas that are not tangible

1.7.1.3 Build generalization relationships

  • Generalization - one class is a refinement of another class.
  • Define Is-a relationships.
  • Break into (1) superclass/parent, and (2) subclass/child.
  • Child inherits attributes and behaviors of the parent.
  • Sometimes discover classes "ahead of schedule".

1.7.1.4 Build associations between classes

  • Association: A static relationship between two classes.
  • Show dependencies between classes but not between actions.
  • Should be a true statement about the problem space, independent of time (i.e., static).
  • Build the list of candidate associations from the list of verbs and verb phrases and knowledge of the problem domain.

Examples:

  • Order generates Trade.
  • Portfolio places Orders.
  • Posting involves GLAccount.
  • Trade generates TradeLot.

  • Some associations are one-to-one, some are one-to-many. These are referred to as multiplicities.
  • Don't worry about being more specific about numbers of one-to-many associations at this time.
  • Aggregation: an association in which one class is made up of other classes. "Has-a" or "part-of" relationships.

1.7.1.5 Mine legacy documentation for domain classes

  • Relational database tables are an excellent source of domain classes.
  • Helper classes: contain attributes and operations that are relevant to more significant classes.

1.7.1.6 Wrapping up domain modeling

1.7.1.6.1 Continue to iterate and refine

  • Draw an analysis-level class diagram
  • The user's wants and needs are the reason your project team exists.
  • Establish a time budget for building your initial domain model.
  • The diagram you draw during domain modeling is just a skeleton of your object model.

1.7.1.6.2 Three key principles

  • Work inward from user requirements.
  • Work outward from data requirements.
  • Drill down from high-level models to detailed design.

1.7.2 Use case modeling

1.7.2.1 Actors

  • An actor is anyone or anything that must interact with the system.
  • An actor is not part of the system.
  • Actors are typically found in the problem statement, and by conversations with customers and domain experts.
  • Actors are drawn as a stick figures.
  • When dealing with actors it is important to think about roles.

Questions to help identify actors

  • Who is interested in a certain requirement?
  • Who installs the system?
  • Who starts and stops the system?
  • Where in the organization is the system used?
  • Who will benefit from use of the system?
  • Who will supply the system with this information, use this information, and remove this information?
  • Who will support and maintain the system?
  • Does the system use an external resource?
  • Does one person play several different roles?
  • Do several people play the same role?
  • Does the system interact with a legacy system?
  • What other systems use this system?
  • Who gets information from this system?

1.7.2.1.1 Use Cases

Use Case - a sequence of actions that an actor performs within a system to achieve a particular goal. The purpose of this stage is to capture user requirements of the new system using use case diagrams.

  • Definition: A sequence of actions that an actor performs within a system to achieve a particular goal.
  • A use case describes one or more courses through a user operation. The basic course must always be present; alternate courses are optional.
  • Basic course - the main start-to-finish path the user will follow under normal circumstances.
  • Alternate course - infrequently used path, an exception, or an error condition.
  • Stated from the perspective of the user as a present-tense verb phrase in an active voice (AdmitPatient, Do Trade Entry, Generate Reports).
  • Describes one aspect of usage of the system without presuming any specific design or implementation.
  • Ask "what happens?"
  • "Then what happens?"
  • Be relentless.
  • All required system functionality should be described in the use cases.
  • Actor - represents a role a user can play with regard to a system.
  • A user can serve as more than one type of actor.
  • Use cases appear as ovals, generally in the middle of a use case diagram.
  • Analysis level and design level use cases.
  • Should be able to write a solid paragraph or two about a design-level use case.
  • Use cases should have strong correlations with material in the user manual for the system (write the manual, then write the code). (Write the manual as though the system already exists.)
  • Use rapid prototyping as frequently as possible.
  • If you're reengineering an existing legacy system, work from the user manual backward.
  • A use case captures some user-visible function.
  • A use case achieves a discrete goal for the user.
  • A use case may be large or small.
  • Use cases model a dialogue between an actor and the system.

1.7.2.1.2 Questions to help identify use cases[11]

  • What are the tasks of each actor?
  • Will any actor create, store, change, remove, or read information in the system?
  • What use case will create, store, change, remove, or read this information?
  • Will any actor need to inform the system about sudden, external changes?
  • Does any actor need to be informed about certain occurrences in the system?
  • What use cases will support and maintain the system?
  • Can all functional requirements be performed by the use cases?

1.7.2.1.3 Use case diagrams

  • Use case diagrams identify use cases and actors of the system.
  • Use case-actor relationships are shown with association lines.
  • Use cases appear as ovals, generally in the middle of a diagram.
  • Use cases appear at various levels of detail; two such levels are analysis-level and design-level.

Figure 1.10: A sample use case diagram.
Image use_case1

1.7.2.1.4 Use case diagrams - include and extend

  • One use case can use or extend another use case.
  • The secondary (sub-level) use case is not associated directly with an actor.
  • Stereotypes
  • «includes» - use/include a piece of behavior that is similar across more than one use case.
  • «extends» - one use case is similar to another, but does more.

1.7.2.1.5 Wrapping Up Use Case Modeling

Feel comfortable when you've achieved the following goals:

  1. Your use cases account for all of the desired functionality of the system.
  2. You have clear and concise descriptions of the basic course of action, with appropriate alternate courses of action.
  3. You have factored out common scenarios.

1.7.2.1.6
Milestone 1: Requirements Review

1.7.3 Robustness analysis

Robustness analysis involves:

  1. analyzing the text of each of your use cases,
  2. identify a first-guess set of objects that will participate in the use case, then
  3. classify these objects into
    1. Boundary objects
    2. Entity objects
    3. Control objects
  4. This has parallels in the Model/View/Controller paradigm.

1.7.3.1 Definitions

  • Boundary objects - Actors use these to communicate with the system ("View").
  • Entity objects - Usually objects from the problem domain ("Model").
  • Control objects - Serve as the "glue" between Boundary and Entity objects ("Controller").

1.7.3.2 Key roles of robustness analysis

  • Sanity check - make sure your use case text is correct.
  • Completeness check - make sure your use cases address all the necessary alternate courses of action.
  • Ongoing discovery of objects - you may have missed some objects during domain modeling.

1.7.3.3 Closer look at object types

1.7.3.3.1 Boundary objects

  • "View".
  • Objects that the Actors will be interacting with.
  • Windows, screens, dialogs, menus.
  • Get many from prototypes.

1.7.3.3.2 Entity objects

  • "Model".
  • Often map to database tables and files.
  • Many come from the domain model.
  • Simpler and more generic - easier to reuse in other projects.

1.7.3.3.3 Control objects

  • "Controller".
  • Embody much of the application logic.
  • Where you capture business rules and application logic.
  • Not necessarily meant to endure as stand-alone classes as you proceed.
  • Sometimes serve as placeholders to make sure you don't forget any functionality and system behavior required by your uses cases.

1.7.3.4 Performing robustness analysis

  • Actors can talk only to Boundary objects.
  • Boundary objects can talk only to Controllers and Actors.
  • Entity objects can only talk to Controllers.
  • Controllers can talk to both Boundary objects and Controllers, but not to Actors.
  • Update your static model.

1.7.3.4.1
Milestone 2: Preliminary Design Review

1.7.4 Interaction modeling

1.7.4.1 Introduction

Current state:

  • Uncovered most problem space objects and assigned some attributes to them.
  • Defined some static relationships between these objects.
  • Defined a few dynamic relationships on robustness diagrams.

Interaction modeling is the phase in which you build the threads that weave your objects together and enable you to see how they will perform useful behavior. One of the primary tools of this task is creating sequence diagrams.

Objectives

Upon completion of this section, students will be able to:

  • Define the goals of interaction modeling.
  • Create sequence diagrams.
  • Put behavioral methods on your classes.
  • Update your static model.

1.7.4.2 Goals of Interaction Modeling

  • Allocate behavior among entity, boundary, and control objects.
  • Show detailed interactions that occur over time among objects.
  • Finalize the distribution of operations among classes.

1.7.4.3 Sequence Diagrams

  • Represent the major work product of our design.
  • Draw one sequence diagram that encompasses the basic course and all alternative courses within each of your use cases. One sequence diagram per use case.
  • These results form the core of your dynamic model.

1.7.4.3.1 Four Sequence Diagram Elements

  • The text for the course of action of the use case.
  • Objects.
  • Messages.
  • Methods (operations, behaviors).

1.7.4.4 Getting Started

Four steps to creating diagrams:

  • Copy the use case text to the left margin of the sequence diagram.
  • Add the entity objects.
  • Add the boundary objects.
  • Work through the controllers, one at a time. Determine how to allocate behavior between the collaborating objects.

1.7.4.5 Putting Methods on Classes

  • This is the essence of interaction modeling.
  • It's also hard.
  • A cow needs milking. Does the cow object milk itself, or does the Milk object "de-cow" itself?
  • Convert controllers from robustness diagrams to sets of methods and messages that embody the desired behavior.
  • An object should have a single "personality". Avoid schizophrenic objects.
  • If you have objects with split personalities you should use aggregation.
  • Use CRC cards to help.
  • Behavior allocation is of critical importance.
  • Don't show message parameters on your sequence diagrams.

1.7.4.5.1 Which Methods Belong With Objects

  • Reusability - the more general, the more reusable. Does this method make the class more or less reusable.
  • Applicability - is there a good fit between the object and method?
  • Complexity - is it easier to build a method in another object?
  • Implementation knowledge - does the implementation of the behavior depend on details internal to the associated method?

1.7.4.6 Completing Interaction Modeling

  • Drawn all needed sequence diagrams.
  • Updated your static model.
  • Last stop before you start coding; Critical Design Review is essential.

1.7.5 Collaboration and State Modeling

1.7.5.1 Introduction

  • Model additional aspects of your system.
  • Most useful in real-time system design.
  • Collaboration diagrams are similar to sequence diagrams.

1.7.5.2 Collaboration diagrams

  • Shows how critical objects collaborate within a use case.
  • Collaboration diagrams are similar to sequence diagrams.
    • Collaboration diagrams focus on key transactions.
    • Sequence diagrams follow the flow of entire use cases (emphasis on time ordering).
    • Collaboration diagrams add extra detail related to timing of messages.

1.7.5.3 State diagrams

  • Captures the lifecycle of one or more objects.
  • Expressed in terms of:
    • Different states objects can assume
    • Events that cause changes in state

Basic elements:

  • Initial state - hollow circle containing a black dot.
  • Each additional state - rectangle with rounded corners.
  • Three standard events:
    • Entry
    • Exit
    • Do
  • Transition - an arrow between two states.

1.7.5.3.1 How many state diagrams are needed?

  • Every object has a state machine.
    • Object is created.
    • Sends messages.
    • Receives messages.
    • It is destroyed.
  • In reality, most state machines are boring, so don't waste time drawing them.
    • Don't diagram an object with two states, On and Off.
  • Readability is important.

1.7.5.4 Activity diagrams

  • Remarkably similar to flowcharts.
  • Swimlanes - group a set of activities according to who is performing them.
  • A good way to understand/model business processes.

1.7.6 Addressing Requirements

1.7.6.1 Introduction

This section shows how to trace the results of your analysis and design work back to your user requirements.

1.7.6.2 Objectives

Upon completion of this section, students will be able to:

  • Define a requirement
  • Describe the nature of requirements, use cases, and functions

1.7.6.3 What is a Requirement?

  • A user-specified criterion that the system must satisfy.
  • Requirements define the bahvior and functionality of a proposed system.
  • Usually expressed as sentences that include the word shall or must.

1.7.6.3.1 Types of Requirements

  • Functional - ``The system shall automatically generate postings to the general ledger''.
  • Data - ``The system ... international currencies ...''.
  • Performance - ``The system must ... in XX seconds''.
  • Capacity - ``Up to 10,000 transactions per day''.
  • Test - ``Stress testing shall ... XX users ... YY computers ...''.

1.7.6.4 Use Cases and Requirements

  • A use case describes a unit of behavior.
  • A requirement describes a law that governs behavior.
  • Several types of requirements: functional, performance, and constraints.
  • A use case can satisfy one or more functional requirements.
  • A functional requirement may be satisfied by one or more use cases.
  • Requirements are requirements, use cases are use cases. Requirements are not use cases.

1.7.6.5 Requirements Traceability

  • Make a list of the system requirements.
  • Write the user manual for the system in the form of use cases.
  • Iterate with your customers until you have closure of items 1 and 2.
  • Make sure you can trace every piece of your design to at least one user requirement.
  • Make sure you can trace every requirement to the point at which its satisfied within your design.
  • Trace your design back to your requirements as you review the design during your critical design review.

1.7.7 Survey of Design Patterns

  • Repeating patterns - ``Her garden is like mine, except that in mine I use astilbe.''
  • Recurring solutions to design problems you see over and over.
  • A set of rules describing how to accomplish certain tasks in the realm of software development.
  • Made famous by the text ``Design Patterns'', by Gamma, Helm, et al.
  • A list of some of the most well-known design patterns:
    Factory Abstract Factory
    Singleton Builder
    Prototype Adapter
    Bridge Composite
    Decorator Facade
    Flyweight Proxy
    Chain of Responsibility Command
    Interpreter Iterator
    Mediator Memento
    Observer State
    Strategy Template
    Visitor

1.7.7.1 Factory pattern example

  • The code and diagram that follow demonstrate a small, simple example of the Factory pattern

    public abstract class Dog {
      public abstract void speak ();
    }
    
    public class Poodle extends Dog {
      public void speak() {
        System.out.println("The poodle says \"arf\"");
      }
    }
    
    public class SiberianHusky extends Dog {
      public void speak() {
        System.out.println("The husky says \"Whazzup?!!\"");
      }
    }
    
    public class Rottweiler extends Dog {
      public void speak() {
        System.out.println("The Rottweiler says (in a very deep voice) \"WOOF!\"");
      }
    }
    

    public class Main {
      public Main() {
        // create a small dog
        Dog dog = DogFactory.getDog("small");
        dog.speak();
    
        // create a big dog
        dog = DogFactory.getDog("big");
        dog.speak();
    
        // create a working dog
        dog = DogFactory.getDog("working");
        dog.speak();
      }
    
      public static void main(String[] args) {
        new Main();
      }
    }
    

    public class DogFactory {
    
      public static Dog getDog(String criteria) {
        if ( criteria.equals("small") )
          return new Poodle();
        else if ( criteria.equals("big") )
          return new Rottweiler();
        else if ( criteria.equals("working") )
          return new SiberianHusky();
    
        return null;
      }
    }
    

1.7.7.1.1
Figure 1.11: A UML use case diagram for the DogFactory.
Image DogFactoryUML