Software Design and Architecture

Engr Saiqa Anjum

Lecturer SE
Software Design and Architecture

Lecture 6
Software Design and Architecture
Decomposition View
 Compared to C&C view which reflects dynamic
information during runtime, decomposition view,
however, supplies more static information.
 There are two kinds of support from decomposition
view, as follows:
 The first feature is to define the vocabulary of system
and construct its logic model. Here, we decompose
the whole system into several logic concepts in top-
down style.
Software Design and Architecture
Decomposition View

 Thisprocess of divide and conquer can be carried out

recursively, gradually showing system detail more
and more clear, until the pieces which enable
personal development, test and management are
reached.
 Through this activity, useful and reuse-possible
concepts are picked out and extracted.
Software Design and Architecture
Decomposition View

 Then concepts are interconnected according to their

relationships in the real world, including use,
generalization, association, aggregation, composite
and so on (generalization is the special case of use,
while aggregation and composite are special cases of
association).
Software Design and Architecture
Decomposition View

 More advanced relationship properties, including

multiplicity and association direction, are also used if
necessary.
 In addition, we can define types of components and
connectors facilitating C&C view.
 Concepts and their relationships construct the logic
model of a system.
Software Design and Architecture
Decomposition View

 Logic model is especially useful for domain software

development because building blocks based on the
model reduce the work needed in similar
development time and time again, because we can
reuse existing blocks implementing those concepts
and relationships, or purchase them from market.
Software Design and Architecture
Decomposition View
EXAMPLE COURSE REGISTER SYSTEM

 Ifa courses-register system is under design, we may

define concepts such as student, department,
course, and schedule.
 More concepts will be added if runtime is concerned,
such as course repository.
Software Design and Architecture
Decomposition View
EXAMPLE COURSE REGISTER SYSTEM

 Examples of relationships may be that "each

department are composed by many students, but
each student has to attach to a single department",
or "students are categorized as undergraduate,
graduate and PhD."
Software Design and Architecture
Decomposition View
EXAMPLE COURSE REGISTER SYSTEM
 During the decomposition process, concepts and
behaviors are divided.
 For example, student may be considered as the
combination of ID, name, age, department, address,
email and phone number, in which ID may be then
divided into several sections regulated by a regular
expression.
Software Design and Architecture
Decomposition View
EXAMPLE COURSE REGISTER SYSTEM

 The behavior of register can be described as a

number of steps, such as logging in, searching course
information, checking course availability, updating
course information and logging out.
Software Design and Architecture
Decomposition View
 When development is being performed, architects
cluster several concepts, as well as their
relationships, into an implementation or test unit,
called module, within which elements should work
together in common ways to provide cooperative
behaviors that are bigger than all of its parts.
 It is a ubiquitous (global) confusion and
misunderstanding between component and module,
since they have some link hazily.
Software Design and Architecture
Decomposition View
 But they do not stand in the same perspective. In
fact, they contain different meanings under different
concerns.
 Component is the logic abstract of functional unit of
runtime, while module is the cluster benefiting
design, implementation, test and management.
 It is possible that a module contains exactly the code
executed as a single component, but this relationship
is not of necessity.
Software Design and Architecture
Decomposition View

 Another feature of decomposition view is to divide

developers' work, making cooperation feasible.
 After decomposition, pieces or modules can be
mapped to organizations or teams of developers,
which own responsibility to perform management ,
detailed analysis, implementation and test.
Software Design and Architecture
Decomposition View

 Meanwhile, the decomposition structure has

benefits to system’s learning and understanding,
because it avoids the possibility that novices are
trapped into a mess of detailed codes and navigates
them in top-down style gradually.
Software Design and Architecture
Decomposition View
There are two bans in decomposition views.
 The first one is that no loop should exist in
decomposition view, considering the recursive
decomposition process needs an end point;
 the second one is that no decomposition piece or
module should be contained in more than one
parent module, since confusion of responsibility may
be bred.
Software Design and Architecture
Decomposition View
Software Design and Architecture
CASCADING STYLE SHEETS (CSS)
Software Design and Architecture
References

Multiple sources.

Acknowledgement
Special thanks to all of the computer scientists,
engineers, book authors and others for providing such
a useful information.
HAVE A NICE DAY

Q/A