Complete and Sufficient Analysis and

Application
When the word complete refers to the design class it means that the design Design
class should include the entire entities (attributes and methods) essential to
exist in the situation which is being described by cl given design class.

Sufficiency is a relative term which measures exact (neither more nor less)
nature of a given design. Hence, a well formed design class usually possess
both the properties i.e. complete and sufficiency respectively.

High Degree of Cohesion

This feature reflects that, whenever a given design class is implemented to

represent a specific purpose, then the attributes and methods, associated with
that class should also reflect the same purpose. Till this condition is satisfied,
we refer that these classes are maintaining high degree of cohesion property.

Low Degree of Coupling

It is often a true fact that, in a given model the design classes should have
collaboration. But this collaboration should not be extended to extreme values.
This is because, a model of design classes possessing high degree 0
collaboration is difficult to rest, maintain etc.; also in this case, we need to
consider even the "Law of Diameter" which suggests that, when there are
multiple 'subsystems, then various methods belonging to single subsystem
should communicate by transmitting messages at the same time restricting the
methods of one class to communicate with the methods of another classes
where the two classes are belonging to different subsystems.

Primitiveness

It suggests that any method belonging to a given design class should be made
to handle only single purpose. Hence, once the method implements a given
purpose, the same method should not be used for the implementation of any
other purpose.

1.7 DESIGN MODEL

A design model here, depicts a two dimensional analogy i.e., it represents

process dimension along horizontal x-axis and abstraction dimension along
vertical y-axis.

The two dimensional representation of the design is show above. The process
dimension along horizontal direction depicts the stages of development (i.e.,
architectural elements, interface element, component level element sand
finally deployment level elements respectively) which is usually observed
during software development process. Now consider the vertical view of this

17

/
 1

diagram. It vertical view refers to abstraction dimension. Here, short details on

Application
the transformation of elements from analysis model to design model are also
Development
Life Cycle shown. Apart from this, the elements which undergo refinement with the
design model are also shown. Usually the refinement is performed in a
sequential fashion. The horizontal dashed line appearing at the mid of the
diagram is used to separate the analysis model from design model. Usually in
both of these diagrams we find the UML diagrams. The UML diagrams
appearing in the design models are completely refined when compared to the
diagrams in analysis model'. This refinement can be in terms of architectural
structure and style, higher implementation details a component that resides
within the architect etc.

Finally, while dealing with the p~oces's dimension one has to remember that,
the architectural design, interface design and component level designs are
developed parallel and the deployment level diagrams is obtained at the end i.e.
deployment level diagram is considered when we are completed with the entire
designing process.

1.8 DESIGN ELEMENTS IN DESIGN MODEL

• Data Design Elements

• Architectural Design Elements

• Interface Design Elements

• Component - level design Elements

• Deployment - level Design Elements

(i) Data Design Elements: Data design often leads to a systematic

representation of data in most abstract form. Later by applying refining
tools the given data is progressed into a descent format which can be easily
processed by any of the computer based systems. While dealing the data
design, one has to remember that the format (rather design) of data (on
which we are currently working. exerts significant impact on the software
which is going to be developed. This can be analyzed by considering the
following states of development.
1
(a) Component Level: At this level we generally concentrate on the
available forms of data like data structures and is corresponding j
algorithms. This turns out to be necessary, since quality of end product
(software) depends primarily on this aspect of component level.

(b) Application Level: At this level, our attention shifts onto storage
aspects i.e., converting the given data model. into database. This

18

/
 remains important to achieve the commercial' objectives, which were Analysis and
estimated n the product. AppUcation
Design
(c) Business or Commercial Level : Once the data is stored in the
database, now we concentrate largely o~ improving its storage aspects
i.e., acquiring the required data with less effort applied: This can be
achieved by data ware housing mechanisms.

(ii) Architectural Design Elements: Architectural design is nothing but a

photocopy of the: end software which is going to be developed. It is
usually designed while considering following aspects:

• The knowledge on the application domain.

• By considering the analysis classes, their associated relationships

and also the collaborations existing between them.

• By considering various architectural pattern sets etc.,

(iii) Interface Design Elements: In general sense interface are just like
wiring provided in a given circuit i.e., it refers to paths or directions in
which the given information proceed. Basically these are three types of
interface design elements: .

• The User Interface

• External Interface

• Internal Interface

The User Interface accommodates following elements:

• Technical

• Aesthetic, and

• Ergonomic respectively.

The external interface defmes flow of information between the

components of two independent systems. The information related to these
interfaces is collected during requirement analysis phase. It is often
recommended to check these interfaces before the initiation of interface
design. As the information in this case usually flows into other system,
hence, it should include security as well as certain error checking
measures.

Internal Interface defines flow of information between various

components of a single system.

19

/ I
 Representation of interfaces is same as what used in UML. Hence,
Application
consider the following diagram.
Development
Life Cycle

. . «Interface»
item Listener

Check Box •..... "AWTevent

multi caster

«Interface»
item Listener

Fig. 1: Representation ofInterface in terms ofUML Notation

As shown in the above figure, an interface is usually represented in the

form of. a rectangle with a key word "interface" inscribed in the first
partition of the icon. Apart from this, the two icons represented on the
either sides of the interface or component. An interface can also be
represented as a small circle.

(iv) Component Level Design Element: As the name suggests, component

level design provides all details of a given software component. In order
to achieve this, the component design describes the representation of data
structure for orderly placement of objects, suitable algorithms to promote
processing internal to a given component and finally defines interface.

The icon used to represent a component is given below:

AWTevent
multi caster

Fig. 2: Component Icon

Name of the component is inscribed in the icon component along with

interface is shown below:

«Interface»
item Listener
AWTevent
multicaster

«Interface»
item Listener

Fig. 3: Component along with an Interface

20

/
 (v) Deployment Level Design Elements: This is usually the final design Analysis and
among all other designs narrated above. It usually describes the scenario Application
·of software functionality when all the subsystems are released to perform Design
ascertain~d ~nctionality in real environment. In order' to design such
instances, we usually resort to UML' S deployment diagram. Hence,
consider an example diagram in this r~gard:

«Desktop»
«Device»
RestaurantPC Termination
«Device»
Printer
OrdersDatabase
.
,

«Device»
receipesDatabase T-connector

Fig. 4 : The above Deployment Diagram reflects only a Single Instance of

Restaurant PC System

1.9 ARCHITECTURAL DESIGN

Software Architecture

Software architecture is a combination of certain number of components, along

with their relationships as well as their visible features.

A software engineer uses software architecture in many ways i.e., a software

architecture provides him specifications, through which he sets his goals, it
provides him information related to modifications to be made to the design at
the initial software development states etc., Hence, h can get rid of potential
risks easily at-the beginning stages of software development only.

As we are known to the definition of software architecture, now let us traverse

through its importance.

Importance of Software Architecture

With above illustrations we can predict the role of architecture in the software
development. Apart from this following. summary provides importance of
software architecture in the real world software development aspects.

21

/ I