The Notation

The act of drawing a diagram does not constitute analysis or design. A diagram simply captures a statement of a system's behavior (for analysis), or the vision and details of an architecture (for design). lf you follow the work of any engineer - software, civil, mechanical, chemical, architectural, or whatever - you will soon realize that the one and only place that a system is conceived is in the mind of the designer.

having a well-defined and expressive notation is important to the process of software development. First, a standard notation makes it possible for an analyst or developer to describe a scenario or formulate an architecture and then unambiguously communicate those decisions to others. Draw an electrical circuit, and the symbol for a transistor will be understood by virtually every electrical engineer in the world. Similarly, if an architect in New York City drafts the plans for a house, a builder in San Francisco will have little trouble understanding where to place doors, windows, and electrical outlets from the details of the blueprints. Second, as Whitehead states in his seminal work on mathematics, By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems" [2]. Third, an expressive notation makes it possible to eliminate much of the tedium of checking the consistency and correctness of these decisions by using automated tools.

The Models of Object-Oriented Development

Elements of the Notation

It is impossible to capture all the subtle details of a complex software system in just one view. As Kleyn and Gingrich observe, "One must understand both the structure and the function of the objects involved. One must understand the taxonomic structure of the class objects, the inheritance mechanisms used, the individual behaviors of objects, and the dynamic behavior of the system as a whole. The problem is somewhat analogous to that of viewing a sports event such as tennis or a football game. Many different camera angles are required to provide an understanding of the action taking place. Each camera reveals particular aspects of the action that could not be conveyed by one camera alone"

As Weinberg notes, "In other design fields, such as architecture, the rough sketch is the most frequently used graphic device, and precise detailed drawings are rarely used at all until the creative part of the design work is finished a notation is only a vehicle for capturing the reasoning about the behavior and architecture of a system; a notation is not an end in itself. Therefore, one should apply only those elements of the notation that are necessary to convey the intended meaning, and nothing more. Just as it is dangerous to overspecify a set of requirements, so it is dangerous to overspecify a solution to a problem.

For example, on a blueprint, an architect may show the general location of a light switch in a room, but its exact location will not be established until the construction manager and owner do an electrical walk-through, after the house has been framed. It would be foolish to specify the precise three-dimensional coordinates of the light switch on the blueprint (unless, of course, this was a detail that was functionally important to the owner: perhaps the owner's family is significantly taller or shorter than average). Thus, if the analysts, designers, and implementors of a software intensive system are highly skilled and have already established a close -working relationship, then rough sketches may suffice (although it will still be necessary to leave a legacy of the architectural vision for the sake of the system's maintainers). If, on the other hand, the implementors are not quite so skilled, or if the developers are separated geographically, in time, or by contract, then more detail will be required during the development process. The notation we present in this chapter covers each of these situations.

Models and Views

analysis and design decisions regarding these classes and objects and their collaborations according to two dimensions: their logical/physical view, and their static/dynamic view. Both dimensions are necessary to specify the structure and behavior of an object-oriented system. For each dimension, we define a number of diagrams that denote a view of a system's models. In this sense, the system's models denote the "whole truth" about its classes, relationships, and other entities, and each diagram represents a projection of these models. In the steady state, all such diagrams must be consistent with the model and therefore among themselves.

For simplicity, across all diagrams, all entities with the same name and within the same scope are considered to be references to the same model item. For example, if class C appears in two different diagrams for the same system, both are references to the same class C. The exception to this rule is for operations, whose names may be overloaded. To distinguish one diagram from another, we must provide a name whose purpose is to indicate the focus or intent of the diagram. Other labels and notes may be attached to a diagram to further elucidate its contents, as we will describe in a later section; such notes in general have no additional semantics.

Logical Versus Physical Models

The logical view of a system serves to describe the existence and meaning of the key abstractions and mechanisms that form the problem space or that define the system's architecture. The physical model of a system describes the concrete software and hardware composition of the system's context or implementation. During analysis, we must address the following central questions: What is the desired behavior of the system? What are the roles and responsibilities of the objects that carry out this behavior?

During design, we must address the following central questions relative to the system's architecture: What classes exist, and how are those classes related? What mechanisms are used to regulate how objects collaborate? Where should each class and object be declared? To what processor should a process be allocated, and for a given processor, how should its multiple processes be scheduled? We use the following diagrams, respectively, to answer to these questions: Class diagrams Object diagrams Module diagrams Process diagrams

Static Versus Dynamic Semantics

The four diagrams we have introduced thus far are largely static. describing a dynamic event in a static medium such as a sheet of paper is a difficult problem, but it confronts virtually every scientific discipline. In object-oriented development, we express the dynamic semantics of a problem or its implementation through two additional diagrams: State transition diagrams Interaction diagram Each class may have an associated state transition diagram that indicates the event-ordered behavior of the class's instances. Similarly, in conjunction with an object diagram representing a scenario, we may provide a script or interaction diagram to show the time or event-ordering of messages as they are evaluated.

Class Diagrams Essentials: Classes and Their Relationships A class diagram is used to show the existence of classes and their relationships in the logical view of a system. A single class diagram represents a view of the class structure of a system. During analysis, we use class diagrams to indicate the common roles and responsibilities of the entities that provide the system's behavior. During design, we use class diagrams to capture the structure of the classes that form the system's architecture. The two essential elements of a class diagram are classes and their basic relationships.

the icon we use to represent a class in a class diagram. Its shape is that of a cloud; some call it an amorphous blob

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 attribute name must be unambiguous in the context of the class. N() Operation name only R N(Arguments) Operation return class, name, and formal arguments (if any) Operation names must be unambiguous in the context of the class, according to the rules for overloading in the chosen implementation language.

Abstract Class Adornment

Class Relationship Icons

Class Relationships The association icon connects two classes and denotes a semantic connection. Associations are Ofte 1 Exactly one N Unlimited number (zero or more) 0 .. N Zero or moren labeled with noun phrases 1 .. N One or more 0 .. 1 Zero or one 3 .. 7 Specified range 1 .. 3, 7 Specified range or exact number

Hydroponics Gardening System Class Diagram