Software Architecture
The software architecture of a program or computing system can be 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. It encompasses the structures of large software systems by defining an abstract view of the system, eliminating details of implementation, algorithm, & data representation but concentrating on the behavior & interaction of “black box” elements.
What makes a Good Software Architecture?
There is no such thing as inherently good or bad architecture. Normally Architectures are more or less fit for some stated purpose. As an example: a distributed 3tier clientserver architecture may be ideal for an enterprise financial management system, but would likely be inappropriate for an avionics application.
Prescriptive vs. Descriptive Architecture
When it comes to the types of Software Architectures, there are two main types Prescriptive and Descriptive that capture the different accept of a particular system.
A system’s prescriptive architecture captures the design decisions made prior to the system’s construction It can be named as the as-conceived or as-intended architecture. On the other hand, a system’s descriptive architecture describes how the system has been built in the actual world. This will be the as-implemented or as-realized architecture.
Architectural Evolution
When a system gets evolved its prescriptive and descriptive architectures get modified accordingly. Ideally in the practical environment, descriptive architecture gets modified directly. Developer sloppiness perception of short deadlines which prevent thinking through and documenting, lack of documented prescriptive architecture and need or desire for code optimizations are some reasons for the architectural Evolution.
Software Architecture’s Elements
When it comes to the process of forming a software architecture, it should have different elements to describe and represent each and every part of the software architecture and how the data flow and interaction happens. These elements can be described as follows,
Components: the elements that encapsulate processing and data in a system’s architecture are referred to as software components and they typically provide application-specific services.
Connectors: used to represent the interaction among the components in software architecture. Connectors typically provide application-independent interaction facilities and in many software systems connectors are usually simple procedure calls or shared data accesses.
Architectural Styles vs Architectural Patterns
“ Architectural styles are strategic while architectural patterns are tactical. ”
Software Architectural styles can be identified as a collection of architectural
design decisions that are applicable in a given development context and constrain architectural design decisions that are specific to a particular system within that context.
While software architectural styles define a high-level abstraction of the application design architectural Pattern is a way to implement an architectural style. A widely used pattern in modern distributed systems is the three-tiered system pattern.
Example for architectural styles: Object-Oriented Style
Components are objects which are composed of the Data and associated operations. These objects are responsible for their internal representation
and this internal representation is hidden from other objects.
Connectors are messages and method invocations.
Example for architectural patterns: Three-Tiered Pattern
Front Tier: Contains the user interface functionality to access the system’s services.
Middle Tier: Contains the application’s major functionality.
Back Tier: Contains the application’s data access and storage functionality.
Domain-Specific Software Architecture
The main objective of Domain-Specific Software Architecture is capturing and characterizing the best solutions and best practices from past projects within a domain. Therefore the production of new applications can focus on the points of novel variation and reuse applicable parts of the architecture and implementation which are captured from the past projects.
