Booch defines a lot of symbols to document almost every design decision. I guess that working with this method, one will rarely use all the symbols and diagrams and will probably stick to a tailored sub-set, indeed Booch references a minimal one in his book: the Booch Lite.
One aspect of Booch method deserves to be pointed out: the method is descriptive, i.e. Booch tells you what you can do in terms of system definition, and does not give you prescriptions on what you should do in order to better perform analysis and design of the system. Now, this could be seen by some as an advantage (those who like a certain freedom for their software production), and as a weakness at the same time as one would probably need more expertise and experience to go OO without more specific guidelines.
Within the method one starts with class and object diagrams (a discovering activity) in the analysis phase and refine these diagrams through various steps (within the same diagram, undergoing a refinement process as long as the problem domain gets more and more understood), following an evolutionary approach. Design symbols are to be added when ready to generate code, usually representing very final implementation decisions. Here Booch notation large set appears to prove beneficial: it is possible to fully document the OO-code.
Booch proposes different views to describe an OO system. The logical model (i.e., the problem domain) is represented in the class and object structure. In the class diagram one builds up the architecture, or the static model.
To deal with complex diagrams, the notation allows class categories to group classes into namespaces, each category being itself a class diagram.
The object diagram shows how objects interact with each other (their relationships), whereas class diagrams (and the relationships therein) are mostly static, object diagrams (and the relationships therein) describe the dynamic behavior of the system. In this instance relationship means message exchanges between objects.
The module and process architecture deals with the physical allocation of classes and objects to modules, and with processors, devices and communication connections between them, in few words it describes the concrete hardware with respect to the software components of a system.
Booch supports the iterative and incremental development of a system.
He defines two processes describing the layout of Object Oriented development:
In principle, the micro process represent the daily activity of the individual developer, or of a small team
of developers. Here the analysis and design phases are intentionally blurred.
Stroustrup observes that: "There are no cookbook methods that can replace intelligence, experience,
and good taste in design and programming...The different phases of a software project, such as design, programming,
and testing cannot be strictly separated".
The macro process serves as the controlling framework of the micro process. It represents the activities of the entire development team on the scale of weeks to months at a time.
The basic philosophy of the macro process is that of incremental development: the system as a whole is built up
step by step, each successive version consisting of the previous ones plus a number of new functions. To this,
Booch explicitly says: "This approach is extremely well suited to the object oriented paradigm..."
A Class Diagram states the relationships among the abstractions of a system (logical view).
During analysis, we use class diagrams to indicate the common roles and responsibilities of the entities that provide the behavior of the system.
During design, we use class diagrams to capture the structure of the classes that form the system's architecture.
In class diagrams we may represent all or part of the class structure of a system, explicitly we can refer to:
The modular unit of OO software decomposition. As a type, a class represents a set of similar run-time data elements, or objects, that share a common structure and a common behavior. As a decomposition unit, a class is a group of related services packed together under a single representative name.
The dynamic behavior of a class is described in a state transition diagram.
class ClassName {
public:
// constructors
// destructors
// operators
// modifiers
// selectors
protected:
// member objects
private:
// friends
};
A class utility denotes a collection of free subprograms (procedures or functions that serve as non primitive operations upon objects) or, in C++ non-member functions.
It is common style in C++ (and Smalltalk) to collect all logically related free subprograms and declare them as part of a class that has no state. In particular in C++ this become static. Thus we may say that all methods are operations, but not all operations are methods: some operations may be expressed as free subprograms.
operation() {
...
}
A class that serves as a template for other classes, in which the template may be parameterized by other classes, objects, and/or operations. This class denotes a family of classes whose structure and behavior are defined independent of its formal generic parameter(s). The mechanism which permits generic classes and the corresponding types is called genericity. A parameterized class does not directly yield a type, one has to provide first a list of types, its actual generic parameters, one for each formal generic parameter. Typically, parameterized classes are used as container classes; the terms generic class and parameterized class are interchangeable. Actually, a generic class means that it is parameterized by types. Genericity is one of the main reasons why classes and types are not identical notions, even if closely connected.
template<class Item>
class Queue {
public:
...
Queue(const Queue<Item>&);
...
};
Queue<int> int Queue;
Queue<Sensor*> sensorQueue;
A logical collection of classes, some of which are visible to other class categories, and others are hidden. The classes in a class category collaborate to provide a set of services.
Most OOP languages do not have any support for class categories, still, class categories allow us to represent an important architectural element of the system to be implemented: clusters of classes that are themselves cohesive, but loosely coupled relative to other class aggregates. Categories are a way to partition the logical model of a system, they represent an encapsulated name space.
A class attribute describes a singular information stored with each instance. For certain class diagram it is useful to expose some of the attributes associated with a class. In this case the selected attributes for showing represent an elided view of the class's entire specification. Using the following language-independent syntax, an attribute may have a name, a class, or both, and optionally a default value.
A Attribute name only :C Attribute class only A : C Attribute name and class A : C = E Attribute name, class and default expression
An operation upon an object, defined as part of the declaration of a class. Usually the terms message, method, and operation are interchangeable. By introducing a method in a class, one specifies that a certain computation (an algorithm) must be applicable to any instance of the class. Methods can be partitioned into functions and procedures, depending on whether the method returns a result or not.
N() Method name only R N(Arguments) Method return class, name and formal arguments
Adornments are secondary pieces of information about some entity in a system's model. The general principle for the notation is a letter denoting the adornment inside a triangle anywhere within the class icon.
Relationships may also have adornments as a kind of qualification. In C++ there are three such properties:
For consistency, class and relationship adornments share the same notation.
OOP languages provide a clear separation between the interface and the implementation of a class, most allow the designer to specify fin-grained access to the interface as well. In C++, for example, members may be public (accessible to all clients), protected (accessible only to subclasses, friends, or the class itself), or private (accessible only to the class itself and its friends). Certain elements might also be a part of a class's implementation, thus inaccessible even to friends of the class.
Object Diagrams are part of the notation of object-oriented design, used to show all or some of the objects and their relationships in a system's logical model; It can be used to trace the execution of different scenarios: hence, a single object diagram represents a snapshot in time of a transitory system state or configuration.
In an object diagram we can refer to:
An object is something you can do things to. An object as state, behavior, and identity; the structure and behavior of similar objects are defined in their common class. Objects are also called the instances of a class.
The term link derives from Rumbaugh, who defines it as a "physical or conceptual connection" between objects. A link denotes the association through which one object, the client, applies the services of another object, the server, or through which one object can navigate to another. In other words, links visualize messaging paths (typically unidirectional) between objects.
As a participant in a link, an object may play one of three roles:
Whenever messages run across a link, the two objects are said to be synchronized. In a completely sequential application synchronization is accomplished just by method invocation. In the presence of multiple threads of control, an object requires more than that in order to deal with problems of mutual exclusions or conflicts.
Actors have their own thread of controls, with servers one has to choose one of three approaches:
Messages are then adorned using the notation:
Class diagrams show the dependencies that exist among the classes of various objects, they do not dictate how those instances can see one another. For this reason it is possible to adorn links to represent the visibility of the server from the client's side:
The absence of adornment on a link means that the precise visibility between the two objects is left unspecified.
The state of an object represents the cumulative results of its behavior. At any givn point in time, the state of an object encompasses all of its properties (the object's attributes and relationships) and the values of each of these properties.
The ability to nest states gives depth to state transition diagrams. A state transition diagram is used to show the state space of a given class, the events (messages) that trigger a transition from one state to another, and the actions that result from a state change.
The notation is borrowed from Harel.
Harel, D. 1987. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming vol. 8.
The notation:
A (unique) name is required for each state; for certain states it could be useful to indicate some of the actions associated with:
The state goes into his lastly assumed state upon entry. This is indicated with adorning the state icon with:
State transitions to and from substates are represented with a stubbed arrow:
As previously said, actions may be associated with states. In particular one may specify actions to be carried out upon entry or exit of a state.
Each state transition connects two states. A state may have transition to itself, and many transition can depart from the same state, although each transition must be unique, i.e. there cannot be any circumstance (event) able to trigger more than one state transition from the same state.
In every state transition diagram there must be exactly one default start state, which is designated by writing a transition from a filled circle.
It is also possible to designate a stop state by drawing a transition to a filled circle within a larger unfilled circle (not shown in the example).
Module diagrams are used to show the allocation of classes and objects to modules in the physical design of a system, that is module diagrams indicate the partitioning of the system architecture.
Through these diagrams it is possible to understand the general physical architecture of a system.
The two essential elements of a module diagram are modules and their dependencies.
The first three icons denote files. The specification and the body icon denote files containing the declaration (.h files) and definition (.cpp files) of entities. The main program icon denotes a file that contains the root of a program (some .cpp file). Typically there is one such module per program.
The notation:
The only relationship we may have between two modules is a compilation dependency, represented by an arrow pointing to the module upon which the dependency exists. Normally, there may be no cycles within a set of compilation dependencies. In C++ this is indicated by #include directives.
The informal convention is to collect related modules in directory structures. The notion of subsystem is introduced for such a reason. Subsystems partition the physical model of the system, they are aggregates containing other modules and other subsystems.
A subsystem can have dependencies upon other subsystems or modules, and a module can have dependencies upon a subsystem. The same notation is used for subsystems dependencies.
You can place the modules in different subsystems. In C++ these are different directories.
A process diagram is used to show the allocation of processes to processors in a physical design of a system. Through the diagrams one indicates the collection of processors and devices that serve as platform where to execute the system.
The three essential elements of a process diagram are processors, devices, and their connections. A list of processes can adorn a processor icon. A process in the list denotes the root of a main program (from a Module diagram) or the name of an active object (from an object diagram).
Notation:
Interaction diagrams trace the execution of a scenario in the same context as an object diagram. In a way, it is another representation of an object diagram.
It allows to read the passing of messages in their relative order, in this sense it complements the corresponding object diagram it refers to. Interesting objects are written horizontally at the top of the diagram and a dashed vertical line is drawn below each object.
Messages are shown horizontally with arrows from the client to the server object dashed line using the same syntax and synchronization symbols used in the corresponding object diagram.
The vertical box adorning each object line represents the relative time that the flow of control is focused in that object.
Interaction diagrams focus on events more than on operations and result better at capturing the semantic of a scenario than are object diagrams.
