Global Journal of Engineering, Design & Technology
Open Access

Software Architecture and its Characteristics

Mutairu Kayode Kolawole^{* *}Correspondence: Mutairu Kayode Kolawole, Department of Computer Engineering, University of Rahjuyan Danesh Borazjan, Bushehr, Iran, Email:

Author info »

Description

Software architecture refers to both the discipline of developing such structures and systems as well as the abstract structure of a software system. Each structure is made up of software elements, connections between those elements, and qualities of both the elements and connections.

Similar to the architecture of a structure, the architecture of a software system is a metaphor. It serves as a system and project development blueprint from which project management can later infer the duties that must be carried out by the teams and individuals involved.

Making basic structural decisions that are difficult to reverse once implemented is the essence of software architecture. Specific structural alternatives from software design options are included in choices for software architecture.

Characteristics

Here are some characteristics of software architecture:

Multitude of stakeholders: Software systems must serve a wide range of stakeholders, including owners, users, and operators of businesses. Each of these stakeholders has unique issues with the system. Designing the system includes balancing these worries and proving that they are addressed. This suggests that architecture is multidisciplinary in nature and includes addressing a wide range of issues and stakeholders.

Separation of concerns: Traditionally, architects have divided the issues that influence the design to reduce complexity. By modeling and explaining the architecture from distinct points of view related to the various stakeholder concerns, architecture documentation demonstrates that all stakeholder concerns are addressed. Architectural views are these distinct descriptions.

Quality-driven: The architecture of a software system is more closely related to its quality attributes, such as fault-tolerance, backward compatibility, extensibility, reliability, maintainability, availability, security, usability, and other similarities. Traditional software design approaches were driven by required functionality and the flow of data through the system.

These quality attributes, also known as non-functional requirements, extra-functional requirements, behavioral requirements, or quality attribute requirements, are frequently influenced by stakeholder concerns.

Recurring styles: The software architecture discipline has created standard methods to address recurring issues, much like the building design field. At different levels of abstraction, these "standard approaches" go by different names. Architectural style technique, reference architecture, and architectural pattern are common names for recurrent solutions.

Conceptual integrity: A concept coined by Fred Brooks in his book The Mythical Man-Month to express the idea that a software system's architecture embodies a broad vision of what it should be able to do and how it should go about doing it. The actualization of this vision should be kept separate. The architect takes on the job of "keeper of the vision," ensuring that system additions are consistent with the architecture and protecting conceptual integrity.

Architecture activities

A software architect is involved in a wide range of tasks. A software architect often collaborates with project managers, talks with stakeholders about requirements that have architectural implications, develops software architecture, assesses designs, and interacts with designers and stakeholders, documents architectural designs, and more.

Architectural analysis is the process of ascertaining the needs for the system and comprehending the environment in which a proposed system will work.

Architectural synthesis or design is the act of developing an architectural work. The design is developed and enhanced in light of the architecturally significant requirements identified by the analysis, the condition of the design at the time, and the outcomes of any evaluation efforts.