Chapter One: Introduction to Software Architecture PDF

Chapter One: Introduction to software architecture Introduction  Having a reasonable software architecture is important to the successful development of a software system and  The basic principle of software architecture is every software system is constructed to satisfy an organization’s bus...

Chapter One: Introduction to software architecture Introduction  Having a reasonable software architecture is important to the successful development of a software system and  The basic principle of software architecture is every software system is constructed to satisfy an organization’s business goals,  and that the architecture of a system is a bridge between those (often abstract) business goals and the final (concrete) resulting system.  software architectures can be designed, analyzed, and documented using known techniques that will support the achievement of these business goals. Introduction  The design, analysis, and documentation of architectures is for achievement of the business goals.  It also examine the influences, principally in the form of business goals that lead to quality attribute requirements, that inform these activities. What Software Architecture Is and What It Isn’t “The software architecture of a system is the set of structures needed to reason about the system.These structures comprise software elements , relations among them, and properties of both”  Architecture is about reasoning-enabling structures  Architecture Is a Set of Software Structures  A structure is simply a set of elements held together by a relation What Software Architecture Is and What It Isn’t  Architectural structures can be organized into three useful categories, which will play an important role in the design, documentation, and analysis of architectures: 1. Component-and-connector structures 2. Module structures 3. Allocation structures  Architecture Is an Abstraction  Since architecture consists of structures, and structures consist of elements and relations, it follows that an architecture comprises software elements and how those elements relate to each other.  This means that architecture specifically and intentionally omits certain information about elements that is not useful for reasoning about the system.  Thus an architecture is foremost an abstraction of a system that selects certain details and suppresses others.  In all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts.  Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural  We simply cannot, and do not want to, deal with all of the complexity all of the time  Architecture versus Design  Architecture is design, but not all design is architecture.  That is, many design decisions are left unbound by the architecture  Every Software System Has a Software Architecture  Every system has an architecture, because every system has elements and relations.  However, it does not follow that the architecture is known to anyone.  Perhaps all of the people who designed the system are long gone,  the documentation has vanished (or was never produced),  The source code has been lost (or was never delivered), and all we have at hand is the executing binary code.  This reveals the difference between the architecture of a system and the representation of that architecture.  Given that an architecture can exist independently of its description or specification, this raises the importance of architecture documentation  Not All Architectures Are Good Architectures  An architecture may either support or hinder achieving the important requirements for a system.  we do not accept trial and error as the best way to choose an architecture for a system—that is, not picking an architecture at random, building the system from it,  System and Enterprise Architectures  Two disciplines related to software architecture are: 1. system architecture and 2. enterprise architecture.  Both of these disciplines have broader concerns than software and affect software architecture through the establishment of constraints within which a software system, and its architect, must live  System Architecture  A system’s architecture is a representation of a system in which there is a mapping of functionality onto hardware and software components, a mapping of the software architecture onto the hardware architecture, and a concern for the human interaction with these components.  That is, system architecture is concerned with the totality of hardware, software, and humans.  A system architecture will influence, for example, the functionality that is assigned to different processors and the types of networks that connect those processors.  The software architecture will determine how this functionality is structured and how the software programs residing on the various processors interact.  System Architecture….  A description of the software architecture, as it is mapped to hardware and networking components, allows reasoning about qualities such as performance and reliability.  A description of the system architecture will allow reasoning about additional qualities such as power consumption, weight, and physical dimensions  Enterprise Architecture  Enterprise architecture is a description of the structure and behavior of an organization’s processes, information flow, personnel, and organizational subunits.  These days enterprise architectures for all but the smallest businesses are unthinkable without information system support.  Thus a modern enterprise architecture is concerned with how software systems support the enterprise’s business processes and goals.  Typically included in this set of concerns is a process for deciding which systems with which functionality the enterprise should support.  Enterprise Architecture…  An enterprise architecture will also specify rules for how the enterprise’s systems interact with external systems and the data model of the organization.  Software is only one concern of enterprise architecture.  How the software is used by humans to perform business processes and the standards that determine the computational environment are two other common concerns addressed by enterprise architecture.  Sometimes the software infrastructure that supports communication among systems and with the external world is considered a portion of the enterprise architecture; at other times, this infrastructure is considered one of the systems within an enterprise.  In either case, the architecture of that infrastructure is a software architecture!)  Architectural Structures and Views  Structures have counterparts in nature.  For example, the neurologist, the orthopedist, the hematologist, and the dermatologist all have different views of the various structures of a human body  Although these views are pictured differently and have very different properties, all are inherently related and interconnected: Together they describe the architecture of the human body Architectural Structures and Views  Architectural Structures and Views…  Architectural structures also have counterparts in human endeavors.  For example, electricians, plumbers, heating and air conditioning specialists, roofers, and framers are each concerned with different structures in a building.  You can readily see the qualities that are the focus of each of these structures. So it is with software.  Three Kinds of Structures  Architectural structures can be divided into three major categories, depending on the broad nature of the elements they show and the kinds of reasoning they support 1. Component-and-connector (C&C) structures  focus on the way the elements interact with each other at runtime to carry out the system’s functions.  They describe how the system is structured as a set of elements that have runtime behavior (components) and interactions (connectors).  Components are the principal units of computation and could be services, peers, clients, servers, filters, or many other types of runtime element.  Three Kinds of Structures….  Connectors are the communication vehicles among components, such as call-return, process synchronization operators, pipes, or others.  C&C structures help answer questions such as the following:  What are the major executing components and how do they interact at runtime?  What are the major shared data stores?  How does data progress through the system?  Which parts of the system can run in parallel?  Can the system’s structure change as it executes and, if so, how?  By extension, these structures are crucially important for asking questions about the system’s runtime properties, such as performance, security, availability, and more  Three Kinds of Structures... Figure 1.2: shows a sketch of a C&C structure of a system using an informal notation that is explained in the figure’s key. The system contains a shared repository that is accessed by servers and an administrative component. A set of client tellers can interact with the account servers and communicate among themselves using a publish-subscribe connector. Figure 1.2  Three Kinds of Structures…. 2. Module structures  partition systems into implementation units, which we call modules.  Module structures show how a system is structured as a set of code or data units that have to be constructed or procured.  Modules are assigned specific computational responsibilities and are the basis of work assignments for programming teams.  In any module structure, the elements are modules of some kind (perhaps classes, packages, layers, or merely divisions of functionality, all of which are units of implementation).  Modules are assigned areas of functional responsibility.  Module implementations include packages, classes, and layers.  Relations among modules in a module structure include uses, generalization (or “is-a”), and “is part of.”  Figures 1.3 and 1.4 show examples of module elements and relations, respectively, using the Unified Modeling Language (UML) notation  Three Kinds of Structures... Figure 1.3 Module elements in UML Three Kinds of Structures….. Figure 1.4 Module relations in UML Three Kinds of Structures…  Module structures allow us to answer questions such as the following:  What is the primary functional responsibility assigned to each module?  What other software elements is a module allowed to use?  What other software does it actually use and depend on?  What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships?.  Three Kinds of Structures… 3. Allocation structures  establish the mapping from software structures to the system’s non software structures, such as its organization, or its development, test, and execution environments.  Allocation structures answer questions such as the following:  Which processor(s) does each software element execute on?  In which directories or files is each element stored during development, testing, and system building?  What is the assignment of each software element to development teams?