Concept: Software Architecture

Concept: Software Architecture

The software architecture represents the structure or structures of the system, made up of software components, properties visible from the outside, and the relationships between them.

The main description of the contract

Introduction

Software architecture is an easy concept to understand and intuitively appreciated by most engineers, especially those with little experience, but it is not easy to define precisely. In particular, it is not easy to draw a precise line between design and architecture. Although, Architecture is an aspect of the invention that focuses on certain specific characteristics.

An Introduction to Software Architecture, David Garlan and Mary Shaw suggests that architecture is a level of design that focuses on aspects: “Beyond algorithms and data structures of computing; designing and specifying the general format of the system appears to be a new type of problem. Structural issues include public organization and the overall control structure; communication, synchronization, and data access protocols; assigning functionality to design elements; physical disposition.

Concept: Software Architecture

The composition of the design elements; scale and performance; and the selection between design alternatives.” (Beyond procedures and computational data structures, the design and specification of the general form of the system emerge as a new class of problems. Structural aspects include available structure control and public organization; data communication, synchronization, access protocols; assignment of functions to design elements; physical layout, composition of design elements; fit and performance; and selection, among other design alternatives). [GAR93]

But architecture is extra than a structure; the IEEE Architecture Working Group defines it as “the highest level concept of a system in its environment” [IEP1471]. It is also about “adapting” to the system’s integrity, financial constraints, aesthetic concerns, and style. It is not limited to an internal approach but considers the entire system within the user environment and the development environment, an external process.

In RUP, the architecture of a software system (at some point) is the organization or structure of important system components that interact through interfaces, with members made up of smaller and smaller interfaces and functionalities.

Architectural Description

To speak and reason about software architecture. It is first necessary to define an architectural representation to describe the important aspects of architecture. In RUP, this description remains captured in the software architecture document.

We decided to represent the architecture of the software in different views of the architecture. Each architecture view addresses a specific set of issues specific to stakeholders in the development process: users, designers, managers, system engineers, maintainers, etc.

The views capture major structural design decisions and show how the software structure remains divided into components and connectors connect members to produce useful shapes [PW92]. These design options should remain tied to Requirements, functional and additional, and other restrictions. Although, in turn, they add more stress to the requirements and design decisions coming down to a lower level.

A Typical Set of Architectural Sites.

The architecture remains still represented through several different architectural views, mainly extracting the “architecturally significant” elements. In RUP, you start with a typical set of beliefs, called a “4 + 1 view pattern” [KRU95]. Consists of:

The Use Cases view contains usage cases and scenarios covering architecturally significant behavioral, class, or technical risks. It is a subset of the use case model.

The logical view contains the most important design classes and their organization into packages and subsystems and the organization of these packages and subsystems into layers. It also includes some use case implementations. But,  It is a subset of the design pattern.

Likewise, The Deployment View, which contains an overview of the deployment model. Also,  And its organization in terms of modules in packages and layers. It also describes the mapping of packages and classes (from the logical view) to packages and modules from the implementation view. But,  It is a subset of the deployment model.

Similarly, The process view, which contains the description of the tasks (processes and threads) involved. Also, Their interactions and configurations, and the assignment of classes and design object to functions. Also,  This view should only be used if the system has a significant degree of concurrency. In RUP, this is a subset of the design model.

The deployment view, which contains the description of the different physical nodes. For the most common platform configurations and tasks (from process view) to physical nodes. This view should only be used if the system remains distributed. It is a subset of the deployment model.

Architecture views remain displayed in the software architecture document. Software to manage customers is software that automates and manages the customer life cycle of an organization. You can display additional images to express different special concerns: UI view, Security view, Data view, etc. In simple systems, you can omit some of the opinions contained in the 4 + 1 view template.

Attention in Architecture

Although the views above can represent the complete design of a system, the architecture only addresses a few specifics:

The structure of the model: organizational diagrams, for example, the creation of layers.

Although, The essentials: critical use cases. But, Main classes, common mechanisms, etc., against all the elements present in the model.

Some key Scenarios show the Main Control Flows of the System.

The services capture aspects of the product line, modularity, and optional features.

Architectural views are essentially abstractions or simplifications of the whole design, in which important elements are made more visible and details remain omitted. These characteristics are important for reasoning about:

• The evolution of the system, the transition to the next development cycle.
• The reuse of architecture, or parts of it, in the context of a product line.
• Assessment of complementary qualities. Such as performance, availability, portability, and security.
• Assign development work to teams and subcontractors.
• Decisions on the inclusion of affordable components.
• Insertion into a larger system.

Architecture Models

Architectural motifs are ready-made formats that solve recurring architectural problems. An architectural infrastructure (middleware) is a set of components on which a certain type of architecture can remain built. Many of the main architectural difficulties must be solved in the infrastructure, usually dedicated to a specific domain: command and control, MIS, control system, etc.