Domain-Specific Architectural Design Language Generation

REUSE IS THE REPEATED USE OF A RESOURCE (assets, process, knowledge, etc.). Reuse of a resource is desirable so that development time can be reduced and quality increased. Systematic reuse, though a goal of many, has not yet been achieved in the software world. Two current methods used to capture this knowledge and promote its reuse are architecture description languages (ADLs) and patterns. This report discusses the characterization of architectural elements as reusable assets of an ADL. Our approach is to capture the essence of the domain architecture that defines a family of architecture and use this as the basis for the constructs and semantics of an ADL. We present our approach in this paper through the use of an example from a physical product domain, box construction, and from a logical product domain WWW architecture. Both examples illustrate the capture of design knowledge that can be used to guide production of the associated product.

Architecture-Based Development
An architecture-based approach to reuse understands that the product development domain of systems/products within a defined domain can be based on the design of an architecture for a family of systems (domain architecture). Thus, new system development can proceed by conforming the domain architecture to the requirements of the individual system. This methodology emphasizes the impact of domain architecture on software reuse in the sense that a domain architecture captures commonalities and differences of a domain and makes them available for reuse with expected savings in the development and maintenance of new systems.

Once the domain architecture is defined it makes explicit the reusable aspects of a system and the conditions by which reuse might occur. This applies to physical product development (such as furniture manufacturing) as well as logical product production, (software development). In both cases the most valuable item of reuse is the reuse of domain knowledge.

Our approach to reuse, as stated earlier, is architectural-based and relies on the definition of a set of architectural structural elements and their behavior. These structural and behavioral aspects of an architecture have been defined in our work by the development of an Architectural Description Language1 and its associated semantics. This language provides a set of notations and rules to capture architectural elements. The behavioral aspects of the elements of the language are illustrated by the attributes defined in tables 1, 2, and 3.

Project Overview
This section begins with an example in the physical domain of the construction of boxes. It illustrates how knowledge of box elements and structure can be represented. It illustrates the role of components and connectors in the physical domain. It is presented as a reference for better understanding the role of component and connector within software development (the logical domain).

A graphical view of the major components of our framework is depicted in Fig. 1. Using a system built from this framework, a domain expert can define a set of domain specification rules that dictate the major design guidelines defining functionality, structure, and logical correctness characterizing a valid design in the domain. That is, the specification will consist of a description of major computational elements along with topological rules constraining the use of these elements.

The specification will be facilitated by using a design specification language, denoted as domain language (DL). This domain language allows the domain expert to construct a formal domain definition. Once the domain has been defined, the semantics of the DL will generate a domain specific architectural design language (ADL) or domain specific ADL. The generated ADL reflects the design rules required to describe designs in the current domain. Changes in the domain definition to accommodate a new domain will yield a new ADL in the new domain. The key aspect of our project is to accomplish a domain independent ADL by which the generated DSL will compensate by expanding and refining high level domain rules into low level design specific rules.

The major computational elements of a domain definition will consist of a set of components and connectors along with connection guidelines to bring them together. A metadatabase (MDB) will contain a set of features describing these elements which serve as the basis for the semantics of the language. Design guidelines will be captured by the ADL in the form of rules (syntactic and semantic actions).

Example Using a Physical Domain
We will present an example from the class of physical domains to illustrate the application of the framework. Let us consider the domain of box construction. Boxes can be categorized into types based on the number of sides. To define this domain, one would describe the various types of boxes that the current manufacturing facility can manufacture. The choice of how to categorize the boxes is up to the domain designer. Consider a four-sided classification is a desirable generic type. Common to all products are components, connectors and connections as well as raw-materials needed for fabrication and construction and assembly operations. It is up to the domain designer to adjust the build-in definitions to define the box types needed. The following domain information must be encoded using our Domain Language. The basic elements used in the design of a box are: components (side1, . . . , sideN, top, bottom) necessary for the fabrication of a box made of metal, wood or plastic and connectors (nails, screws, glue, etc.) for fastening or holding the sides together.

The domain designer will compose the structural rules using the Graphical User Interface (GUI) front-end to the language and will also fill in the required profile for all components and connectors. The component profile for this example is shown in Table 1. The framework defines the attributes (name of each column in the table) and their semantics surrounding it. The domain expert must fill in these tables in order to define the current set of components. These attributes are described below.

• Component Name: allows for the specification of the types of components that make up a box. In this case we have classified types left-side, right-side, front-side, back-side, top or bottom.
• Component Material: allows for specification of the types of raw materials needed for fabrication of component types; in this case, wood, plastic, cardboard, metal, etc.
• Available Dimensions: provides a range of available sizes for a component, given in inches.
• Connector Material Suggested: indicates the kind of connector material requisite for connecting this kind of component to other similar components.
• Material Properties: identifies chemical and physical properties of the component based upon the composition of its material. These properties include flammability, ductility, and flexibility with low(l), medium(m), and high(h) ranking levels.

Table 1. Box Components Profile

As part of the domain definition process, a similar profile for connectors must also be defined. The framework defines the attributes (name of each column in the table) and the semantics surrounding it. The domain expert must fill in these tables in order to define the current set of components. These attributes are described below.

• Connector Name: nail, screw, glue, staple.
• Connector Material: metal, chemical compound.
• Available Dimensions: provides a range of available sizes for a connector, given in inches.
• Component Material Suggested: indicates component material for which the connector is best suited.
• Material Properties: chemical and physical properties of the connector due to material composition. These properties may have low(l), medium(m), and high(h) levels of flammability, ductility, and flexibility.
• Connection Properties: indicates the reliabililty and strength of the connection of this connector is with the component material suggested. The ranking levels that each property may have are low(l), medium(m), and high(h) ranking levels.

The domain designer must next define the structural and assembly domain rules for each box type; in this example, we use a four-sided box type. These rules will serve as configuration or topological rules constraining the use of components and connectors previously defined. These rules should define the fundamental structure of the box. Figure 2 is a a summary of these domain rules. This is the point at which the number of sides, bottom, and top (types of components) are specified as well as the method of fabrication.

The collection of the above set of specifications become rules used by our framework to provide a very specific ADL for the designer. This ADL embodies all rules input and uses these to apply checks to future designs of boxes. For example, consider a box design using a side-w component. Its component material is wood. The sizes available for a side-w component range from 10 in. to 40 in. long, 10 in. to 40 in. wide, and 1/32 in. to 1 in. thick. The information in the Connector Material Suggested column from Table 1 indicates that a side-w may be connected with other side-w components using a metal connector or a chemical compound connector. This information is used by the ADL generated to restricts the connectors available to the designer to those defined in Connector Material in Table 2.

Table 2. Box Connector Profile

Each of the sides may be an instance of the components available in Table 1 (side-w, side-m, side-c, side-p). For example, a side-w component complements the domain rules with information such as Component Material, Available Dimensions, Connector Material Suggested, and Component Properties contained in Table 1. The domain rules also indicate the connection rules that dictate the manner in which the borders (b1, b2, b3, b4) of the components will be connected to the borders of other components using a connector (nail, glue, screw, staple). These rules have the general form side.border->side.border (-> denotes a type of connector). For instance, the rule side1.b3->side3.b3 indicates that border b3 of side1 connects to border b3 of side3 by means of a connector (Fig. 3a).

At this point, the domain is well defined and can now be used by product designers to design box structures that conform to the domain rules given in the profile and topology.

Figure 3 shows a box design based on the box domain as defined. Domain rules provide constraints on a specific box design. That is, the connection guidelines and constraints captured by the profile and structural domain rules will be reflected in the specific design of a box. They must be so defined in order to successfully parse the design expressed in our ADL.

We now present an example of an application of our framework to the Software Development domain.

Logical Domain: Software Development
Consider now the world of software domains. Software architecture is necessary to model these domains at a high level of abstraction. The most common architectural elements used in this abstraction of a system are components (major functional and structural elements that capture a desired behavior in a system) and connectors (structural elements that connect the components). These elements have been defined intuitively in practice^2-6 and research.^7-9 We use the same basic framework constructs to provide a domain definition language to capture key architectural elements (components and connectors) along with design rules and design knowledge within a domain.¹⁰

ADL Design and Repository Definition
As with the physical domain, the logical domain relies on the logical domain profile for a description of architectural components and connectors. See Table 3 and Table 4. It is similar in structure to the design rules for components and connectors in our box example. Table 3 defines rules for built-in components (server, client, function) and Table 4 defines rules for built-in connectors (broadcast, socket, rpc). For the sake of illustration we have illustrated the profile for product-type of a WWW architecture. A collection of profiles constitutes the contents of the database (architectural component and connector knowledge) and the conceptual database schema. We again must define the structural rules which define the allowable connections that can form various architectures allowed for the specific type we are defining.

Table 3. Sample Architectural Component Profile

Table 4. Sample Architectural Connector Profile

In the logical domain profile we differentiate between built-in and user-defined components, and between built-in and user-defined connectors. A built-in element has pre-set values for each of its attributes in the profile. A profile for a built-in element is stored in an ADL repository. These built-in component and connector types dictate how the profile can be defined. Figure 3 shows the types we are currently designing. Defining a user-defined element requires modification to the profile definition itself. We forego discussion because of page limitations.

Our built-in profile definition consists of the following attributes:

• Component/Connector Name: name identification for an element (client, server, function, broadcast, socket, rpc).
• Class: components categorized in terms of the functionality provided (computation, memory, etc.); connectors classified by the interconnection furnished (remote procedure calls, message passing, dataflow, etc.).¹¹ Figure 4 summarizes this classification that facilitates the handling of built-in and user-defined elements.
• Data Ports (in[min:max]/out[min:max]): minimum and maximum amount of data input/output ports.
• Control Ports (in[min:max]/out[min:max]): minimum and maximum amount of control input/output ports.
• Data Modification: components characterized by having the potential to modify their data, as opposed to connectors which do not modify data.
• Control Abdication: components and connectors characterized by having the potential to abdicate control.
• Suggested Components/Connectors: verification and validation issues facilitated at the time of composition. Although it can be dynamically inferred, it is shown here to better understand the purpose of a profile.
• Behavioral Properties: behavioral information supportive of structural analysis of the architecture. Information allows architectural matching of elements as described in work by Kazman et al.¹²

This attribute may be redefined to capture other kinds of properties and provide a better understanding of a domain from a particular point of view (i.e., functional, data modeling, etc.).

Once the profiles of components and connectors have been defined, the domain definition must be completed by specifying the particular architecture type. This process will involve specifying for each type, the number and type of components and their connections to each other.

Figure 5 shows one such set of rules for an architectural type called Harvest_arch which is a sub type of the domain of WWW architecture. At this point, the domain has been defined to a point that this information can be used by our system to generate a design environment that will allow designs to be specified and checked for conformance to domain rules. Our framework provides the automation of this generation process. Using the generated design environment, designs can now be created. Figure 6 shows one such design which is valid according to the domain rules specified. All knowledge stored concerning the component type, connections and connectors, and topology used in this design is encoded in the underlying environment and can be used by the design support system to check design and offer suggestions to the designer in an automated manner.

Conclusions, Current, and Future Work
We have presented one method of representing architectural domains with built-in and user-defined architectural elements and associated configuration rules. This representation is used as the basis for the design of an ADL. The ADL itself is constantly evolving and only a small piece of it is discussed here. The domain definition is spread across the profile and the configuration rules. The profile is captured in a database used to store information regarding necessary ADL constructs (components, connectors, design guidelines). These ADL constructs can be utilized to describe an architectural design in the current domain. Effort is being devoted to the refinement of the ADL and associated database. Also, we are currently working in the areas of graphical and textual representation of user-defined components and connectors. A prototype Graphical User Interface (GUI) within a Java environment has been developed as front-end for the ADL. The GUI will facilitate describing a domain in terms of a graphical notation.

References
¹S. A. White and C. Lemus-Olalde. "Domain Specific Architectural Design Language Generator," Institute for Space Systems Operations Annual Report 1995-1996. (1996): 38-40.
²D. Batory, L. Coglianase, M. Goodwin, R. Smith, W. Tracz, K. Bellman, D. Gries, D. McAllester, R. Selby, and R. Taylor. "An Avionics Domain-Specific Software Architecture," Carnegie Mellon Univ., Software Engineering Institute Special Report CMU/SEI-92-SR-9, (1992).
³P. Binns, M. Englehart, M. Jackson, and S. Vestal. "Domain-Specific Software Architecture for Guidance, Navigation and Control," Honeywell Technology Center, Minneapolis MN, Int'l J. of Software Engineering and Knowledge Engineering Jan. 1994, revised Feb. 1995).
⁴M. Englehart and M. Jackson. "ControlH: A Specification Language and Code Generator for Real-Time N&C Applications," Honeywell Technology Center, 1993.
⁵F. Hayes-Roth. "Architecture-Based Acquisition and Development of Software Guidelines and Recommendations from the ARPA Domain Specific Software Architecture (DSSA) Program," Tecknowledge Federal Systems, Version 1.01, 1994.
⁶D. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan, and W. Mann. "Specification and Analysis of System Architecture Using Rapide," IEEE Trans. on Software Engineering 21.4 (April 1995): 336-53.
⁷T. R. Dean and J. R. Cody. "A Syntactic Theory for Software Architecture," IEEE Trans. on Software Engineering 21.4 (April 1995): 302-13.
⁸D. E. Perry and A. L. Wolf. "Foundations for the Study of Software Architecture," ACM SIGSOFT Software Engineering Notes 17.4 (October 1992): 40-52.
⁹M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996.
¹⁰S. A. White. "Software Architecture Design Domain," Proc. of the 2nd Integrated Design and Process Technology Conf. (IDPT '96), Austin, TX, Dec. 1-4, 1996. 1: 283-90.
¹¹M. Shaw and D. Garlan. "Characteristics of Higher-level Languages for Software Architecture," Technical Report CMU-CS-94-210 or CMU/SEI-94-TR-23. Pittsburgh: Carnegie Mellon Univ., Dec. 1994.
¹²R. Kazman, P. C. Clements, G. Abowd, and L. Bass. "Classifying Architectural Elements as Foundation for Mechanism Matching," Proc. of COMPSAC 1997, Washington, D.C., August 1997. (Scheduled for publication.)
¹³S. A. White. "Development of a Language-Based Framework for the Automatic Generation of Domain-Specific Design Languages," Proc. of the ASME Symp. on Computers in Engineering, ASME-ETCE95 Conf., Houston, TX, Jan. 29-Feb 1, 1995. PD 67: 23-32.
¹⁴S. A. White. "A Framework for the Development of Domain Specific Design Support Systems," Proc. of the 1st World Conf. on Integrated Design & Process Technology (IDPT), Austin, TX, Dec. 6-9, 1995. IDPT 1: 37-42.

Publications
Drew, D. and S. A. White. "From Creational Craftsmanship to Engineered Construction," Proc. of Automated Software Engineering Conf., Honolulu, HI, Oct. 1998. (Submitted for publication.)
Lemus, C. and B. Belkouche. "Multiple View Analysis of Designs," Int'l Workshop on Multiple Perspectives in Software Development (ACM Viewpoints '96), joint Proc. of the SIGSOFT '96 Workshops, San Francisco, CA, Oct. 14-15, 1996. 159-61.
White, S. A. "A Design Metalanguage for Design Language Creation," Proc. of ASME and API Energy Information Management-Incorporating ETCE, Houston, TX, Jan. 29-Feb 2, 1996, Computers in Engineering I (1996): 135-44.
White, S. A. "A Framework for the Development of Domain Specific Design Support Systems," Proc. of the First World Conf. on Integrated Design & Process Technology, Austin, TX, Dec. 6-9, 1995. 1: 37-42.
White, S. A. "The Repository Based Software Engineering Program," Proc. of the 1996 Workshop, A NASA Focus on Software Reuse, George Mason Univ., Fairfax, VA, Sept. 24-27, 1996. 53-62.
White, S. A. "Software Architecture Design Domain," Proc. of the 2nd World Conf. on Integrated Design and Process Technology, Austin, Tx, Dec. 1-4, 1996. 1: 283-90.
White, S. A. and C. Lemus. "Architectural Reuse in Software Development," 20th Int'l Computers in Engineering Symp., Jan. 1998. 128: 136; ASME Symp. on Computers in Engineering, Jan. 1998. (Submitted for publication.)
White, S. A. and C. Lemus. "Architecture Reuse through a Domain Specific Language Generator," 8th Ann. Workshop on Software Reuse, Columbus, OH, March 23-26, 1997. White-SA-1, WhiteSA-6.
White, S. A. and C. Lemus. "The Software Architecture Process," Proc. of ASME and API Energy Information Management-Incorporating ETCE, Houston, TX, Jan. 29-Feb 2, 1997. 170-75.
Presentations
Lemus, C. "Software Architecture and Software Design," Conf. at the Int'l Symp. of Computer Systems. Monterrey Institute of Technology, Monterey, Mexico. March 8, 1997.
Lemus C. and B. Belkouche. "Multiple View Analysis of Designs," Int'l Workshop on Multiple Perspectives in Software Development (ACM Viewpoints'96) SIGSOFT'96, San Francisco, CA, Oct. 14-15, 1996.
White, S. A. "A Design Metalanguage for Design Language Creation," ASME & API Energy Information Mgt., Houston, TX, Jan. 29-Feb 2, 1996.
White, S. A. "RBSE and ROSE," A NASA Focus on Software Reuse, George Mason Univ., Fairfax, VA, Sept. 24-27, 1996.
White, S. A. "The Repository Based Software Engineering Program," A NASA Focus on Software Reuse, George Mason Univ., Fairfax, VA, Sept. 24-27, 1996.
White, S. A. "Software Architecture Design Domain," 2nd World Conf. on Integrated Design and Process Technology, Austin, TX, Dec. 1-4, 1996.
White, S. A. and C. Lemus. "Architecture Reuse through a Domain Specific Language Generator," WISR8, 8th Annual Workshop on Software Reuse, Columbus, OH, March 23-26, 1997.
White, S. A. and C. Lemus. "The Software Architecture Process," Proc. of ASME and API Energy Information Management--Incorporating ETCE, Houston TX, Jan. 29-Feb 2, 1997. 170-75.
Funding
"Analysis of Infomation Exchange and Human-Centered Automation in Tools in the Joint NASA/FAA Program for Advanced Air Traffic Transportation Technologies." Co-Investigator: C. McKay. Honeywell, Inc., $20,922.36.
"Automatic graphical interface generation" Faculty Support Award, UHCL, March 15, 1996. $5337.
"A NASA-JSC Architecture Design Language." NASA-JSC Regional Univ. Grant, 1997, $59,917; not-funded.
"Software Architecture Design Languages." Faculty Support Award, UHCL, July 26, 1996. $6,250.
"A Software Architecture Design Reuse and Development Environment," Texas Advanced Research Program, 1997, $102,989; not-funded.

Contents
ISSO -- Institute for Space Systems Operations
1997-1998 Annual Report