CS603- Software Architecture and Design

Topic: 1

Software Application
Software application development process consist on different phases mentioned in the below figure.
Planning, analysis, design, deployment and implementation, testing and maintenance are steps (phases)
that involved in software development.

Topic: 2

Customer Requirements
Customer requirements mean what customers or users required from the system. How the system
behaves, what are the tasks need to perform by the system, how users will interact with the
system, and how the system will present the output. The customer is a significant stakeholder
that plays a vital role in the correct development, successful implementation, and system
utilization.
Domain Knowledge
Domain knowledge means the information and having expertise about the particular environment
and industry in which the developed system will operate. For example, knowledge of the
pharmaceutical industry and telecom industry.

Domain Knowledge Expert Example

A person has knowledge of hospitalization process and its major departments.

System Specification

A system specification can be a written document containing a detailed description of all aspects
of the system to be built before the project commences.

Topic 3:

What is poorly designed software?

Poorly designed means the designer did not spend a good amount of time to analysis software
requirements to design. In start, adding small features to show working product to a client is very easy but
with the passage of time, software size increased that makes it difficult to understand and make further
modifications and adding more features.

What is extendable design?

Change in software requirements and adding more features is very much natural in software development
and maintenance process. Well-designed software is easy to understand and welcomes changes in
requirements, future modifications and adding new features.

Topic 4:

Complexity Vs Size (Example of a Building)

The building in the below image is tall with many floors; the building may contain many offices,
commercial shops, parking areas, and apartments. Each entity (offices, shops, .etc.) have different kind of
facilities, fire exit directions, earthquake resistance, sanitary and sewerage. Due to its large size, any
addition or modification will be hard to manage and demand excellent design and architectural skills. In
contrast, a single room house is easy to manage and extend.

Complexity VS Size (Example of two different Applications)

A calculator with four functionalities, addition, subtraction, multiplication, and division, is easy to
manage, modify, or add any new functionality. While a big application, enterprise resource planning
(ERP), contains many different integrated components, it is hard to modify, manage, or add a new feature.
Because a calculator has 100 to 200 lines of code, but an ERP solution has millions of lines of code so a
single change in ERP may affect other components. You can imagine the complexity relation with the
size in the above example; the bigger the size, the bigger the complexity, while the smaller the size, the
smaller the complexity.
Topic 5

Types of Complexities
 Essential Complexities
 Accidental complexities

Essential Complexities

You will understand Essential Complexities after reading below different descriptions of
essential complexities.

 Essential Complexity is just the nature of the beast you are trying to tame.
 Essential Complexity represents the difficulty inherent in any problem.
 Essential Complexity is Complexity inherent to the problem. It is Complexity related to
the problem and cannot remove.
 Essential Complexity is how hard something is to do, regardless of how experienced you
are, what tools you use or what new and flashy architecture pattern you used to solve the
problem. Essential Complexity is Complexity inherent to the problem.
 Essential Complexity is the entanglement/combination of components/ideas in software
necessary for solving the problem at hand. It cannot avoid.

Essential Complexities Examples

Example 1

If users need a program to do 30 things, then those 30 things are essential; you cannot simply
take out a few of them to make the software less complex. Whenever you are solving a problem,
there are just some areas of complexity that cannot be whittled down.

Example 2

Coordinating a nation’s air traffic is an inherently complex problem. Every plane’s exact position
(including altitude), speed, direction, and destination must be tracked in real-time to prevent mid-
air and runway collisions. The flight schedules of aircraft must be managed to avoid airport
congestion in a continuously changing environment—a severe change in weather throws the
entire schedule out of whack.

Accidental Complexities

You will understand Essential Complexities after reading below different descriptions of
essential complexities.

 Accidental Complexity is Complexity not related to the problem. Ben Mosely and Peter
Marks describe it as a “mishap.” It is Complexity from the fault of the developer and
happens to be there.
  Accidental Complexity is the entanglement of components/ideas that is not necessary for
solving the problem. This Complexity is accidental because someone probably didn’t
think hard enough before unnecessarily tying things together. As a result, the software is
harder to understand than it should be.
 Accidental Complexity grows from the things we feel we must build to mitigate essential
Complexity.

Accidental Complexities Examples

Example 1

Accidental complexity refers to challenges that developers unintentionally make for themselves
due to trying to solve a problem. (Fortunately, this kind of complexity can also be fixed or
improved by developers.)

Example 2

Developers bring complexity while writing the program. This type of complexity is called
accidental complexity.

How to remove accidental complexities?

Accidental complexities can be removed or reduce with the better design.

Topic 6

Why software design is very important to manage complexity?

One of the most important techniques for managing software complexity is to design systems so that
developers only need to face a small fraction of the overall complexity at any given time. Because
software designer provides a road map (blueprint) to the developer in which he mentions the system's
overall structure.

What is abstraction?
An abstraction is a simplified view of an entity, which omits unimportant details. The software designer
ignores the minor details attached to the problem and focused on the high-level details.

For example, a software designer designs the system's overall structure instead of working on the minor
details of the application, such as the color of user interface forms and font styles of text.

Why software design is hard?

The fundamental problem is that designers must use current information to predict a future state that will
not come about unless their predictions are correct. The outcome of designing has to be assumed before
the means of achieving it can be explored: the designers have to work backward in time from an assumed
effect upon the world to the beginning of a chain of events that will bring the effect about.

Topic 7

What is Art?
Art is a diverse range of human activities involving creative imagination to express technical proficiency,
beauty, emotional power, or conceptual ideas.

What is Science?
 Science is made up of fundamental principles, which can be taught as truth.
 A branch of knowledge or study dealing with a body of facts or truths systematically arranged
and showing the operation of general laws.
Topic 10

Divide and Conquer

This topic is related to a strategy for solving a problem. If a problem is P and it is a large problem.
Suppose its size is n. Then we will divide P into smaller sub-problems P1, P2, P3……. Pk. So a big
problem has been divided into smaller sub-problems. Obtaining a solution to each smaller problem is easy
rather than solving a big problem at once. All sub-problems are solved individually. After getting the
solution to each sub-problem, combine all solutions into one big solution of the one big problem. If the
sub-problem is also big then apply the same divide and conquer strategy to divide this sub-problem
further.
Modularity
The dictionary defines module as “each of a set of standardized parts or independent units that can be
used to construct a more complex structure.”

For example: ‘ships are now built in modules rather than built in a whole from the base up’.
In above figure, you can imagine that four individual modules have been solved individually then
combined all modules into one combined solution.

Hierarchical Organization / Structure

A big problem is broken into smaller meaningful parts (Sub-systems) that can be solved individually then
we need to combine all these parts that depict the solution of a big problem. But how will we know which
part will be integrated with which part? How we will know, which part will be top-level and other parts
will come as the sub-part of the top-level part. So Hierarchical Organization provides the solution to
organize each part in proper Hierarchy/structure.
Information Hiding
 A component encapsulates its behaviors and data, hiding the implementation details from other
components. Modules should be designed so that information (i.e., algorithms and data)
contained within one module is inaccessible to other modules that have no need for such
information.
 Information hiding, the purpose of information hiding is to separate interface from
implementation. By hiding the implementation details that are likely to change, encapsulation
allows for flexibility in design. For example, a stack interface can define two public operations,
push and pop, that are available to other parts of the program. However, its internal data
organization, e.g., whether to use a linked list or an array for storing stack elements, can be
hidden.

Abstraction
Transitioning your thought process from program design to software design involves the use of
abstraction. When designing software, you think of ways to abstract away certain details. This is typically
done by grouping certain details together based on shared characteristics or purposes. These shared
characteristics or purposes are then a way to generalize your design. For example, a programmer may
think about a soccer ball, tennis ball, baseball, and softball as distinct types of items. A software designer
would generalize these items by classifying all of them as a type of ball that share certain characteristics
(e.g., they are all spheres with a center point and radius) and purposes (e.g., they are all struck by an
object). (Reference Book: Guide to Efficient Software Design by David P. Voorhees)

Abstraction Hand-on-Exercise
You are required to explain and discuss below image moderate discussion board.
Topic 12

Why code reuse is important?

If you have developed a software, library, class, written an algorithm or written a function. If you have
written it well and test properly. Moreover, this functionality is used repeatedly in your software. Its mean
that you can call/copy/paste this functionality in your code. In return, your development effort will be
less, time will be saved and you can utilize your time efficiently. One more benefit of code reuse is an
enhancement in the quality. For example, a code written that tested multiple times and used in different
locations in your code will increase the quality of the software and boost the confidence.

Software Quality in regard to Design

The concept of quality is a familiar one, although we tend to associate it with properties that arise from
the tasks of construction rather than with those of design. Asked for examples of ‘good’ quality, many
people are likely to identify such examples as well-made joints on an item of furniture, the quality of the
paintwork on an expensive car, or the texture of a woven fabric. All these are examples of quality of
construction rather than of design, yet quality in construction depends upon good design: to achieve a
high-quality product high standards are needed in both, and in order to achieve high standards of quality
in design products, one needs to seek high standards of quality in the design process. Unfortunately,
quality is a concept that can rarely be related to any absolutes, and even for manufactured items ideas
about quality usually cannot be usefully measured on any absolute scale. The best that we can usually do
is to rank items on an ordinal scale, as when we say that we believe the construction of this coffee table is
better than that of another, in terms of materials used and the workmanship it exhibits. However, we lack
any means of defining how much better the one is than the other. When it comes to assessing design,
rather than construction, the problem is, if anything, worse. Quality in design is often associated with
visual properties, as when we appraise the quality typefaces, furniture and clothes. We associate elegance
with good design, yet it offers no help in quantifying our thinking and, even worse, is likely to have
ephemeral aspects: it may be strongly influenced by our ideas about fashion – so creating a context for
quality. (As an example, a 1930s radio set might look quite in place in a room that is furnished in 1930s
style, but would be most unsuited to a room that was furnished in the style of the 1980s.)

No matter how good the design is, in terms of proportions, efficient use of materials and ease of
construction and modification, our ideas about its quality will still be very largely influenced by the actual
construction. If it is badly assembled, then, regardless of how good its design may be, we will not
consider it to be of good quality. Equally, if the design is poor, no amount of good craftsmanship applied
to its construction will be able to disguise its fundamental failings. (The door may be well made and may
close well, but if it is positioned so that we graze our knuckles each time it is opened, then we will still
find it inconvenient to use.)

[Book: Software Design by David Budgen]

Exercise: Analyze the below image regarding code reusability and describe
that what comes to your mind
Topic 14

Constraint

A constraint is a decision over which you have little or no control as a designer/ architect. Your job is just
to satisfy to design the best system that you can, despite the constraints you face. Sometimes you might
be able to argue for loosening a constraint, but in most cases, you have no choice but to design around the
constraints.

Designer’s Communication Channels

A software designer may need to acquire some degree of ‘domain knowledge’ as a routine part of the
input needed for undertaking any particular design task. Below figure present, the different
communication channels (Inputs to the design process) through which the designer acquire the
information needed in the design process.

Topic 15

Maintainability
As systems get larger and more costly, the need to offset this by ensuring a long lifetime in service
increases in parallel. In order to achieve this, designs must allow for future modification.
Simplicity
A characteristic of almost all good designs, in whatever sphere of activity they are produced, is a basic
simplicity. A good design meets its objectives and has no additional embellishments that detract from its
main purpose.

Reusability Phenomenon
The concept of reuse makes an explicit appearance in the definition provided by Brown and Short, and
implicit appearances in the others. Strictly, of course, reuse is not an essential characteristic for a
component, only a desirable one. If a large system contains one or two uniquely crafted components
among a set of reused ones, then this can be considered as a quite pragmatic design decision that reduces
the detailed design problem to that of designing only a few components, rather than a whole system

Jones says,

“Most experienced programmers have private libraries which allow them to develop software with about
30% reused code by volume. Reusability at the corporate level aims for 75% reused code by volume, and
requires special library and administrative support. Corporate reusable code also implies changes in
project accounting and measurement practices to give credit for reusability”

Van Snyder points out,

“We conjecture that barriers to reuse are not on the producer side, but on the consumer side. If a
software engineer, a potential consumer of standardized software components, perceives it to be more
expensive to find a component that meets his need, and so verify, than to write one anew, a new,
duplicative component will be written. Notice we said perceives above. It doesn't matter what the true
cost of reconstruction is. Reuse has been successful for mathematical software for two reasons: (I) It is
arcane, requiring an enormous intellectual input per line of code; and (2) there is a rich and standard
nomenclature, namely mathematics, to describe the functionality of each component. Thus, the cost to
reconstruct a component of mathematical software is high, and the cost to discover the functionality of an
existing component is low. The long tradition of professional journals publishing and collecting
algorithms, and offering them at modest cost, and commercial concerns offering very high quality
algorithms at somewhat higher but still modest cost, makes discovering a component that meets one's
need simpler than in many other disciplines, where it is sometimes not possible to specify one's need
precisely and tersely. These factors collaborate to make it more attractive to reuse rather than to reinvent
mathematical software.”

Parnas writes,

“Reuse is something that is far easier to say than to do. Doing it requires both good design and very
good documentation. Even when we see good design, which is still infrequently, we won't see the
components reused without good documentation.”

[Book: The Mythical Man-Month]

Portability
The system's level of independence on software and hardware platforms. Systems developed using high-
level programming languages usually have good portability. One typical example is Java — most Java
programs need only be compiled once and can run everywhere.

[Book: Software Architecture and Design Illuminated]