Examining The Definition Of Software Architecture Information Technology Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Software Architecture essentially illustrates the practice of developing computer software. Architecture can be described as a fundamental organisation of a system, embedded in its components, their relationships to each other and the environment and the principles governing its design and evolution. Software Architecture also refers to the documentation needed for creating computer software. This documentation is produced to describe the system's software architecture thoroughly so that the software can be created. Software Architecture can be compared to building architecture in the way that both have a purpose, both use materials to create the project and both have documentation or blueprints for the project describing its structure. Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is described below:

"Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behaviour as specified in collaboration among those elements; composition of these structural and behavioural elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns."

Role of a Software Architect

The role of an architect is to create the system architecture and layout the various responsibilities of the stakeholders in the system. This includes documenting the structure of the system with design documentation to implementation documentation. Communication between software architects and stakeholders is vital as the architect must fully understand user requirements and business goals. Stakeholders can include users, architects, developers, designers, maintainers or system engineers. Software architects are possibly the most important part of a team responsible for building computer software as they provide the other members of the team with the conceptual views of the project. For example the software architect provides an implementation view for the programmers and this allows the programmers to create software to the standard of the users and also the software architect. Software Architects are also responsible for the key technical decisions that essentially decide the overall design and implementation of a project.

Software Architecture just like construction architecture can be good or bad architecture. By this we mean that the architecture can be done in a good way or a bad way. In order for a software architect to provide good architecture they must ensure that the architecture is resilient, simple and approachable. As well as this they must ensure that there is a balanced distribution of responsibilities and also ensure that they balance economic and technical constraints.

The below image shows the role of a software architect by illustrating its interactions with different sections of a project.


We can see in the above illustration that the software architect has a "hands on" approach to models such as deployment models, analysis models, design models and implementation models.

Responsibilities of a Software Architect

Software Architects have many responsibilities, however the main responsibility of a software architect is to provide the overall structure of a project. This involves the structure of 4 conceptual views such as the logical view, the process view, the implementation view and the deployment view. Each one of these views is structured by the software architect in order to provide the overall structure of the project. More responsibilities of a software architect can be seen below.

A Software Architect sets realistic objectives for a project so that the project can be completed to the standards of the user. Without realistic objectives the project may never be completed to these standards.

A Software Architect makes critical decisions about a project that define the directions which a project will take. These decisions define the characteristics of a system.

A Software Architect works very closely with executives to explain in detail the benefits of the project and to justify the investment which has been given to design a specified system.

A Software Architect motivates and inspires colleagues to enable them to apply the industries best practice to the project at hand. Colleagues must also have knowledge of the work of a software architect and be able to understand documented system architecture.

Comparison of two industrial software architecture design methods

Here I will be discussing the comparison between two industrial software architecture design methods. The methods I have chosen to compare are the 4 + 1 architecture framework and the RM-ODP architecture framework. The 4 + 1 architecture framework is a view model which was designed by Philippe Kruchten for describing the architecture of software. In order to describe software architecture, Philippe Kruchten came up with the idea to use a model composed of multiple views or perspectives. The model which he designed is made up of five main views and these are:

Logical view

Development view

Process view

Physical view


The logical view, also known as the design view, primarily supports the functional requirements for the system. This means that it is concerned with the functional requirements that the system provides to the users. The system is decomposed into key abstractions in the form of objects and object classes. Once this is done the logical architecture can be represented by means of class diagrams and sequence diagrams.

The development view, also known as the implementation view, describes the architecture of a system from the software developer's perspective. The software which is developed by the programmers is packaged into package libraries or subsystems and these subsystems are organised into layers and each of these layers provide well defined interfaces to the layers above them. Once this has all been done the development architecture can be represented by means of component diagrams and package diagrams.

The process view focuses mainly on scalability, concurrency, synchronization and the performance of the system at run time. It explains the processes within the system and how each of them communicates with each other across the system. To illustrate these processes and the communication between them we use activity diagrams and state diagrams.

The deployment view, also known as the physical view, illustrates the architecture of a system from the software engineer's point of view. The deployment view is represented by means of a deployment diagram which shows the nodes which are what the software is executed on and the dependencies between them.

Scenarios are the fifth view of the 4 + 1 architecture framework and they define a description of architecture by using use cases. These use cases describe sequences of interaction between objects and this is illustrated in use case diagrams.

This 4+1 view model has been used with success for many years and has allowed the various stakeholders to find what they want to know about the software architecture of a desired system.

The RM-ODP (Reference Model of Open Distributed Processing) architecture framework is a reference model used for standardization of open distributed processing. RM-ODP has four fundamental elements which include:

an object modelling approach to system specification

the specification of a system in terms of separate but interrelated viewpoint specifications

the definition of a system infrastructure providing distribution transparencies for system applications

a framework for assessing system conformance

RM-ODP also has five viewpoints which are used to solve complex problems within a system, each of these viewpoints allow a software architect and a systems stakeholders to identify problem areas within the many stages of the design of a system. Below you can see these five viewpoints:

The enterprise viewpoint

The information viewpoint

The computational viewpoint

The engineering viewpoint

The technology viewpoint

A viewpoint is a subdivision of a complete system which is used when dealing with complex systems to compile pieces of information relevant to an area of concern during the design of a system. Each of the above viewpoints is used to describe the architecture of software in their very own way. This method has proved to be successful when used with highly complex and large systems as the viewpoints allow architects to solve difficult problems during the analysis or design of a system.

The comparison between these two architecture design methods is shown within the views of the 4 + 1 model and the viewpoints of the RM-ODP model. However the RM-ODP architecture framework is more concerned with solving the major problems of a large complex system by breaking the whole system down into separate subdivisions where as the 4 + 1 architecture framework is divided into 5 views which can be referenced using UML diagrams for a more illustrated view of the architecture.

In conclusion we can see from this paper that software architecture underlies the practice of developing computer software in the sense of documentation, implementation and illustration. A software architect is a very important role in the development of a system and they have many important duties which must be achieved to fulfil the user's expectations.