Using ontology to support development of software architectures.

INTRODUCTION

The IEEE Recommended Practices for Architectural Description of Software-Intensive Systems (IEEE-1471) (1) provides a conceptual framework for documenting software architectures, in which the documentation is organized as a set of architecture views. Each view addresses one or more of the concerns of stakeholders, the parties involved in the development project, such as executives, software developers, and software architects. Traditional view-based approaches, such as the Reference Model for Open Distributed Processing (RM-ODP), (2) the 4+1 View Model, (3) and IBM's Rational * Unified Process * (4) generally adhere to this standard. For example, RM-ODP organizes the architectural description into Enterprise, Information, Computational, Engineering, and Technology views.

In contrast, in Architecture Decisions: Demystifying Architecture, (5) we argue that architecture decisions are the primary representation of architecture.

Rather than starting with view construction, we first document explicit architecture decisions and then complement those with views. In this paper we extend our previous work and submit that software architecture should foundationally be captured and maintained as an instance of an architectural ontology. A similar approach has been used at the University of California at Irvine. (6)

By definition, ontology is an explicit formal specification of the concepts (also referred to as classes) in a domain and the relations among them. (7) Classes contain properties (also known as slots), which describe various features and attributes of the class. (8) Ontologies are used in various application domains to facilitate a common understanding of the information structures in a domain and to enable reuse of domain knowledge. We view ontology as a powerful mechanism that can play a similar role in the world of software architecture.

An architectural ontology provides a common vocabulary that enables the level of precision needed for making effective architecture decisions. Our proposed ontology is composed of four segments: (1) architecture assets, such as subsystems, components and interfaces, (2) architecture decisions, (3) stakeholder concerns, and (4) an architecture roadmap that describes which aspects of the architecture should be developed and when they should be tackled. The work we present here offers the following benefits beyond our original approach:

* The approach ensures the architect is focused on what is important. Just as viewpoints, or templates for views, provide guidelines for architectural descriptions, architecture-related decision making needs appropriate guidelines to focus attention on those assets that are important to the organization.

* The ontology-based approach provides a common vocabulary to enhance precision and clarity. One benefit of architecture-modeling approaches is the added degree of precision they provide. Similarly, an architectural vocabulary provides a higher level of precision for decision making.

* Tools that provide repository support are available. In large projects we make hundreds of decisions, which need documenting. Also required is support for navigation and reuse. From the various tools available we have chosen Protege, an open-source ontology development tool.

* The approach supports impact analysis. Architecture decisions change due to changes in business needs, product experience in the field, changes in schedules, and so on. The approach and the supporting tools enable us to perform what-if analyses, which lead to improved architecture decisions.

* The approach supports on-demand view creation. It has proven difficult to predetermine which views to construct before the architecture is documented. This approach gives us the ability to create views on demand from a structured repository.

* The approach supports the temporal mapping of the development of the architecture. Stakeholders often require a time-based view of the evolution of the architecture over a number of releases, which we provide through an architecture roadmap.

The rest of this paper is organized as follows. In the next section we describe our ontology-based approach to architecture development. In the section that follows we illustrate our approach through a case study that involves a credit-approval system and the use of Protege, an open-source ontology development tool. We then discuss the results of our case study and the lessons learned, after which we describe related research and position our work in its context. We conclude with a summary and ideas for future work.

OUR APPROACH

Our approach is built on an ontology that connects stakeholder concerns, architecture decisions, architecture assets, and an implementation roadmap. The concerns of the various stakeholders (strategic business needs, business risks, specific functional requirements, etc.) drive architecture entities and are captured as a set of key decisions. The decisions can be viewed as making changes to the various assets in the information technology (IT) environment, such as systems, interfaces, nodes, and components. For example, a decision may call for decommissioning of an existing system or for the development of a new interface. These changes are carried out based on a technology transformation roadmap.

A high-level view of this ontology is shown in Figure 1; in this paper, we use the UML ** (Unified Modeling Language **) notation in the diagrams representing ontology structures. The class Concern has the slot addressed by, whose value is class Architecture Decision; class Architecture Decision in turn has slots transforms and implemented by, whose values are classes Architecture Asset and Roadmap.

[FIGURE 1 OMITTED]

We develop this ontology in five steps: (1) capturing stakeholder concerns, (2) analyzing the current architecture, (3) defining the target architecture, (4) conducting a gap analysis and producing the roadmap, and (5) validating the architecture. These are the same steps we described in An Architecture Process for System Evolution, (9) and the process is similar to the one used by other methodologies such as The Open Group Architecture Framework (TOGAF **). (10)

In the next section we illustrate our approach through a case study in which we capture the ontology using Protege, an open-source ontology development tool from Stanford University. (11) Protege provides a graphical user interface for modeling classes, properties, and relations. Protege generates interactive forms for domain experts to enter ontology data, which is then validated by the tool. The tool comes with a large collection of plug-ins that query and visualize ontology data. Models (classes and instances) are loaded and saved in various formats, including XML (Extensible Markup Language) and RDF (Resource Description Framework). Protege models may be stored in any database supporting JDBC ** (Java Database Connectivity).

CASE STUDY

In Architecture Decisions: Demystifying Architecture, (5) a case study introduced a complex real-time credit-approval process in a predominately batch environment. We make use of the same scenario here and present a case study in which our ontology-based approach to architectural development is illustrated. In the section "Discussion," we describe the way in which our previous results have been further improved.

The management of a fictional large financial organization (the company) has determined that it has to provide an immediate response to customers when they apply for a new financial product (credit card, loan, savings account, etc.). The current approval process is complex; it involves batch processing of data; and the customers are notified by mail. A system developed in house (system A) performs the batch processing. The processing flow and the business rules are "hard coded," and there are few configuration options. The company has recently deployed a commercial off-the-shelf (COTS) system (system B) to handle the approval process for a certain type of financial product. The COTS package contains a flexible workflow engine that allows non-IT personnel to enter or modify business rules. This solution works in both batch mode and interactive mode, but extending support for additional product types requires significant customization work. Both systems interact with numerous client systems. None of these interactions happens in real time, as processing involves file transfer via FTP (File Transfer Protocol). Although the company has an internally developed middleware platform that is used by many customer-facing applications, neither system A nor system B is configured to use this middleware.

Capturing stakeholder concerns

We articulate the business vision as a set of stakeholder concerns, which are represented by class Concern. Figure 2 illustrates the Concern branch of the ontology, which consists of class Concern and its five subclasses: Business Need (business goals, objectives, or issues), Risk, Change Case (future requirements), Quality (nonfunctional requirements such as performance, reliability, etc.), and Capability (functional features of the system). The arrow pointing to class Concern represents the relation subclass of. We capture all the "architecturally significant" concerns, both pre-existing and new, in Protege. Figure 3 shows how the concerns appear on the screen. Here are some instances of Concern that we have identified in our case study.

* Offer customers a real-time credit-approval service (Business Need).

* Make credit-approval service available within six months (Business Need).

* Limit budget overrun to 10 percent (Business Need).