Software architecture

A software architecture is one of the types of architecture in the computer science and describes the basic components and their interactions within a software system.

Definition

A definition of Helmut Balzert describes the term as " a structured or hierarchical arrangement of the system components and describe their relations." The architecture components form a decomposition of the overall system, which means that each software element is associated with exactly one component architecture.

Paul Clements describes software architecture as " structures of a software system: software components, the relationships between these and the properties of software components and their relationships."

The software architecture is part of the software design (see SWEBOK ), it arises within which as a rough outline of the components. During software design also refers to local aspects within the architectural framework of the software and therefore can be very detailed, the software architecture is a global property of the overall system.

Classification and delimitation

In the context of software development, the software architecture represents the earliest software design decision ( architectural design ). It is essentially determined by software quality criteria, ie non-functional properties such as modifiability, maintainability, safety or performance (see for example FURPS ). A once established software architecture is later amendable only with great effort. The decision on their design is thus one of the most critical and important points in the development process of a software.

A software architecture is dependent in its economics perspective very different from surrounding aspects. Therefore requires a software architecture in order to function successfully, an appropriate coordination with the other most important factors of the software project. For users and developers of the software project is a well designed software architecture easily have a basic understanding of the system. Important factors that influence the suitability of the software architecture are project planning, risk analysis, organization, development process, procedures, hardware, and quality assurance requirements.

Example

History

Beginnings (1960-1990)

Edsger W. Dijkstra described the ' separation of powers '.

Frederick Brooks lifted ' Conceptual Integrity ' highlighted.

The beginnings of the description and use of an explicit software architecture dates back to the 1960s, when the first large software systems were. The complexity of the systems (eg OS/360 ) made ​​it necessary to divide the implementation tasks to different teams and to define interfaces. The first mention of the term " software architecture " can be found in the proceedings of a funded by the NATO Conference on Software Engineering in 1969. Visitors to this conference were numerous computer science pioneers such as Tony Hoare, Edsger W. Dijkstra, Alan Perlis, Per Brinch Hansen Friedrich L. Bauer, and Niklaus Wirth.

In the 1970s and 1980s, the word "architecture" often in the IT sector in the context of system architectures (ie physical computer system structures ) was used or referred specifically to processor families. Published in 1972 David Parnas an influential article on criteria for Moduldekomposition of software systems. Although he was not used the term " software architecture", but he took some of the later concepts and ideas for software architecture anticipated. 1975, the book The Mythical Man Month by Frederick P. Brooks, were discussed in the key concepts for the design and organization of software systems. More articles by Parnas and Brooks in the 1980s deepened these ideas and concepts.

Establishment (1990-2000)

Software architecture is an independent branch of software engineering only in the 1990s. 1992 published Dewayne Perry and Alexander Wolf a fundamental article entitled Foundations for the Study of Software Architecture. In it they led the formula "Elements form = Rational Software Architecture " one. Many researchers interpreted the "elements" as software components and connectors. Then arose at various universities, a number of Architecture Description Languages ​​(C2, Rapide, Darwin, Wright, ACME, Unicon ), which were hardly used industrially.

As of 1995, the software architecture both in industry and in the academic environment has become increasingly important. The Software Engineering Institute ( SEI) in Pittsburgh published the Software Architecture Analysis Method ( SAAM ). The concept of architectural views reflected in various approaches such as Rational's " 4 1 views" or Siemens " Four views" resist. In 1996 the book Pattern -Oriented Software Architecture, which transferred the concept of design patterns on software architectures. Siemens, Nokia, Philips, Nortel, Lockheed Martin, IBM and other major software companies used software architecture for better reusability of software and designed software product lines. 1999 took place in the U.S., the first international conference ( WICSA 1) instead of specifically focused on software architecture.

Currently (2000 -present)

In 2000, the IEEE 1471:2000 Standard Recommended Practice for Architectural Description of Software - Intensive Systems appeared on the architecture description of software systems. In the same year took over Bill Gates one of the most prominent people in the IT area the title of chief software architect at Microsoft. The SEI worked out the scenario-based architecture evaluation method Architecture Trade -off Analysis Method ( ATAM ), which was applied in the following in numerous industrial projects. The Unified Modeling Language (UML ) is suitable since version 2.0 from 2003 also for documenting software architectures. In 2003, the now most-quoted book on software architecture ( Software Architecture in Practice) and emphasized the importance of quality attributes for the design and evaluation of software architectures.

In Germany with the International Software Architect Qualification Board ( iSAQB ), awarded an association of German IT company since 2003 Certifications for Software Architects. By 2013, the more than 3,000 software architects have been certified according to CPSA -F ( Foundation Level ). In 2004, a working group of the society for computer science founded on software architecture and in 2006 published the Handbook of Software Architecture. Was established in 2006 from the temporary working group a permanent GI specialist group.

Current practice topics such as software architectures for cloud computing, multi-core processors and mobile devices, as well as service -oriented architectures. Current research topics in the field of software architecture are eg knowledge management for software architectures, model-based analysis method, and software product lines.

Description

The description of a software architecture contains information about the structure ( " componentization " ) of a software system, but also information about the communication between components, as well as their mapping to hardware or software resources ( distribution and deployment).

Software architecture descriptions can be used throughout the entire life cycle of a software system. This includes not only the development of particular software evolution, software installation and software operation. Likewise, in addition to technical activities and project management activities such as cost estimation, milestone planning, planning of cross-project software reuse and the organization benefit distributed software development of a good architecture description.

Various textual or graphical notations are used to describe software architectures. The value of pure graphical representations of software architectures is as controversial as the value of purely textual representations. Well-known examples are:

Design

The design of software architecture is the process of creating a rough structure of a software system. Here are functional and non-functional requirements as well as technical and organizational factors as input. The design process usually proceeds iteratively and incrementally. The result of the software architecture design is a software architecture description, which forms the basis for the detailed design.

Software architects follow a number of fundamental design principles. With the principle of targeted abstraction of information they make the complexity of a system under control. The principle of separation of powers (English separation of concerns ) ensures that each component of an architecture is only responsible for a single task. The inner workings of components is encapsulated by interfaces, which goes back to the principle of information hiding ( engl. information hiding ). The system is ideally in a lot of self-contained, loosely coupled components with high cohesion disassembled (the principle of modularity, see also Packaging principles), which makes it easier to understand and customizable. A software architecture is also often constructed hierarchically. The principle of conceptual integrity aims at a consistent application of design decisions.

Software architects use when you design often with proven solutions that are documented as so-called architectural patterns. They offer templates for the basic organization and interaction of software components. Examples of architectural patterns are client-server (for example, the basis for HTTP) or layered architecture (eg the OSI model). Some architectural patterns can be implemented with the help of ready-made infrastructure software. For example, the peer -to-peer architecture patterns can be implemented with a reference library like JXTA.

Quality requirements (eg for performance, maintainability, reliability and security ) are a key factor for the design of a software architecture, as can be realized with functional requirements of unstructured software. It is often the job of software architects to clarify the technical feasibility and the cost of non-functional requirements during architecture design. These usage scenarios can be designed similar system will be investigated and experimental prototypes are created. For the implementation of quality requirements, a set of architectural tactics have been documented, as a heuristic that can guide the design process.

Assessment

The main objectives of the software architecture evaluation is the identification of potential risks, assessing the implementation of quality requirements by the architecture and the identification of opportunities for reuse of software components and other artifacts.

An important quality characteristic of software architectures is their continuity in terms of changes to be solved by software problems. Small changes of the problem should result in only minor changes in the software architecture. The central quality criterion for the work of a software architect from an economic point of view, therefore, is whether he can define a software architecture that has very little or no change with small changes in the problem. In agile software development is called in this context of Design for Change - a software architecture that is open to any changes in the problem. To achieve this, use is made of the emergent designs - a gradually growing software architecture that is flexible exactly where the requirements change often.

For the evaluation of software architectures, there are various methods that differ significantly in terms of goals, use contexts, costs and benefits for part:

  • Informal presentation
  • Filling of pre- questionnaires and checklists
  • Architektursichtungen (English Walkthroughs )
  • Scenario-based methods
  • Simulation of formal architectural models
  • Construction and analysis of prototypes
  • Collection and verification of architectural metrics and ratios
  • Architecture consistency check by means of static code analysis

Considerations in the design and construction of a software architecture

In developing and building a software architecture in a company generally include the following considerations are necessary:

Information security Workflow Encapsulation (object-oriented programming) Fred Brooks ISO/IEC 9126 Coupling (computer programming) Modular programming Hierarchy Client–server model Software metric Reference model Reference architecture Digital Object Identifier Integrated Authority File
75586
de