An Introduction to Software Architecture - Summary

An Introduction to Software Architecture - Summary

• 1.
  An Introduction toSoftware Architecture - Summary 1. Introduction ● It is increasingly clear that effective software engineering requires facility in architectural software design: ● Common Paradigms ● Get the right architecture ● New systems as evolutions or ● Success of a software system design variations of old systems ● Detailed and deep understand help ● Architectural System Representation decide. ● Analysis and description of the high- ● Get Alternatives level properties of a complex system. ● In Software Architecture there are a lot of activities ○ Module interconnection languages ○ Templates ○ Frameworks ○ Systems that serve the needs of specific ● Good software engineers make common use of architectural principles when designing complex software.
• 2.
  ● Many principleshave emerged informally over time. And others are more carefully documented as industry and scientific standards. ● It is increasingly clear that effective software engineering requires facility in architectural software design. ● Facility: ○ Able to recognize common paradigms so that high-level relationships among systems can be understood, and ■ so that new systems can be built as variations on old systems. ○ Getting the right architecture is often crucial to the success of a software system design (the wrong can lead to disastrous results). ○ Detailed understanding of software architectures allows the engineer to make principled choices among design alternatives. ○ An architectural system representation is often essential to the analysis and description to the high-level properties of a complex system. 2. From Programming Languages to Software Architecture 2.1 High-level Programming Language Low-level Languages (1950): Macro processors:
• 3.
  New Patterns: Method (orprocedure) invocation: Sequence, Conditional and Loop Statements (Corrado Bohm and Giuseppe Jacopini):
• 4.
  2.2 Abstract DataTypes (ADT) 2.3 Software Architecture Just as good programmers recognized useful data structures in the late 1960s, good software system designers now recognize useful system organization. We are still far from having a well-accepted taxonomy of such architectural paradigms, let alone a fully-developed theory of software architecture. But we can now clearly identify a number of architectural patterns, or styles, that currently form the basic repertoire of a software architect. 3. Common Architectural Styles To understand the differences between styles, we must choose a framework from which to view them. An architecture is a collections of computational components. And a description about interactions about them (the connectors).
• 5.
  A connector canbe: ● Procedure call, ● Event broadcast, ● Database queries, and ● pipes. An architectural style, then, define a family of such systems in terms of a pattern of structural organization. An architectural style defines the components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. Questions about a given framework: ● What is the structural pattern -the components, connectors, and components? ● What is the underlying computational model? ● What are the essential invariants of the style? ● What are some common examples of its use? ● What are the advantages and disadvantages of using that style? ● What are some of the common specializations? 3.1 Pipes and Filters
• 6.
  ● The connectorsof this style serve as conduits for the streams, transmitting outputs of one filter to inputs of another. ● The best known examples of pipe and filter architectures are programs written in the Unix shell. ● Examples of pipe style: ○ Signal processing, ○ functional programming, and ○ distributed systems. ○ Compilers ■ Lexical analysis ■ Parsing ■ Semantic analysis ■ Code generation ■ And so on. ● Pipe and filter systems have a number of nice properties. ○ First, they allow the designer to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters. ○ Second, they support reuse: any two filters can be hooked together, provided they agree on the data that is being transmitted between them. ○ Third, systems can be easily maintained and enhanced: new filters can be added to existing systems and old filters can be replaced by improved ones. ○ Fourth, they permit certain kinds of specialized analysis, such as throughout and deadlock analysis. ○ Finally, they naturally support concurrent execution. ● The designer is forced to think of each filter as providing a complete transformation of input data to output data. ○ This is not considered for interactive applications.
• 7.
  3.2 Data Abstractionand Object-Oriented Organization data representations and their associated primitive ● In this style operations are encapsulated in an abstract data type or object. ● The components of this style are the objects -or, if you will, instances of the abstract data types. ● Objects are examples of a sort of component we call a manager because it is responsible for preserving the integrity of a resource (here the representation). ● Objects responsibilities: ○ ...is responsible for preserving the integrity of its representation ○ ...that the representation is hidden from other objects.
• 8.
  ● Variationsabout Object-Oriented: ○ Some systems allow objects to be concurrent tasks, ○ Others allow objects to have multiple interfaces. ● Object-oriented systems have many nice properties, most of which are well known. Because an object hides its representation from its clients, it is possible to change the implementation without affecting those clients. ● Objects allow the designers to decompose problems into collections of interacting agents. ● Object-oriented disadvantages: ○ Interaction between objects NEEDS to know each other. 3.3. Event-based, Implicit Invocation ● Components interact with each other by explicitly invoking those routines. ● Current alternatives: ○ Implicit Invocation ○ Reactive Integration ○ Selective Broadcast ● The idea behind implicit invocation is that instead of invoking a procedure directly, a component can announce (or broadcast) one or more events. ○ Other components in the system can register an interest in an event by associating a procedure with the event. ○ When the event is announced the system itself invokes all of the procedures that have been registered for the event. ○ Thus an event announcement «implicitly» causes the invocation of procedures in other modules. ● The connectors in an implicit invocation system include traditional procedure call as well as bindings between event announcements and procedure calls. ● The main invariant of this style is that announcers of events do not know which components will be affected by those events. ● Most implicit invocation systems also include explicit invocation (i.e., normal procedure call) as a complementary form of interaction. ● Implicit Invocation applications: ○ In programming environments to integrate tools, ○ in database management systems to ensure consistency constraints, ○ in user interfaces to separate presentation of data from applications that manage the data, ○ and by syntax-directed editors to support incremental semantic checking. ● One the most important benefit of II is that it provides strong support for reuse. ○ Any component can be introduced into a system simply by registering it for the events of that system.
• 9.
  ● A second benefit is that implicit invocation eases system evolution. Components may be replaced by other components without affecting the interfaces of other components in the system. ● The primary disadvantage of implicit invocation is that components relinquish control over the computation performed by the system. ○ It does not know when other components listen it up. ○ It does not know the order that events are consumed. 3.4. Layered Systems ● A layered system is organized hierarchically. ● Each layer providing service to the layer above it and serving as a client to layer below. ● In these systems the components implement a virtual machine at some layer in the hierarchy. ● The connectors are defined by the protocols that determine how the layers will interact. ● Topological constraints include limiting interactions to adjacent layers. ● The most widely known examples of this kind of architectural style are layered communication protocols.
• 10.
  ● Other application areas for this style include database systems and operating systems. ● Layered systems have several desirable properties: ○ Support design based on increasing levels of abstraction. ■ This allows implementors to partition a complex problem into a sequence of incremental steps. ● Like pipelines, because each layer interacts with at most the layers below and above, changes to the function of one layer affect at most two other layers. ● Support reuse. ● Disadvantages: ○ Not all systems are easily structured in a layered fashion. ○ And even if a system can logically be structured as layers, considerations of performance may require closer coupling between logically high-level functions may require closer coupling between logically high-level functions and their lower-level implementations. 3.5. Repositories ● In a repository style there are two quite distinct kinds of components: ○ a central data structure represents the current state, and ○ a collection of independent components operate on the central data store. ● The choice of control discipline leads to major subcategories: ○ If the types of transactions in an input stream of transactions trigger selection of processes to execute, the repository can be a traditional database. ○ If the current state of the central data structure is the main trigger of selecting processes to execute, the repository can be a blackboard. ● Figure 4 illustrates a simple view of a blackboard architecture.
• 11.
  ● The Blackboard model is usually presented with three major parts: ○ The Knowledge Sources: separate, independent parcels of application- dependent knowledge. Interaction among knowledge sources takes place solely through the blackboard. ○ The Blackboard data structure: problem-solving state data, organized into an application-dependent hierarchy. Knowledge sources make changes to the blackboard that lead incrementally to a solution to the problem. ○ Control: driven entirely by state of blackboard. Knowledge sources respond opportunistically when changes in the blackboard make them applicable. ● Blackboard systems have traditionally been used for applications requiring complex interpretations of signal processing, such as speech and pattern recognition. ● BB have also appeared in other kinds of systems that involve shared access to data with loosely coupled agents. 3.6. Table Driven Interpreters ● In an interpreter organization a virtual machine is produced in software. ● An interpreter includes the pseudo-program being interpreted and the interpretation engine itself. ● The interpretation engine includes both the definition of the interpreter and the current state of its execution.
• 12.
  ● An interpreter generally has four components: 1. an interpretation engine to do the work, 2. la memory that contains the pseudo-code to be interpreted 3. a representation of the control state of the interpretation engine, and a representation of the current state of the program being simulated. ● Interpreters are commonly used to build virtual machines that close the gap between the computing engine expected by the semantics of the program and the computing engine available in hardware. 3.7 Other Familiar Architectures ● Distributed processes ○ One common form of distributed system architecture is a “client-server” organization. ■ In these systems a server represents a process that provides services to other processes (the clients).
• 13.
  ■ Usually theserver does not know in advance the identities or number of clients that will access it at run time. ■ On the other hand, clients know the identity of a server (or can find it out through some other server) and access it by remote procedure call. ● Main program/subroutine organizations ○ The primary organization of many systems mirrors the programming language in which the system is written. ○ For languages without support for modularization this often results in a system organized around a main program and a set of subroutines. ○ The main program acts as the driver for the subroutines, typically providing a control loop for sequencing through the subroutines in some order.
• 14.
  ● Domain-specific software architectures ○ Recently there has been considerable interest in developing “reference” architectures for specific domains. ○ By specializing the architecture to the domain, it is possible to increase the descriptive power of structures. Indeed, in many cases the architecture is sufficiently constrained that an executable system can be generated automatically or semi-automatically from the architectural description itself. ● State Transition Systems ○ These systems are defined in terms a set of states and a set of named transitions that move a system from one state to another.
• 15.
  ● Process Control Systems ○ These systems are roughly characterized as a feedback loop in which inputs from sensors are used by the process control system to determine a set of outputs that will produce a new state of the environment. 3.8. Heterogeneous Architectures ● While it is important to understand the individual nature of the above architectural styles, most systems typically involve some combination of several styles. ● For example, in a Unix pipeline the individual components may be represented internally using virtually any style -including, of course, another pipe and filter, system. ● What is perhaps more surprising is that connectors, too, can often be hierarchically decomposed. ○ For example, a pipe connector may be implemented internally as a FIFO queue accessed by insert and remove operations. ● A second way for styles to be combined is to permit a single component to use a mixture of architectural connectors. ○ For example, a component might access a repository through part of its interface, but interact through pipes with other components in a system, and accept control information through another part of its interface. ○ In fact, Unix pipe and filter systems do this, the file system playing the role of the repository and initialization switches playing the role of control.) ● Another example is an “active database”. This is a repository which activates external components through implicit invocation. ○ In this organization external components register interest in portions of the database. ○ The database automatically invokes the appropriate tools based on this association. ○ Blackboards are often constructed this way, knowledge sources are associated with specific kinds of data, and are activated whenever that kind of data is modified.) ● A third way for styles to be combined is to completely elaborate one level of architectural description in a completely different architectural style.