Individual Essay on Software Architecture Parnas vs Shaw

Student Name: Raeesah Joowalay Student ID: s2852595

Workshop No:2 Group No: 5

Abstract
In a progressive technology era that we
comprise of today, it is of prodigious importance
that we embrace the factual understanding of the
evolution of software architecture and its
significance in facilitating people to adjust and
adapt to the changes of everyday lives.
This essay studies two pioneer papers about
software architecture and conglomerates the
common principles and ideologies of software
architecture. This study clearly shows the evolution
of software architecture and the foundations and
discoveries that will suffice in understanding its
importance and relevance in todays world.

Introduction
Over the past 30 years the advancement of
software architecture industry has been renowned
with each design stage developed to give optimum
results and implemented within the complexity of
systems to forgo a more simple and structured
overview. Software architecture is imperative as it
puts in place provisions and guidelines that are
necessities within the technology epoch that we
adhere to. Therefore we need to have an idealistic
understanding of its history and how it has evolved
over the years by observing the overall architecture
of a system and how we can decompose of the
system but maintain, test and implement designs
patterns into it. This essays studies two historical
papers about software architecture and its
developments and findings through-out the years.
One paper is a problematic research study and
evolution of software architecture and the other
paper is a more specified piece with realistic
approaches to software architecture. This first paper
was published in December 1972 by David Parnas.
The main ideas in that paper are understanding the
mechanisms of module decomposition and
modularization. The second paper was published in
1989 by Mary Shaw, fifteen years after Parnas
paper and covers the main ideas of abstractions and
view types of software architecture.
After studying the two papers, and compared

with what we have learnt to date in our Software

Architecture course, we found that Shaws ideas
have a more specified set of disciplinarians that are
relatively understandable with perceptible
similarities to what we have learnt. Whereas,
Parnas paper sets the initial groundwork and
findings of modularization. We propose the reason
for that is software architecture is built and based
on a series of trial and error principles which Shaw
has been able to embrace years after Parnas
findings. We predict that software architecture is a
form of rules and guidelines that help people to
undergo abstractions of systems at the highest level
of solutions.
The rest of the essay is organised as follows: A
detailed discussion of Parnas and Shaws findings
and their accomplishments, followed by their
similarities and differences between their papers
and what they both may have missed. A critical
analysis of the relationship between the two papers
with recent concepts in relation to what we have
gathered and how we generated ideas which leads
to our contributions. Real-world examples will be
defined to support our ideas followed by open
issues that have yet to be solved and possible future
research (methods, plans) to elucidate those open
issues. To conclude our findings; begins with a
clear insight into the future of software
architecture, how it ties to course concepts and the
summarization of arguments made throughout the
rest of the paper will demonstrate a clear learning
and understanding of software architecture.

Discussion
In the first paper Parnas discusses
modularization and defines it As a mechanism for
improving the flexibility and comprehensibility of a
system while allowing the shortening of its
development time. (Parnas, 1972, p.1). Parnas
introduces module decomposition whereby he takes
a system and breaks down the program through two
forms of modularization. These two forms of
modularization are based on design verdicts rather
than a sequence of defined stages, to find a way of

altering parts of the program without any slack time

throughout the development which optimises the
completion time. The first example of
Modularization falls along the lines of practical and
technical responsibility and guidelines. This is
described as the flowchart method which is
broken down into five modules (Parnas, 1972, p.
1053). The second example of modularization is
described as Information Hiding and is broken
down into six modules.
Parnas makes a breakthrough in the second
modularization: Every module in the second
decomposition is characterized by its knowledge of
a design decision which it hides from all others. Its
interface or definition was chosen to reveal as little
as possible about its inner workings. (Parnas,
1972, p. 1057). These particular sentences are of
prodigious significance as this is where Parnas
brings awareness of Information Hiding within
Software Architecture which helps us to understand
what it aims to achieve, that is protect information
and parts of a program from extensive
modification. (Rogers, 2001, p1).
With both modularization examples thoroughly
defined, Parnas has been able to make a clear
finding by demonstrating that the use of flowcharts
should not be initially used in the decomposition of
systems into modules. (Parnas, 1972, p.1058).
In the second paper Shaw introduces and
discusses abstraction techniques and large scale
systems and enforces its importance as through the
argument for a deeper look into abstractions and
inner collaborations of design patterns, especially
of larger scale systems and subsystems can be
handled without affecting the entire system.
Shaw covers a variety of topics that are of
concern, however in section 3. Composition of
Systems from Subsystems, Shaw makes an
observations about the relationship between large
systems and subsystems and how they subsystems
should be dealt with according to their own internal
structures. Moreover, understanding the
characteristics of subsystems and implementing the
design process at system levels. (Shaw, 1989,
p.144).
This opens a broader spectrum for
implementation of higher-level design patterns. It
offers a set of predefined subsystems and specifies
their responsibilities that are best suited to their
functions and accountabilities. (Anthony, Garland,
2003, p.216). However, Shaw concludes by stating
that there was insufficient groundwork within
architecture to provide enough evidence on the
development and support of such high-level
patterns (Shaw, 1989, p.145).
Both Parnas and Shaws work depict on

software architecture designs that have had

somewhat impact in the evolutionary foundation of
understanding functional and technical attributes of
architecture. However, within todays object
orientated world, their synopsis fails to take into
account the vast areas of software designs with
high-level intrinsic complexity of structural
elements associated with essential behaviour and
qualities such as reliability and scalability of
systems. (Eeles, 2006, p.1). Nevertheless, as we
have since progressed into the new era of
technology some of these concerns have been
addressed through the formation of modern
architectural and module class level design patterns
which we have been covering in our Software
architecture course.

Critical Analysis
Parnas paper identifies the early findings of
Information Hiding which have evolved over the
years and become a foundation for software
elements. Shaws paper is a furtherance of Parnas
work with a more clear aspect of abstraction
techniques of large scale systems. In hindsight,
Shaw was able to express interest in a more logical
context by extending on Parnas main ideas about
modules and explaining how instead of
approaching modules at a singularly level, it should
be noted that with larger-scale systems, they ought
to be categorized according to their level of
complexity and quality attributes which provides
opportunity to maintain, test and change parts of
the system without impact on the entire system.
Shaw states: This level of system organization and
design is the software architecture level. this
enforces Shaws arguments and discussions that are
evident in section 2 of her paper where Software
Architecture Level of Design is discussed. (Shaw,
1989, p.144).
Architecture can be defined in numerous ways,
however it somewhat delineates these main points;
design decisions and principals, software elements
and relationships. Architecture is the fundamental
organization of a system embodied in
its components, their relationships to each other,
and to the environment, and the principles guiding
its design and evolution. (IEEE, 1995, p.1471).
Software architecture is represented through
different view types that serve for different
purposes such as large scale systems which inhibit
subsystems that can be dealt with according to
provisions set in place. Designing architecture can
be simple or complex depending on the system.
Design patterns and tactics are used as they are
articulated by functional and non-functional

requirements. One book that provides sound

information on the topic how to design architecture
is Design Patterns: Elements of Reusable ObjectOrientated Software (Gamma, Helm, Johnson,
Vlissides, 1994). It introduced a variety of
developers and architects to the idea of reusable
design patterns that enables them to have a clear
understanding on how to maintain, test and deal
with high complexity modules and classes in an
orderly manner.
After reading both Parnas and Shaws papers we
found that in our ever changing world of
technology, the concepts of architecture will
continuously evolve to keep up with the
development of software architecture as it is driven
by the demand of new software systems which aim
to deliver a higher level of complexity and quality.
A real life example is the new social software such
as face book. The Engineering manager at
Facebook S.Kumar has stated that Over the years,
the software architecture at Facebook has been
built to not only scale efficiently but also to support
the different needs of a large number of new
products. (Kumar, 2012, p.1). He discusses the
demand for software architecture 15 years ago and
the evolution of his findings which he illustrates
through a few cases. Overall he encapsulates the
importance of software architecture on a large scale
system by identifying certain quality attributes
(functionality, performance and scalability) that
form the grounding of a successful system.

Conclusion
Even though software architecture has
developed rapidly in the last few decades, there is
however still a number of open problems from a
software architecture perspective. As the
fundamental hardware intensifies in capacity and
intricacy the need for a more improvised level of
simplicity of systems is needed. Shaws synopsis
indicated that there is still several problem areas to
attack, however in time when the problem arises, it
is expected that software architects are able to
overcome those obstacles with the direction and
knowledge of previous groundworks formulated

through research and evolutionary papers like

Parnas and Shaws.
In this essay we have delivered our views and
findings based on Parnas and Shaws papers. We
have found that Parnas works shaped the
fundamentals for a variety of design patterns which
till today are implemented in modern software
systems. Moreover, we have learnt from Shaws
continuation of Parnas work and further readings
that through abstraction techniques and design
decisions we are able to adapt and maintain high
level complex systems via subsystems, as they
allow for reusable software design patterns which
gives us the ability to build larger systems that can
be easily modified. However, as we are forever
evolving in technology we will need to advance in
our understandings of software architecture in the
near future.

References
[1] David L. Parnas. On the Criteria to be Used on
Decomposing Systems into Modules, Communications
of the ACM, 15(12):1053-1058, 1972.
[2] Mary Shaw. Larger Scale Systems Require HigherLevel Abstractions, Proceedings of the Fifth
International Workshop on Software Specifications and
Design, 143-146, published 1989.
[3] J. Garland, R. Anthony. Large-Scale Software
Architecture: A Practical Guide using UML, 2003.
[4] P.Rogers. Encapsulation is not information hiding:
JavaWorld. 2001.
[5] P.Eeles. The Process of Software Architecting.
Technical Report, 2006.
[6] IEEE Computer Society, IEEE Standard for
Information Technology -- Software Life Cycle
Processes. IEEE Std 12207-1995.
[7] E. Gamma, R. Helm, R. Johnson & J. Vlissides.
Design Patterns: Elements of Reusable Object-Oriented
Software, 1994.
[8] S.Kumar. Evolution of Software Architecture at
Facebook, Computer Science, 2012.