Notations in software design

8/13/2019 Notations in software design

1/17


2/17

The Notation

The act of drawing a diagram does notconstitute analysis or design. A diagramsimply

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 willsoon realize that the one and only place thata

system is conceived is in the mind of the

designer.


3/17

having a well-defined and expressive notation is important tothe process of software development.

First, a standard notation makes it possible for an analyst ordeveloper to describe a scenario or formulate an architectureand then unambiguously communicate those decisions toothers. Draw an electrical circuit, and the symbol for a

transistor will be understood by virtually every electricalengineer in the world. Similarly, if an architect in New YorkCity drafts the plans for a house, a builder in San Franciscowill have little trouble understanding where to place doors,windows, and electrical outlets from the details of theblueprints.

Second, as Whitehead states in his seminal work onmathematics, By relieving the brain of all unnecessary work,a good notation sets it free to concentrate on more advancedproblems" [2].

Third, an expressive notation makes it possible to eliminatemuch of the tedium of checking the consistency andcorrectness of these decisions by using automated tools.


4/17

The Models of Object-Oriented

Development


5/17

Elements of the Notation

It is impossible to capture all the subtle details of acomplex software system in just one view.

As Kleyn and Gingrich observe, "One must understandboth 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 somewhatanalogous to that of viewing a sports

event such as tennis or a football game. Many differentcamera angles are required to provide

an understanding of the action taking place. Eachcamera reveals particular aspects of the

action that could not be conveyed by one cameraalone"


6/17

As Weinberg notes, "In other design fields, such asarchitecture, the rough sketch is the most

frequently used graphic device, and precise detaileddrawings 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 thoseelements of the notation that are

necessary to convey the intended meaning, and nothingmore. Just as it is dangerous to

overspecify a set of requirements, so it is dangerous tooverspecify a solution to a problem.


7/17

For example, on a blueprint, an architect may show the general location of a lightswitch in a

room, but its exact location will not be established until the construction managerand owner

do an electrical walk-through, after the house has been framed. It would be foolishto 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 theowner'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 alreadyestablished 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 thedevelopers are

separated geographically, in time, or by contract, then more detail will be requiredduring the

development process. The notation we present in this chapter covers each ofthese situations.


8/17

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. Bothdimensions are necessary to

specify the structure and behavior of an object-orientedsystem.

For each dimension, we define a number of diagrams thatdenote a view of a system's

models. In this sense, the system's models denote the "wholetruth" about its classes,

relationships, and other entities, and each diagramrepresents a projection of these models. In

the steady state, all such diagrams must be consistent withthe model and therefore among

themselves.


9/17

For simplicity, across all diagrams, all entities with thesame name and within the same scope

are considered to be references to the same modelitem. 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 mustprovide a name whose purpose is to

indicate the focus or intent of the diagram. Other labelsand notes may be attached to a

diagram to further elucidate its contents, as we willdescribe in a later section; such notes in

general have no additional semantics.


10/17

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 theproblem space or that define the system's

architecture. The physical model of a systemdescribes the concrete software and hardware

composition of the system's context orimplementation.

During analysis, we must address the following

central questions: What is the desired behavior of the system?

What are the roles and responsibilities of theobjects that carry out this behavior?


11/17

During design, we must address the following centralquestions relative to the system's

architecture:

What classes exist, and how are those classes related?

What mechanisms are used to regulate how objectscollaborate?

Where should each class and object be declared?

To what processor should a process be allocated, and for agiven 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


12/17

Static Versus Dynamic

Semantics The four diagrams we have introduced thus far are largelystatic.

describing a dynamic event in a static

medium such as a sheet of paper is a difficult problem, but itconfronts virtually every

scientific discipline. In object-oriented development, weexpress the dynamic semantics of a

problem or its implementation through two additionaldiagrams:

State transition diagrams

Interaction diagram

Each class may have an associated state transition diagramthat indicates the event-ordered

behavior of the class's instances. Similarly, in conjunction withan object diagram representing

a scenario, we may provide a script or interaction diagram toshow the time or event-ordering

of messages as they are evaluated.

Cl Di


13/17

Class Diagrams

Essentials: Classes and Their Relationships

A class diagram is used to show the existence ofclasses and their relationships in the logical

view of a system. A single class diagram represents aview 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 thesystem'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


14/17

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 formalarguments (if any)

Operation names must be unambiguous in the context of the class,according to the rules for

overloading in the chosen implementation language.


15/17

Abstract Class Adornment Class Relationship Icons


16/17

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 nounphrases

1 .. N One or more

0 .. 1 Zero or one

3 .. 7 Specified range

1 .. 3, 7 Specified range or exact number


17/17

Hydroponics Gardening

System Class Diagram

Documents

Notations in software design