From Domain Models to Architecture Frameworks 1. ~ .

From Domain Models to Architecture

Frameworks

Jacques Meekel $, Thomas B. Horton t, Robert B. Francet, CharlieMellone L Sajid Dalvi $ $Motorola, 1o.. CorpnmtcSotlwre I&search& Development BOyntOrl Bcwh, FL $Motomla, Inc. IntegratedSoftware Products Boynton Beach, FL l’lkpt, of ComputerScienw sod Engineering FtoridaAtlanticUnivcmity Boca Rston, FL

design-level components in a way that produced a framework that can be used to support product development in this domain. Before describing how this experience has led to these insights about framework developmen~ the paper discusses the project, the domain analysis methods used, and transition from domain models in architecture.

Abstract Thispaper &resses

how domain analysis served to help create reusable architectures and components in the development of a real-time embealied system. The subject domain is portable winders communication devices. The paper discwrses this experience in terms of discovering and developing reusable @neworkr for this domain. Some interesting differences between this approach and what is usually suggested as a process for developing frameworks are described.

As noted earlier, the goal is to produce software architectures and sets of components to allow new products to be brought to market more quickly. Code in these portable wireless communications devices is written in the C language and not C++, due to constraints in the embedded system’s microprocessor power and the software development environment. However, an objectoriented approach to domain analysis was used. The project’s goals include targets to strictly limit any increase in either code size or efficiency in the reusable components produced. This is because considerable cost-savings can be realized when as little memory as possible is used, and because these products must achieve highly optimized realtime performance to be successful.

Keywords: Reuse, domain analysis, frameworks, architecture.

.

1. ~

lvlany companies have looked towards software reuse as a way of reducing product cycle time, allowing industry to deliver new products to market as quickly as possible. Using a domain-specific engineering approach has allowed companies like Hewlett-Packard [1] and Verilog [2] to achieve a 3-to-4X cycle time reduction by building

architectures for a family of products. In this paper we describe a Motorola project with similar goals, addressing the development of a software platform for a family of oneway and two-way pager products.

One interesting result of this entire experience was that an 00 approach to domain engineering turned out to be very useful despite the fact that an 00 implementation would not be carried out. Part of this success might be due to our definition of a component as a large-grain system building block which embodies a unique subset of system features and behaviors. (It is larger than functional procedures or object classes). This definition, adapted from [3], considers a component as a unit of configuration and deployment in the sense that a component should be independently configured, packaged, and distributed for reuse without the consideration of other components. A subsystem is a component which consists of other components. This view allowed the project to adopt an incremental implementation approach. The first phase of this approach focused on the component engineering process, and included a focused domain analysis,

Reporting our experiences in applying domain engineering provides something more than another experience report on using domain analysis to create reusable design architectures and components. We believe that our successes in this experience can provide useful insight to those seeking to create object-oriented frameworks for a particular problem domain, even though our final target language was not object-oriented. The project succeeded in effectively mapping domain model representations to Permleeion to make rJigltal/hard copy of part or all tnts worK lor personal or

claaaroom

usa ia granted without fee providad that

copies are not made or distributed for profit or commercial advantage, tha copyright notice, the title of tha publication and its date ePPear. and notice is 9iven thet copying ie by permission of ACM, Inc. To copy otherwise, to rapubiiah, to post on aarvara, or to redistribute to Iiets, requires prior specific permission and/or a fee. SSR ’97 MA, USA 01997

ACM O-89791 -945 -9/97 JOO05... $3.50

75

architecture, and development of a single subsystem. This subsystem was chosen after a system-level domain analysis identified several well-defined and independent areas of functionality that could be addressed in an incremental fashion.

.

a domain model: a general description of the requirements in terms of entities, operations and relationships;

.

a commonality model, which describes the basic features common to all products and significant variations.

A better understanding of the project’s goals may be gained by characterizing them by a list of perspectives according to Prieto-Diaz [4], as shown in Table 1. The project’s reuse implementation model is planned reuse, i.e., components are developed for reuse considering both current and likely future needs. Our intent is to move away from the traditional “ad-hoc” and “opportunistic” reuse implementations. Our targeted products are a domain model, an architecture, component designs and implementations. Although early reuse efforts have focused in general on source code, greater benefits come from the capability to focus at a higher level and to reuse requirements, architecture, and design. The scope is a single product family, thus our goals is vertical reuse as opposed to horizontal reuse. Techniques of composition,

. Activity & Deliverables

\imb2in9

. Domain Scope

\&

Product history Requirements inventory ~Domain dictionaw

\

. ..”

. .

.

Domain Model .~na,

based on integrating existing components to build an application, are used in deploying the reusable

.

. Commonality model

components.

,.p.

Approach

Reuse Perspectives

Reuse

Im@m@a&on ‘mQde

Planned

I

Tkgeted preduas

\~

Revised domain model

Q . . \~dF~

Domain model, architecture, design, source code

Figure 1. DomainAnalysisProcess

The remainder of this section describes the important aspects of these deliverables that are most relevant-to the transition into design. The OMT (Object Modeling Technique [6]) notation was used to describe the domain model. Object models were developed horn existing documentation of product requirements and reviewed by domain experts. Analysis led to development of subsystem views of the object models, based on requirements-oriented aggregation of functionality. Scenarios played a crucial role in validating these models; these were created and analyzed for a number of existing products and used to describe interactions between the external actors and the devices. In addition, state machines were u&d when it was important to model the behavior of a few dynamic objects.

‘IhbIe 1- ReuseApproach

3. ~

Process W

Prod@

The success of a domain-engineering approach depends on a correct identification of the components required for future product family applications. This identification has been achieved by analyzing and classifying the key common featumxs and their variations across current and future Motorola products in this domain as well as competitor products. This process, adapted from [5] and illustrated in Figure 1, led to a number of domain analysis deliverables, including: . a database of reusable requirements for products in the domain; .

a product history of existing products developed in the past by Motoroltu

.

a domain dictionary;

To analyze commonrdities and variations, we introduced variations to the OMT modeling notations that allowed us to represent variations in operations and attributes. (Some of these variations were simply “typographic” in nature; for example, an optional attribute might be shown in italics.) In addition, higher-tier products in the domain with additional functionality were modeled by adding optional classes that encapsulated these additional features. Finally, to create the commonality model we examined a number of

76

existing products; this usually led to identifying a small set of changes to our early models that were required by that product’s variation in requirements. In this sense, the commonality analysis leads to an additional dimension of our view of the domain models (Figure 2).

4. Moving into Architectuw 4.1 Product Family Architecture The goal of the project was to define an architecture for a family of prcducts, i.e., a high-level partitioning of software into components, the specification of those components and their interactions, and a set of guidelines explaining how these components can be applied to applications within the domain. As Clements [7] and Kruchten [8] point OUL the description of an architecture requires different views. The architecture is described using four different views: .

the Q@ecr Mew provides the logical view of the architecture describing objects and their relationships;

o the i~fg describes how components are organized in a hierarchy of layers, each one providing a well defined interface to the layers above i~

Figure 2. Viewsof domainmodels Analyzing commonalities and variations led to important conclusions regarding both how we understood requirements for products in this domain and how we moved into the design of reusable software components.

.

the H Wnv anrdyzes and describes the concurrency and synchronization aspects of the architecture;

.

the ~ describe interactions between external actors (e.g., the end user) and the system components.

As shown in Figure 4, the development of the architecture was carried out by using and sometimes evolving the descriptions provided by the domain model while taking into account the performance and system constraints.

First, we learned that product requirements in this domain are better classified according to the type of service provided rather than the “traditional” market segmentation that had been defined and used by marketing, and followed by engineering groups. Such services ranged from basic or fundamental services common to all products in the domain to advanced or high-end services provided by fewer products. Figure 3 shows our view of one subsystem in terms of the relative number of basic features compared to features that vary.

ure f

Second, the domain model identified the key components required for future product applications but also provided the framework for the architecture’s logical view and layered view. ‘l%is classification of services and features became the basis for subsystem identification, and a detailed analysis of each subsystem provided a classification of its features and the basis for its logical design.

Figure 4. From Domain Model to Architecture

4.2 Mapping Domain models to Architectural

representations The mapping of the domain model to an architecture

Common Feeturee:

followed the steps defined below.

MO{E

1. Mwt@cation

of the Application

Layer Subsystems

The initial subsystems and components of the archkcture

are identified using the domain model as well as the known OS components. As shown in Figure 5 below, the domain model provides the preliminary identification of the subsystems for the application layer.

Duplication MakeRoom

Figure 3. Common and VariantFeatmesin a Subsystem

77

Domain ModeI

m

Lw-

Application

Lbl.

Architecture Layerad View

File

I

Services Layer

Hardware Abstraction LaWrl

L

I

Figure 7. Layeredview

Servicas

I

I

Hardware abstraction

I

The task view organizes the architecture in independent tasks with a specification of coordination mechanisms used. Taking into account the performance requirements, the taskhig model identifies how the components are implemented in real-time (task or subroutine), how they communicate, and how they synchronize.

Figurs 5. Applicstion layered subsystems

2. Object V&?wDevehpment The Object View (or logical view) of each subsystem

evolved directly from the Object Model developed during the domain analysis. (See Figure 6.) This domain model was modified and extended to include mechanisms and components providing services to a set of components (e.g., the file manager).

Message

Scenarios were used in the architectural stage to both drive the definition of the architecture and verifi it. Some of the scenarios developed for the domain model were reused and extended.

Dirsotory

Box

4.3 Components & Frameworks

Name

Name Store New Msgo DaleteMag

d

5. Scenarios

etQr$d es

o+

Figure 8 below shows how, using what was learned in the domain analysis, a component is organized. The set of common features are features that are provided by all products using the component. Custom features are features that will require to be changed to respond to existing and future variations. At the application layer, these variations are directly related to user feature variations identified during the domain analysis. At the hardware abstraction layer, these variations are mostly related to the range of hardware configurations that need to be supported.

=bp

contains

Mseaege Fits

...

stored as I

I

I

Services Provided

Figure 6. Extending tbe domain model

1

3. Luyered view The architecture layered view consists of three main layers

(Figure 7). The top layer is the application layer, the middle layer is the services layer, and the bottom layer shields the other layers from variations in hardware platforms (microcontrollers, extemal/intemal memory, etc.).

-1.,.,

The layered view is developed using the subsystem.d components identified from the domain model and the object view development.

Figure 8. Componentorganization

78

It is important to notice that the component provides a consistent client API notwithstanding the multiple variations that can be derived, and a predefine set of hooks for customization.

1. domain analysis, i.e., analyzing the common features

and their variations across current and future products in the domain. This entails scoping the domain, gathering the relevant product information, identifying and classifying the features, and analyzing their commonalities.

Although not implemented using an object oriented language, the organization of these components is indeed very similar to the concept of framework as defined by Ttdigent[9] and Lewis [10]. Andert [11] refers to the same organization (custom features are referred as ensembles) by noting - “The best designs encapsulate each piece of

2. architecture, i.e., defining the high-level partitioning of the software into components. This includes identifying the application layer subsystems, extending the object model, defining the layered view and the task view, and developing the scenarios.

knowledge in just one place. Thus, the fundamental invariants are encapsulated in the fkunework, while variable rules and policies are encapsulated in the ensembles.”

3. subsysterdcomponent design, i.e., organizing the design of each subsystem/component using the commonalities and variations identified in the domain analysis. The frameworks we identified and developed approach include:

The difference, as we see it, does not lie in the characteristics of the components, but rather in the process used to develop them. This will be the topic of the next section.

5. ~eworks

. for a 6‘new99 Onulul

As defined by Nelson [13], “A framework helps developers provide solutions for problem domains and better maintain those solutions. It provides a well-designed and thought out infrastructure so that when new pieces are created, they can be substituted with minimal impact on the other pieces in the framework”.

with this

.

domain-specific frameworks such as the Message Manager - these frameworks were derived directly from the domain model,

.

and support-level framework such as the File Manager these frameworks were developed analyzing the services required by the domain-specific frameworks and, in the case of hardware-dependent framework, analyzing the range of hardware platforms to support.

6. Con*

.

Most of the existing literature on frameworks focuses on analyzing what a framework is, how they are organized and their benefits. With respect to the identication and design of frameworks, the literature [9,10,11] appears to suggest an iterative process based on progressively understanding and analyzing the domain, and reworking the solution to cover a broader range of applications. llvo observations can be made. Fkst, this iterative process appears somehow to follow what has been observed in the development of an object-oriented application: a good design might require two or three iterations. Second, although some of this literature on frameworks provide guidelines to analyze the problem domain, we have not yet seen reference to existing publications in the field of domain analysis/engineering [12].

Our application of domain analysis has shown to be usefil not only for creating domain-specific architectures and components, but also for creating fi-ameworks for a particular problem domain.

Although we recognize as Andert [11] points out that “frameworks are hard to develop... They are not created by accident; they require deliberate, concerted effort”, we also believe that domain analysis provides the capability to systematically analyze a problem domain and identify the frameworks while at the same time minimizing the number of iterations.

[1] M. Rix, “Case Study of a Successful Firmware Reuse Program”, HP Software Productivity Conference, August 1992.

and object The fields of domain awhitecturdengineering oriented frameworh represent today two communities without much overlap. Although their focus can be perceived to be different, we believe that both can benefit from each other. Domain analysis techniques can improve the process of discovering frameworks, while the knowledge on object oriented frameworks can be applied for organizing domain specific components even when their implementation is not object oriented.

[2] R. Troy, “Software Re-Use”, Presentation at the ObjectWorld Conference, 1993. [3] W. Kozaczynski, J. Ning, “Component-Baaed Software Engineering”, Panel Introduction, IEEE Fourth International Conference on Sotlware Reuse, April 1996.

Our approach can be summarized as follows:

[4] R. Prieto-Diaz, “Status Report Software Reusability”, IEEE Software, May 1993.

79

[5] G. Arango, “Domain analysis methods” in So@are Reusabilio edited by W. Shafer, R, Prieto-Diaz and M. Matsumoto, Ellis Horwood Ltd., 1994, Chapter 2. [6] J. Rumbaugh & all, Object-Oriented Design, Prentice Hall, 1991.

Modeling

and

[7] P. Clements, “From Domain Models to Architectures”,

USC Center for Engineering Focused Workshop on Software Architectures, June 1994. [8] P. Kruchten, ‘The 4+1 View Model of Architecture”, IEEE Software, NOV 1995. [9] Taligent, “Building Object-Oriented White Paper, Taligent Inc., 1994. [10] T. Lewis,

Object

Oriented

Application

Frameworks”, Frameworks

Manning Publications, 1995. [11] G. Andert, “Object Frameworks in the Taligent OS” IEEE International Conference, 1994. [12] G. Arango, R. Prieto-Diaz, Domain Analysis and Software Systems Modeling, Tutorial, IEEE, 1991.

[13] C. Nelson, “A forum

for fitting

the task”,

IEEE

Computer, March 1994.

80