Lecture
A software architecture is a structure of a program or a computing system that includes software components, the properties of these components visible from the outside, and the relationship between them . This term also refers to the documentation of the software architecture . Documenting the software architecture simplifies the process of communication between stakeholders, allows you to record decisions made at the early design stages of a high-level system design and allows you to reuse components of this design and templates in other projects.
Overview
Since its inception, the field of computer science has faced problems related to the complexity of software systems. Previously, problems of complexity were solved by developers by the correct choice of data structures, the development of algorithms and the application of the concept of delimitation of powers. Although the term “software architecture” is relatively new to the software development industry, the fundamental principles of this field have been misaligned by software development pioneers since the mid-1980s. The first attempts to realize and explain the software architecture of the system were full of inaccuracies and suffered from a lack of organization, often it was just a diagram of blocks connected by lines. In the 1990s, there was an attempt to identify and systematize the main aspects of this discipline. The initial set of design patterns, design styles, best practices, description languages, and formal logic were developed during this time.
The underlying idea of the discipline of software architecture is the idea of reducing the complexity of the system through abstraction and separation of powers. To date, there is still no agreement on a clear definition of the term “software architecture”.
Being at the moment of its development a discipline without clear rules on the “right” way of creating a system, software architecture design is still a mixture of science and art. The “art” aspect is that any commercial system implies an application or mission. What key objectives the system has is described by scripts as non-functional system requirements, also known as quality attributes, defining how the system behaves. System quality attributes include fault tolerance, backward compatibility, extensibility, reliability, maintainability, availability, security, usability, and other qualities. From the user's point of view of the software architecture, the software architecture provides direction for the movement and solution of problems related to the specialty of each such user, for example, an interested person, software developer, software support team, software maintenance specialist, software deployment specialist, tester, and end users. In this sense, the software architecture actually brings together different points of view on the system. The fact that these several different points of view can be combined in a software architecture is an argument in defense of the need and feasibility of creating a software architecture even before the software development phase.
The beginning of software architecture as a concept was laid in the research work of Edsger Dijkstra in 1968 and David Parnas in the early 1970s. These scientists emphasized that the structure of the software system is important, and that building the right structure is critical. The popularity of studying this area has increased since the early 1990s, along with research on the study of architectural styles (templates), architecture description languages, architecture documentation, and formal methods.
Research and development institutions play an important role in the development of software architecture as a discipline. Mary Shaw and David Garlan from Carnegie Mellon University wrote a book called Software Architecture: Perspectives on a New Discipline in 1996, in which they introduced software architecture concepts such as components, connectors, styles, and so on. At the University of California, the Irvine Institute for Software Research primarily examines architectural styles, architecture description languages, and dynamic architectures.
The first standard of the software architecture is the IEEE 1471 standard: ANSI / IEEE 1471-2000: Recommendations for the description of predominantly software systems. It was adopted in 2007 under the name ISO ISO / IEC 42010: 2007.
Architecture Description Languages (ADLS) are used to describe software architecture. Various organizations developed several different ADLS, including AADL (SAE standard), Wright (developed at Carnegie Mellon University), Acme (developed at Carnegie Mellon University), xADL (developed at UCI), Darwin (developed at Imperial College in London ), DAOP-ADL (developed at the University of Málaga), and ByADL (University of L'Aquila, Italy). Common elements for all these languages are the concepts of component, connector, and configuration.
The software architecture typically contains several types that are similar to various types of drawings in building construction. In the ontology established by ANSI / IEEE 1471-2000, views are instances of a point of view, where a point of view exists to describe an architecture from the point of view of a given set of interested parties.
Examples of types:
Although several languages have been developed to describe software architecture, there is currently no agreement on which set of types should be adopted as a reference. As a standard for “modeling software systems (and not only),” UML was created.
The following frameworks exist in the field of software architecture:
Examples of architectures such as the Zachman Framework, DODAF, and TOGAF are in the area of enterprise architectures.
Software architecture is the implementation of non-functional system requirements, while software design is the implementation of functional requirements [ source not specified 149 days ] .
Software architecture, which can also be thought of as strategy development, is an activity associated with defining global constraints imposed on system design, such as choosing a programming paradigm, architectural styles, software development standards based on the use of components, design principles and limitations, imposed by state law. Detailed design, that is, the development of tactics is an activity associated with the definition of local design constraints, such as design patterns, architectural models, programming and refactoring idioms. According to the stress / neighborhood hypothesis (Intension / Locality Hyphotysis), the difference between architectural and detailed design is determined by the Locality Criteria criterion, according to which the statement that software design is not local (but architectural) is true if and only if a program that meets this criterion can be expanded into a program that does not satisfy it. For example, the client-server application style is an architectural style (strategic design), because a program that is built on this principle can be expanded into a program that is not a client-server, for example, by adding peer-to-peer nodes.
Architecture is a design (design), but not every design is an architectural design. In practice, the architect defines the distinction between software architecture (architectural design) and detailed design (non-architectural design). There are no rules or instructions on how to do this that are suitable for any occasion.
There are many common ways to develop software modules and their relationships, including:
Comments
To leave a comment
Software and information systems development
Terms: Software and information systems development