|
Subsections
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.
First guess at domain objects.
- 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?
- 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?
- 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?
- 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).
- 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
- 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".
- 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.
- Relational database tables are an excellent source of domain classes.
- Helper classes: contain attributes and operations that are relevant to more significant classes.
- 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.
- Work inward from user requirements.
- Work outward from data requirements.
- Drill down from high-level models to detailed design.
- 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?
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.
- 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?
- 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.
|
|
- 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.
Feel comfortable when you've achieved the following goals:
- Your use cases account for all of the desired functionality of the system.
- You have clear and concise descriptions of the basic course of action, with appropriate alternate courses of action.
- You have factored out common scenarios.
Milestone 1: Requirements Review
Robustness analysis involves:
- analyzing the text of each of your use cases,
- identify a first-guess set of objects that will participate in the use case, then
- classify these objects into
- Boundary objects
- Entity objects
- Control objects
- This has parallels in the Model/View/Controller paradigm.
- 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").
- 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.
- "View".
- Objects that the Actors will be interacting with.
- Windows, screens, dialogs, menus.
- Get many from prototypes.
- "Model".
- Often map to database tables and files.
- Many come from the domain model.
- Simpler and more generic - easier to reuse in other projects.
- "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.
- 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.
Milestone 2: Preliminary Design Review
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.
- Allocate behavior among entity, boundary, and control objects.
- Show detailed interactions that occur over time among objects.
- Finalize the distribution of operations among classes.
- 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.
- The text for the course of action of the use case.
- Objects.
- Messages.
- Methods (operations, behaviors).
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.
- 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.
- 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?
- Drawn all needed sequence diagrams.
- Updated your static model.
- Last stop before you start coding; Critical Design Review is essential.
- Model additional aspects of your system.
- Most useful in real-time system design.
- Collaboration diagrams are similar to sequence 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.
- 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:
- Transition - an arrow between two states.
- 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.
- Remarkably similar to flowcharts.
- Swimlanes - group a set of activities according to who is performing them.
- A good way to understand/model business processes.
This section shows how to trace the results of your analysis and design work back to your user requirements.
Upon completion of this section, students will be able to:
- Define a requirement
- Describe the nature of requirements, use cases, and functions
- 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.
- 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 ...''.
- 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.
- 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.
- 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 |
- 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;
}
}
Figure 1.11:
A UML use case diagram for the DogFactory.
|
|
|
|
