لطفا منتظر باشید ...
previous section has been reduced to practice by building SYNTHESIS, a prototype application development environment based on its principles. This section is devoted to a brief description of the SYNTHESIS system. A more detailed description can be found in Dellarocas (1996).The current implementation of SYNTHESIS runs under the Microsoft Windows 3.1 and Windows 95 operating systems. SYNTHESIS itself has been implemented by composing a set of components developed using different environments (Intellicorp's Kappa-PC, Microsoft's Visual Basic, and Shapeware's Visio).SYNTHESIS consists of three elements:
SYNOPSIS, a software architecture description language
An on-line ''design handbook''of dependencies and associated coordination protocols
A design assistant that generates executable applications by successive specializations of their SYNOPSIS description
18.3.1 SYNTHESIS — A Software Architecture Description Language
SYNOPSIS supports graphical descriptions of software application architectures at both the specification and the implementation level. It provides separate language entities for representing software activities and dependencies.SYNOPSIS language elements are connected together through ports. Ports provide a general mechanism for representing abstract component interfaces. All elements of the language can contain an arbitrary number of attributes. Attributes encode additional properties of the element, as well as compatibility criteria that constrain its connection to other elements. For example, figure 18.2 shows the SYNOPSIS description of a simple software system.
Figure 18.2: Representation of a simple file viewer application using SYNOPSIS
SYNOPSIS provides two mechanisms for abstraction: Decomposition allows new entities to be defined as patterns of simpler ones. It enables the naming, storage, and reuse of designs at the architectural level. Specialization allows new entities to be defined as variations of other existing entities. Specialized entities inherit the decomposition and attributes of their parents and can differentiate themselves by modifying any of those elements. Specialization enables the incremental generation of new designs from existing ones, as well as the organization of related designs in concise hierarchies. Finally, it enables the representation of reusable software architectures at various levels of abstraction (from very generic to very specific).Activities Activities represent the main functional pieces of an application. They own a set of ports, through which they interconnect with the rest of the system. Ports usually represent interfaces through which resources are produced and consumed by various activities. Activities are defined as sets of attributes that describe their core function and their capabilities to interconnect with the rest of the system. Two activity attributes are most important:
An (optional) decomposition. Decompositions are patterns of simpler activities and dependencies that implement the functionality intended by the composite activity.
An (optional) component description. Component descriptions associate SYNOPSIS activities with code-level components that implement their intended functionality. Examples of code-level components include source code modules, executable programs, and network servers, among their number.
SYNOPSIS provides a special notation for describing the properties of software components associated with executable activities. Such properties include the component kind, the provided and expected interfaces of the component, the source and object files needed by the component, and so on (figure 18.3).
Figure 18.3: Example of an atomic activity and its associated code-level component description
Depending on the values of the preceding two attributes, activities are distinguished as follows:
Atomic or composite. Atomic activities have no decomposition. Composite activities are associated with a decomposition into patterns of activities and dependencies.
Executable or generic. Executable activities are defined at a level precise enough to allow their translation into executable code. Activities are executable either if they are associated with a component description, or if they are composite and every element in their decomposition is executable. Activities that are not executable are called generic. To generate an executable implementation, all generic activities must be replaced by appropriate executable specializations.
Dependencies Dependencies describe interconnection relationships and constraints among activities. Like activities, dependencies are defined as sets of attributes. The most important attributes are:
Figure 18.4: SYNOPSIS representation of a data flow dependency and its associated pipe transfer coordination protocol
An (optional) decomposition into patterns of simpler dependencies. These collectively specify the same relationship as the composite dependency.
An (optional) coordination protocol. Coordination protocols are patterns of simpler dependencies and activities that describe a mechanism for managing the relationship or constraint implied by the dependency (figure 18.4).
An (optional) association with a software connector. Connectors are low-level mechanisms for interconnecting software components that are directly supported by programming languages and operating systems. Examples include procedure calls, method invocations, and shared memory.
In a manner similar to activities, dependencies are distinguished into atomic or composite, executable or generic.
Specialization Object-oriented languages provide the mechanism of inheritance to facilitate the incremental generation of new objects as specializations of existing ones, and also to help organize and relate similar object classes. SYNOPSIS provides an analogous mechanism called entity specialization. Specialization applies to all the elements of the language, and allows new entities to be created as special cases of existing ones. Specialized entities inherit the decomposition and other attributes of their parents. They can differentiate themselves from their specialization parents by modifying their structure and attributes using the operations described below. Entity specialization is based on the mechanism of process specialization that was first introduced by the Process Handbook project (Dellarocas 1994; Malone et al. 1993).
Figure 18.5: Hierarchy of prerequisite dependencies with increasingly specialized associated coordination protocols
The mechanism of entity specialization enables the creation of specialization hierarchies for activities, dependencies, ports, and coordination protocols. Such hierarchies are analogous to the class hierarchies of object-oriented systems. In specialization hierarchies, generic designs form the roots of specialization trees, consisting of increasingly specialized but related designs. The leafs of specialization trees usually represent design elements that are specific enough to be translated into executable code (figure 18.5).
18.3.2 A Design Handbook of Software Component Interconnection
SYNTHESIS contains our initial version of a handbook of dependencies and coordination protocols commonly encountered in software systems. The prototype handbook is stored on-line as a hierarchy of increasingly specialized SYNOPSIS dependency entities. An entity browser interface (similar to class browsers of object-oriented systems) is available for navigation and selection of handbook entries.
An important decision in making a taxonomy of software interconnection is the choice of the generic dependency types. If we are to treat software interconnection as an orthogonal problem to that of designing the core functional components of an application, dependencies among components should represent relationships that are also orthogonal to the functional domain of an application. Fortunately this requirement is consistent with the nature of most interconnection problems: whether our application is controlling inventory or driving a nuclear submarine, most problems related to connecting its components together are related to a relatively narrow set of concepts, such as resource flows, resource sharing, and timing dependencies. The design of associated coordination protocols involves a similarly narrow set of mechanisms such as shared events, invocation mechanisms, and communication protocols.The prototype handbook is based on the simple assumption that software component interdependencies are explicitly or implicitly related to patterns of resource production and usage. Beginning from this assumption, we have defined a number of useful dependency families in a way independent of the application context where they might be used. Dependency families represented in the handbook include:
Flow dependencies. Flow dependencies represent relationships between producers and consumers of resources. They are specialized according to the kind of resource, the number of producers, the number of consumers, and so on. Coordination protocols for managing flows decompose into protocols, which ensure accessibility of the resource by the consumers (usually by physically transporting it across a communication medium), usability of the resource (usually by performing appropriate data format conversions), as well as synchronization between producers and consumers.
Sharing dependencies. They encode relationships among consumers who use the same resource. Sharing dependencies are specialized according to the sharing properties of the resource in use (divisibility, consumability, concurrency). Coordination protocols for sharing dependencies ensure proper enforcement of the sharing properties, usually by dividing a resource among competing users or by enforcing mutual exclusion protocols.
Timing dependencies. Timing dependencies express constraints on the relative flow of control among a set of activities. Examples include prerequisite dependencies and mutual exclusion dependencies. Timing dependencies are used to specify application-specific cooperation patterns among activities that share the same resources. They are also used in the decomposition of coordination protocols for flow and sharing dependencies.
A detailed description of the contents of the prototype handbook can be found in Dellarocas (1996).
Figure 18.6: Sketch of an algorithm used by SYNTHESIS to generate executable applications by successive specializations of their SYNOPSIS descriptions
18.3.3 Synthesis Design Assistant
The design methodology supported by SYNTHESIS uses SYNOPSIS descriptions in order to both specify and implement software systems. SYNTHESIS supports a process for generating executable systems by successive specialization of their SYNOPSIS descriptions. The process is summarized in figure 18.6. As can be seen, the existence of on-line design handbooks of activities and dependencies can assist, and often automate, parts of the process.
The design process can be customized in a variety of ways. Designers can manually select each new element to be managed, rather than follow the ordering of the to-do list. They can optionally input an evaluation function that helps the system perform an automatic ranking and selection of compatible candidates. Furthermore successive transformations of the original application diagram (stored as composite activities) can optionally be stored as successive specializations in the activity hierarchy. The system can thus keep a design history, which allows designers to easily backtrack to a previous stage of the design and choose a different design path. In that manner exploratory design and maintenance of alternative implementations can be facilitated.
Figure 18.7: Configuration of SYNTHESIS windows during design mode
Figure 18.7 shows the layout of SYNTHESIS windows during design. The SYNOPSIS decomposition editor (in the lower half of the screen) displays the current state of the architectural diagram and updates it automatically whenever a new transformation (replacement of activity or management of dependency) takes place. The entity browser (in the upper left part of the screen) is used for displaying and selecting compatible specializations for application design elements. Finally the design manager window (in the upper right part of the screen) summarizes the status of the design process and allows users to control its parameters.
