Basic concepts of Software Architecture
A lot of people underestimate the importance of software architecture and some people just do not know what it is and what are the benefits of it. If you want to build a house, you must know its architecture. It’s the same fact with software architecture. It is the root of software.
Before diving into it, grab a cup of coffee. It is a long term.
A software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them and properties of both.
Let’s look at some of the implications of the definition:
1. Architecture is a set of software structures:
This is the first and most obvious implication of the definition.
A structure is the set of elements itself, as they exist in software. For example, a module structure is the set of the system’s modules and their organization. A module view is the representation of that structure, as documented and used by some system stakeholders.
There are three categories of architectural structures:
- Module structures: Some structures partition systems into implementation units, which are called modules. Module structures are static structures, in that they focus on the way the system’s functionality is divided up and assigned to implementation teams.
- Component-and-Connector (C&C) structures: The term ‘component’ is overloaded in software engineering. Basically, a component is always a runtime entity. Suppose, the system is to be built as a set of services. The services, the infrastructure they interact with and the synchronization and interaction relations among them form C&C structure.
- Allocation structures: This structure describes the mapping from software structures to the system’s organizational, developmental, installation and execution environment.
2. Architecture is an abstraction:
Architecture specifically omits certain information about elements that is not useful for reasoning about the system, i.e. it removes information that has no ramifications outside of a single element.
Architecture is concerned with the interface. Apart from this, though the architectural abstraction lets us look at the system in terms of its elements, how they are arranged, how they interact, how they are composed, what their properties are that support the system reasoning and so forth.
3. Every software system has a software architecture:
Even though every system has an architecture, it does not necessarily follow that architecture is known to anyone.
Perhaps all of the people who designed the system are long gone, the documentation has been vanished, the source code has been lost and all we have is executing binary code. This reveals the difference between the architecture of a system and the representation of that architecture.
4. Architecture includes behavior:
Architectural behavior embodies how elements interact with each other- which is clearly part of the definition of architecture.
When looking at the names of the boxes(databases, GUI etc.), a reader may well imagine the functionality and behaviors of the corresponding elements. This mental image approaches an architecture, but it springs from the imagination of the observer’s mind and relies on information that is not present.
Architectural behaviors must be considered and should be well documented as a part of software system.
5. Not all architectures are good architecture:
The definition is indifferent as to whether the architecture for a system is a good or a bad one.An Architecture may permit or preclude a system’s achievement of its behavioral, quality attributes and life-cycle requirements.
By now you must have understood that a good software architecture is extremely important for a software project. It creates a solid foundation for the software project, makes your platform scalable, increases performance of the platform and makes the platform faster.
