Software Architecture By Nick V. Scherbakov Technical University of

Software Architecture By Nick V. Scherbakov Technical University of St. Petersburg

What is Software Architecture? A set of significant decisions about the organization of a software system, The selection of the structural elements and their interfaces by which the system is composed, The behavior of the structural elements as specified in the collaborations among those elements, Composition of these structural and behavioral elements into progressively larger subsystems, The architectural style that guides this organization (i.e. these elements and their interfaces, their collaborations, and their composition).

Note on the Definition In the definition above, we assume that components can make up a component. The intent of this definition is that a software architecture must abstract away some information from the system (otherwise there is no point looking at the architecture, we are simply viewing the entire system) and yet provide enough information to be a basis for analysis, decision making, and hence risk reduction. First, architecture defines components. The architecture embodies information about how the components interact with each other. This means that architecture specifically omits content information about components that does not pertain to their interaction.

Note on the Definition (Cont’d) Second, the definition makes clear that systems can comprise more than one structure, and that no one structure holds the irrefutable claim to being the architecture. By intention, the definition does not specify what architectural components and relationships are. Is a software component an object? A process? A library? A database? A commercial product? It can be any of these things and more. Third, the definition implies that every software system has an architecture, because every system can be shown to be composed of components and relations among them.

Note on the Definition (Cont’d) Fourth, the behavior of each component is part of the architecture, insofar as that behavior can be observed or discerned from the point of view of another component. This behavior is what allows components to interact with each other, which is clearly part of the architecture. Hence, most of the box-and-line drawings that are passed off as architectures are in fact not architectures at all. They are simply box-andline drawing

System Quality Attributes The architecture essentially defines "externally visible" properties also known as system quality attributes for the whole software project, we are referring to such properties as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Evaluation of an architecture's properties is critical to successful system development. However, reasoning about a system's intended architecture must be recognized as distinct from reasoning about its realized architecture. As design and eventually implementation of an architecture proceed, faithfulness to the principles of the intended architecture is not always easy to achieve.

Run-Time Quality Attributes Performance refers to the responsiveness of the system, the 'time’ required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes a transaction with the system to complete. Since communication usually takes longer than computation, performance is often a function of how much communication and interaction there is between the components of the systemclearly an architectural issue. Security is a measure of the system's ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. It is categorized in terms of the types of threats that might be made to system;

Run-Time Quality Attributes (Cont’d) Availability measures the proportion of time the system is up and running. It is measured by the length of time between failures as well as by how quickly the system is able to resume operation in the event of failure. The steady state availability of a system is the proportion of time that the system is functioning correctly and is typically seen as follows: time to failure/(time to failure time to repair) Availability comes from both "time to failure" and "time to repair"; both are addressed through architectural means.

Run-Time Quality Attributes (Cont’d) Reliability is closely related to availability, the ability of the system to keep operating over time. Reliability is usually measured with "time to failure". This is a quality attribute that is tied to the architecture: Careful attention to error reporting and handling (which involves constraining the interaction patterns among the components), and special kinds of components such as time-out monitors. Mean time to failure is lengthened primarily by making an architecture fault tolerant. Fault tolerance, in turn, is achieved by the replication of critical processing elements and connections within the architecture. Mean time to failure can also be lengthened by gelding a less error-prone system, which is addressed architecturally by careful separation of concerns, which leads to better inerrability and testability.

Run-Time Quality Attributes (Cont’d) Functionality is the ability of the system to do the work for which it was intended. Performing a task requires that many or most of the system's components work in a coordinated manner to complete the job, just as framers, electricians, plumbers, drywall hangers, painters, and finish carpenters all come together to cooperatively perform the task of getting a house built. Therefore, if the components have not been assigned the correct responsibilities or have not been endowed with the correct facilities for coordinating with other components (so that, for instance, they know when it is time for them to begin their portion of the task), the system will be unable to perform the required functionality.

Run-Time Quality Attributes (Cont’d) Usability can be broken down into the following areas: Learnability: How quick and easy is it for a user to learn to use the system's interface? Efficiency: Does the system respond with appropriate speed to a user's requests? Memorability: Can the user remember how to do system operations between uses of the system? Error avoidance: Does the system anticipate and prevent common user errors? Error handling: Does the system help the user recover from errors? Satisfaction: Does the system make the user's job easy?

Engineering Quality Attributes Modifiability, in all its forms, may be the quality attribute most closely aligned to the architecture of a system. The ability to make changes quickly and cost effectively follows directly from the architecture: Modifiability is largely a function of the locality of any change. Making a widespread change to the system is more costly than making a change to a single component, all other things being equal. There are exceptions, of course. A single component, if excessively large and complex, may be more costly to change than five simple ones. It's also easy to imagine a global change that in each place is simple and systematic: changing the value of a constant that appears everywhere, for instance.

Engineering Quality Attributes (Cont’d) Modifiability (cont’d) However, in large systems, making a change is much more costly than just, well, making the change. Development process costs start to dominate, such as maintaining version control, approving the change across many change control boards, coordinating the change time across many large teams, retesting all the units, perhaps assuring backward compatibility, and so forth. We take as a general principle that local is better. Since the architecture defines the components and the responsibilities of each, it also defines the circumstances under which each component will have to change. An architecture effectively classifies all possible changes into four categories

The Four Categories of Change Extending or changing capabilities. Adding new functionality, enhancing existing functionality, or repairing bugs. The ability to acquire new features is called extensibility. Adding new capabilities is important to remain competitive against other products in the same market. Deleting unwanted capabilities. To streamline or simplify the functionality of an existing application, perhaps to deliver a less-capable (and therefore less expensive) version of a product to a wider customer base. Adapting to new operating environments. For example, processor hardware, input/output devices, and logical devices. This kind of modification occurs so often that the quality of being amenable to it has a special name, portability, which we will discuss separately. Portability makes a product more flexible in how it can be fielded, appealing to a broader customer base. Restructuring. For example, rationalizing system services, modularising, . optimising, or creating reusable components that may serve to give the organization a head start on future systems.

Engineering Quality Attributes (Cont’d) Portability is the ability of the system to run under different computing environments. These environments can be hardware, software, or a combination of the two. A system is portable to the extent that all of the assumptions about any particular computing environment are confined to one component (or at worst, a small number of easily changed components). The encapsulation of platform-specific considerations in an architecture typically takes the form of a portability layer, a set of software services that gives application software an abstract interface to its environment. This interface remains constant (thus insulating the application software from change) even though the implementation of that layer changes as the system is ported from environment to environment.

Engineering Quality Attributes (Cont’d) Reusability is usually taken to mean designing a system so that the system's structure or some of its components can be reused again in future applications. Designing for reusability means that the system has been structured so that its components can be chosen from previously built products, in which case it is a synonym for integrability . In either case, reusability can be conceived of as another special case of modifiability.

Engineering Quality Attributes (Cont’d) Integrability is the ability to make the separately developed components of the system work correctly together. This in turn depends on the external complexity of the components, their interaction mechanisms and protocols, and the degree to which responsibilities have been cleanly partitioned, all architecture-level issues. Inerrability also depends upon how well and completely the interfaces to the components have been specified. Integrating a component depends not only on the interaction mechanisms used (e.g., procedure call versus process spawning) but also on the functionality assigned to the component to be integrated and how that functionality is related to the functionality of this new component's environment.

Engineering Quality Attributes (Cont’d) Interoperability is a special kind of integrability. lntegrability measures the ability of parts of a system to work together; interoperability measures the ability of a group of parts (constituting a system) to work with another system.

Engineering Quality Attributes (Cont’d) Software testability refers to the ease with which software can be made to demonstrate its faults through (typically execution-based) testing. In particular, testability refers to the probability that, assuming that the software does have at least one fault, the software will fail on its next test execution. Testability is related to the concepts of absorbability and coagulability. For a system to be properly testable, it must be possible to control each component's internal state and inputs and then to observe its outputs. A system's testability relates to several structural or architectural issues: its level of architectural documentation, its separation of concerns, and the degree to which the system uses information hiding. Incremental development also benefits testability in the same way it enhances interoperability.

Business Quality Attributes In addition to the preceding qualities that apply directly to a system, there are a number of business quality goals that frequently shape a system's architecture. We (briefly) distinguish two kinds of business goals. The first concerns cost and schedule considerations; The other business goal deals with market and marketing considerations;

Business Quality Attributes (Cont’d) Time to market. If there is competitive pressure or if there is a short window of opportunity for a system or product, development time becomes important. This in turn leads to pressure to buy or otherwise reuse existing components. Time to market is often reduced by using prebuilt components such as commercial off-the-shelf (COTS) products or components reused from previous projects. The ability to insert a component into a system depends on the decomposition of the system into components, one or more of which are prebuilt.

Business Quality Attributes (Cont’d) Cost. The development effort will naturally have a budget that must not be exceeded. Different architectures will yield different development costs; for instance, an architecture that relies on technology (or expertise with a technology) that is not resident within the developing organization will be more expensive to realize than one that takes advantage of assets already inhouse.

Business Quality Attributes (Cont’d) Projected lifetime of the system. lf the system is intended to have a long lifetime, modifiability and portability across different platforms become important. But building in the additional infrastructure (such as a portability layer) to support modifiability and portability will usually compromise time to market. On the other hand, a modifiable, extensible product is more likely to survive longer in the marketplace, extending its lifetime.

Business Quality Attributes (Cont’d) Targeted market. For general-purpose (mass- market) software, the platforms on which a system runs as well as its feature set will determine the size of the potential market. Thus, portability and functionality are key to market share. Other qualities such as performance, reliability, and usability also play a role. For a large but specific market, a product-line approach should be considered, in which a core of the system is common (frequently including provisions for portability) and around which layers of software of increasing specificity are constructed.

Business Quality Attributes (Cont’d) Rollout schedule. lf a product is to be introduced as base functionality with many options, flexibility and customizability are important. Particularly, the system must be constructed with ease of expansion and contraction in mind.

Business Quality Attributes (Cont’d) Extensive use of legacy systems. If the new system must integrate with existing systems, care must be taken to define appropriate integration mechanisms. This is a property that is clearly of marketing importance but which has substantial architectural implications. For example, the ability to integrate a legacy system with an HTTP server to make it accessible from the World Wide Web is currently a marketing goal in many corporations. The architectural constraints implied by this integration must be analyzed.