- Remember to only model what needs to be shown.
- There is a tendency among novice OO designers to put too much emphasis upon statis models. In fact, a static emphasis on object oriented design is inappropriate. Softare design is about behavior, and behavior is dynamic. Object oriented design is a technique used to separate and encapsulate behaviors.
Actors are external to the system and interact with the system by providing stimuli. Actors can be humans playing roles or even other systems.
Use cases provide a framework to textual describe the behavior of the system: the inputs and outputs to actors; nature of the stimulus, etc.
Example:
Use Case: Looking up a web service
- User connects to a UDDI (Universal Description Discovery and Integration) service
- System scans the Web Service registry looking up Web Service descriptions that are stated in WSDL
- System finds matches and lists services in order of closest match at the top of the list
- User selects a service to connect to
- System resolves the service connection protocols and creates a contract
- Service provider and user agree to the terms of the contract and the service is activated
To understand the textual and graphical format of Use Cases refer to the reading.
Important points:
- The structure of the Use Case is not the structure of the software it represents:
Use Cases do not represent objects or classes. The structure of Use Cases and the structure of software are unrelated.
- Use Case diagrams have low information content. They convey the structure of Use Cases but tell you very little about the text within them. The diagrams provide a reader with a diagrammatic representation of the use cases and the relationships (<
> < >) between them.
Use cases are powerful tools for analysts to use when partitioning the functionality of a system. Use case relationships and the corresponding diagrams help analysts to structure use cases such that their textual descriptions contain a minimum of redundant information; thus making the whole text document much easier to maintain. But use cases are not design tools. They do not specify the structure of the eventual software, nor do they imply the existence of any classes or objects. They are purely functional descriptions written in a formalism that is completely separate from software design.
Statechart diagram
"A Statechart diagram depicts a finite state machine that describes how the class responds to different external stimuli (events). These stimuli are the receipt of messages by instances of the class, in the form of calls of the class’s operations"
Object state
An object has many states right from its creation to its destruction.
Object transition
A transition is a mechanism that causes an object to leave a state and change into a new state.
Internal transition
It is a special kind of transition that does not cause an object to leave the state.
Statechart example - describing the borrowing of a book
Relationship between class and state
The purpose of a state chart diagram is to describe the internal workings of objects. Each class has its own unique state chart diagram.
Each object is an instance of a class and has a life cycle from its creation to destruction. During the existence of an object in a system, the object makes transitions from state to state.
States are represented as attributes on the class diagram. However, note that the state of an object does not necessarily change whenever an attribute changes its value.
When to use State Charts
- When you have a complex object and you are not sure how it is going to function
- The class has many states and it is vital to the success of your application
- A statechart diagram has one initial state and one (or possibly more) final states
- When modeling the behavior of a reactive object with statecharts you are essentially specifying:
- The stable state in which that object may live.
- The events that trigger a transition from state to state.
- The actions that occur on each state change.
- You can also model the creation and destruction of the object.
- States
- Events
- Transitions
- Actions
- Activities
- Step 1: Review the class diagram and select classes that will need statecharts. Begin with the classes that have the simplest statecharts
- Step 2: Identify all the input messages across all sequence diagrams from the selected cases. One good assumption is that each message will be the trigger for a transition.
- Step 3: For each selected class make a list of states that it can be in. It is helpful to think of the life of the object in the following terms:
- How does it come into existence?
- When and how is it deleted?
- Does it have active states?
- Does it have inactive states?
- Does it have states where it is waiting?
- Step 4: Put the pieces together. Construct the lifecycle path and fill in the pieces.
- Step 5: Review the paths and ask yourself the following questions:
- Can the object be in both of these states at the same time?
- Or does one state naturally follow another state?
- Step 6: Review and test each statechart by following these steps:
- Make sure your states are really states of the object in the class.
- Follow the life cycle and be sure all combinations are covered and the paths are accurate.
- Be sure your diagram covers all exceptions as well as the normal course of action.
- For each transition, ask is it really permissible for the object to go from state A to state B?
- Review messages and make sure they are handled somewhere in the statechart.
- Review all possible actions and activities and make sure they are included correctly in the statechart.
Allow objects to be created in a system without having to specify the class type in the code so you do not need to write large complex code to create objects.
- Abstract Factory: This pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes
- Factory Method: This pattern provides an interface to create an object but lets the subclasses decide which class to instantiate
- Builder: Separates the construction of a complex object from its representation so the same construction process can create different objects
- Prototype: Allows an object to create customized objects without knowing their exact class or the details of how to create them
- Singleton: Ensures that a class has only one instance, and provides a global point of access to that class
Allows you to create systems without rewriting or customizing code. Provides a way to create highly reusable and robust systems.
- Adapter: Acts as an intermediary between two classes, converting the interface of one class so that it can be used with the other
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy
Influence have state and behavior flow through a system. By optimizing how state and behavior flow you can organize, simplify and increase the maintainability of the system.
- Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Templae Method
- Visitor
public class Loner() {
private Loner();
private static Loner lone = new Loner();
public static Loner getInstance() {
return lone;
}
// other public methods
}
Several software projects are built by a large group of practitioners leading to division of work. At some point integration of all pieces needs to be done. This part of the project normally has the most risk attached to it due to the following reasons:
- Individual pieces of code were not built as per specifications
- Only at the time of integration do the practitioners see the big picture leading to wastage of time and resources
- Performance of individual pieces of code was acceptable however, on integration performance degraded considerably
- Large intervals between integration lead to a greater number of integration points thus increasing complexity