In the second half of the 20th century researchers tried to improve, simplify and speed up software development by having a look at the fundamental principles behind the architectural development. Applying these software architecture principles helped to design and develop software systems. This paper will introduce the very beginning of software architecture and how it contributed to solving open issues arising with today’s software by comparing abstracts of Parnas and Shaw who published two of the earliest papers in this field.
Abstract
In the second half of the 20th century researchers tried to improve, simplify and speed up software development by having a look at the fundamental principles behind the architectural development. Applying these software architecture principles helped to design and develop software systems. This paper will introduce the very beginning of software architecture and how it contributed to solving open issues arising with today’s software by comparing abstracts of Parnas and Shaw who published two of the earliest papers in this field.
1. Introduction
Software architecture makes principal decisions about the system and is defined as the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them [3]. With the evolution of software systems it became more difficult for software engineers to make software easier to produce, decompose it efficiently and structure procedures while meeting quality attributes as software systems became larger and more complex. Therefore the importance of software systems designs and predicting problems that may arise, increased.
To get a deeper understanding about the importance of software architecture and the varieties of decomposition, this paper analyses and compares ‘On the criteria to be used in decomposing systems into modules’ by D.L Parnas and ‘Large scale systems require higher-level abstractions’ by Mary Shaw.
Parnas, a Canadian early pioneer in software engineering stated that by hiding information the flexibility, comprehensibility and development time of software systems will be improved. Therefore he breaks software systems down into modules that can interact.
In 1989 Shaw, known for her work in the field of software architecture, outlined the requirement of new kinds of abstractions that capture essential properties of major subsystems and the ways they interact.
Furthermore she extended Parnas observations on modules and hierarchy[2].
The critical analysis of these two papers presents different approaches to face architecture design problems, outlines which criteria are still relevant for modern software architecture and gives an insight into the possible development of this field.
2. Discussion
‘On the criteria to be used in decomposing systems into modules’ is the first article to be considered. Parnas work was only preceded by Edsger Dijkstra and therefore contributed to the fundament of software architecture and its practices. By comparing the conventional flowchart approach of dividing the major steps in the processing into modules with the unconventional modularization based on information hiding he showed that the criteria for modularization determines the efficiency of the system and contributes to the changeability, independent development and the comprehensibility of it. While the line of step-by step procedures is more efficient for small systems, the concept of object oriented design, where modules hide the architecture design decision and reveal as little as possible about inner workings, reduces errors within the system’s reusability and therefore is preferable when it comes to large systems[1].
Parnas introduced the hierarchical structure as a further property of the system structure, modularization is essential for. The dependency between modules defines the layer and therefore the layout of the system. This results in a loosely coupled software system where upper levels can be simplified by using services provided by lower levels. Modules at one level can perform in any order independently which leads to parallel computation[1].
In 1989 Shaw introduced a new design level “above the traditional module” and outlined the importance of the architectural abstraction representing subsystems and how they interact. In her work she did not only refer to Parnas’ idea of information hiding but extended it by introducing different abstractions appropriating at different points in the software design and development process to better understand and develop large-scale systems. She described different organization structures and their capabilities while stating that most software engineers are badly educated in implementing the right patterns. The system organizations result from combined subsystems that perform clear functions within the system, have internal structures, allow different implementations of their functions and are combined into systems in a number of ways[2]. Therefore the knowledge about the software architecture of a system has to be codified and specified to provide a “shared understanding of design and implementation strategies and standards”[2]. However Shaw was convinced that software architecture had to become more mature before using high-level patterns.
Parnas and Shaw described the decomposition of software systems as a software architecture design element many architecture design patterns still rely on today. While Parnas defined the criteria of modularization and different types of algorithm data Shaw concentrated on abstract programming and outlined the educational problem in terms of software architecture.
With his revolutionary concepts in modular programming Parnas pioneered object oriented programming, gave programmers the ability to work in teams on different parts of the program at the same time while increasing its understandability. Besides the hierarchical structure increased program efficiency by running different modules at the same time.
However, both papers did not take into consideration that it gets harder to keep the balance between setting up a complex system with integrated modules and maintaining it, keeping it portable and testing it. Furthermore none of them addressed the creation, structure and behavior of objects in complex software systems which are nowadays seen as very important in terms of object oriented programming.
3. Critical Analysis
Nowadays, abstraction of small and large systems which includes the principles pioneered by Parnas and Shaw is still mandatory in modern software architecture when developing modern systems. For example one of the highest engineering goals remains “the decomposition of the work into cooperating processes” [4]. Complexity and size determining the variety of levels of the abstraction decomposition was added by Shaw. She expanded Parnas’ work by describing different abstraction levels and combining them in the software architecture level. Furthermore she applied Parnas’ modularization principles to an entire subsystem. Nevertheless Shaw missed to explain how modules should be identified and which lower-level subsystems should be used.
Modern software architects need to look at software in three ways: How it is structured as a set of implementation units; how it is structured as a set of elements that have runtime behavior and interaction; how it relates to non-structures and its environment. This analysis includes the consideration of architectural abstraction, views and hierarchy. Therefore software architects use different descriptions of elements and relation types together with a set of constraints on how they may be used, so called patterns[3].
There are two different approaches of architecture documentation. Parnas observation about different structures that can describe a software resulted in the view concept we know as 4+1 views by Kruchten. The Three Viewtype approach contains the Module Viewtype, the Component and Connector Viewtype and the Allocation Viewtype. Some of the Component and Connector Viewtype styles, like the Pipes and Filters style were already presented by Shaw. The complexity of these styles makes them preferable for the decomposition of large-scale systems.
In retrospective from the beginning of Software architecture, a trend towards capturing and abstracting details is clearly visible. Abstraction helped software engineers reducing the amount of code and getting away from a completely manual software. The process might continue until software is able to develop its architecture automatically while the task of software architects changes into focusing on views and structures.
New forms like cloud computing require an abstract set of services what supports the trend towards entire system abstraction. Besides, the microservice architectural style with small immutable services that are decoupled becomes more popular. This supports independency and speeds up the testing, development and implementation of applications[5].
The quality attributes shifted from reliability, usability and configurability towards an increasing importance of scalability, security and performance. This gave the opportunity for new systems like the ‘shared-nothing’ system.
Besides, neither Parnas nor Shaw mentioned the role of software architecture in a project. It does not only draw the overall picture but has the additional benefit of simplifying the communication with stakeholders or clients. If a project is planned and organized properly it makes it easy to verify that all the requirements are met.
These days, clients ask for fast developed programs. Therefore the method of developing software systems also changes from the static waterfall approach to an agile method. Therefore the work of the software architect changes from a one-time task at the beginning of the project to aligning new requirements with the big picture that evolves with the time as well.
4. Conclusion
The work of both Parnas and Shaw pioneered software architecture and led to further developments in software abstraction and system automation. Parnas developed the criteria and principles of modularization and information hiding while Shaw extended his observations at new abstraction levels she constructed and described. These outstanding findings are still applied nowadays. Nevertheless both did not consider complicated large-scale systems that have required new systems at a later stage.
In the future, the tasks of software engineers defining the right styles might be overtaken by the system that creates the most efficient way automatically. Consequently, just as Parnas invented modules that work independently, future software architecture might observe the abstraction of entire systems that can be treated in the same way. Furthermore, upcoming trends like cognitive computing will support this movement and will require new systems as software architecture keeps evolving.
[...]
- Quote paper
- Saskia Siebert (Author), 2017, The Beginning of Software Architecture, Munich, GRIN Verlag, https://www.grin.com/document/414640
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.