The goals of developing systems better, faster, and cheaper continue to drive software engineering practitioners and researchers to investigate software engineering methodologies that are novel, yet practical. As the size and complexity of systems continues to grow, there has been a growing interest in the investigation of social paradigms (e.g., agent- and goaloriented approaches) and the use of COTS components. These are being viewed more and more as promising, and also perhaps inevitable, solutions to this problem. The effective application of social paradigms and use of COTS components, however, requires a systematic approach that provides a set of concepts for modeling the subject matter, a set of guidelines for using such concepts, and tool support to assist the developer. In this paper, we present an overview of a COTS-Aware Requirements Engineering (CARE) approach that explicitly supports the use of COTS components. Our CARE approach is knowledge based, has a defined process, and is agent- and goal-oriented. In more detail, we present the models and ontology that support the definition of agents. Our CARE approach is validated using a part of a Digital Library System; a prototype of the CARE Assistant tool is used to present some preliminary results.
The goal of developing systems better, faster, and cheaper continues to drive software engineering practitioners and researchers to investigate software engineering methodologies that are novel, yet practical. As the size and complexity of systems continues to grow, there has been a growing interest in the investigation of social paradigms (e.g., agent- and goaloriented approaches) and the use of COTS components. These are being viewed more and more as promising, and also perhaps inevitable, solutions to this problem.
Our work is focused on creating, modeling and analyzing a goal- and agent-oriented
requirements engineering approach that explicitly supports the use of commercial off the
shelf (COTS) components. Our approach is called the COTS-Aware Requirements
Engineering (CARE) approach. It is agent-oriented (as in [
The CARE approach is being defined with a set of models and is supported with a prototype of the CARE Assistant Tool. Models are used to embody abstract ideas in a concrete representation. In a model, the ideas are more easily communicated, reviewed, and revised. The properties we seek in a model include completeness, consistency, correctness, etc. We also recognize that a model needs both an ontology and a methodology. An ontology is a formal description of entities and their properties; it forms a shared terminology for the objects of interest in the domain, along with definitions for the terms. A methodology describes how the entities are used or created. In CARE, the models include a process, product, and a meta-model. The process model describes the activities performed to define the system agents, goals, system requirements, software requirements, and software architecture (with respect to using COTS components). Each activity defines who performs it, the steps, constraints, inputs, and outputs. The product model describes the format of the output, or products, created using the process. The CARE meta-model defines the ontology for the approach. Entities include agents, goals, system requirements, software requirements, COTS components, assertions, and activities.
We recognize that developing the CARE approach is an ambitious project. To accomplish the
work, we are using an iterative approach to define, refine, and validate the CARE models and
tool support [
This paper is organized as follows. Following the introduction, we describe related work and then provide an overview of the CARE approach. Subsequently, parts of the process, product, and ontology that support the definition of agents are presented. Some of our lessons learned are described; this is followed by our conclusions and future work.
The CARE approach draws upon research in a number of areas including agent- and goaloriented paradigms, knowledge engineering, process engineering, and COTS based software engineering work. As the focus of this work is integrating agent-oriented research in our CARE approach, we focus the related work section on research in the use of COTS components and agent-oriented paradigms in software engineering.
Approaches that offer specific technical solutions that are applicable to the requirements
engineering phase include the Rational Unified Process (RUP), Model-Based Architecting
and Software Engineering (MBASE), and the Procurement Oriented Requirements
Engineering (PORE). RUP is a comprehensive, object oriented software engineering process
model [
The MBASE approach focuses on the early phases of software engineering. It considers four
types of models: success, process, product and property [
From the PORE technique, we draw on its support for the evaluation and selection of COTS
components [
An overview of the CARE approach is provided in this section (refer to Figure 1) and it is
illustrated with examples from the Digital Library System. The reader is referred to the
complimentary technical report in [
The CARE approach supports the definition of agents, goals, system requirements, and
software requirements. The first task is to define the agents for the system. As part of the
definition, the goals of the agents are captured; these goals are used to drive the development
of the system. Goals are very high-level objectives of the system. The may be functional
(hardgoals) or non-functional (softgoals). Goals are related to the other goals of the system
using the NFR framework [
Describing the CARE approach requires an agent-oriented notation. We have selected the i* framework as it is well suited for describing goal and softgoal dependencies among agents
Goals Specification Component n Specification Component 2 Goals
… Goals
System Requirement System Requirement
Software
Requirement Software Requirement … …
Specification
Component 1 Legend
Mapping System Goals to Component Goals
Mapping System, Software Requirements to Component Specification
Agent
[
An overview of the CARE process model from an agent-oriented perspective is illustrated in Figure 2. At this level, the agents are three interdependent businesses: Customer, Development House, and the Component Vendor. For example, the Development House depends upon the Customer to validate the system artifacts.
CARE Process Model: Define Agents The process model is refined (refer to Figure 3) to illustrate additional details for the goal to deliver the system artifacts. In addition, this figure contains the strategic rationale model for the RE. To accomplish the goal of delivering the agents, goals, and requirements for a system, the RE performs the corresponding tasks.
In Figure 4, the model is further refined to illustrate the tasks involved in defining the baselined agents. The RE's tasks include elicit, analyze, correct, validate, and baseline the agent definitions. The RE uses them iteratively to refine the definitions of the agents. Sources of information to accomplish these tasks include the customer (end users, managers, etc.), existing documentation for the system, the expertise of requirements engineers, software architects, and component engineers, etc. Each of these tasks is described briefly below:
Customer Legend Development
House
Component
Sales
Deliver Within Budget
Component Deliver On Time
Component Deliver High Quality
Component
Deliver Component Artifacts
Component
Vendor Dependency Relationship
Goal
Softgoal
Elicit Agents. The RE identifies and defines the agents, or stakeholders, for the system under
development. The agents may be people, computer systems, or businesses. For example, the
people may include the end-users, administrators, managers, people responsible for procuring
the system, and people responsible for developing the system. An agent is intentional and has
one or more roles to play. Each role has a unique identifier, agent dependencies, and abilities.
To elicit the initial set of agents, the RE begins with the enterprise goals and the initial
concept of the system. To identify additional agents, the RE may use interviews, surveys,
workflow analysis, and examine the documentation of the current system (if available). A
significant amount of work has been done in the area of elicitation (e.g.,[
Validate System Agents. The RE uses feedback from the customer to validate the definition of the agents. The RE documents the decisions and the rationale for the decisions made performing the task.
Baseline System Agents. The RE and CM baseline the validated agent definitions and place them under configuration management.
Deliver Within Schedule
Architecture Deliver Within Budget
Architecture Deliver High Quality
Architecture
Deliver Architecture
Validate Architecture Component Vendor
Dependencies … Define Baselined
System Agents (see Figure 4)
Define Baselined
System Reqs (with COTS)
… Requirements
Engineer
Provide Arch.
Expertise
Define Baselined
System Goals (with COTS) Define Baselined Software Reqs (with COTS)
Maintain
Repository Maintain Quality
Repository Provide RE Expertise
Component
Engineer Maintain Quality
Repository Architect
Maintain
Repository
CARE Product Model: Define Agent
The users of the CARE process may select their own techniques for the product model. In
this work, we use a tabular approach to summarize the attributes the RE needs to define. This
presentation is similar to examples available in the MBASE approach [
Unique Identifier. This attribute is used to support traceability. The Agent Unique Identifier is “A_” followed by a unique three digit integer. (e.g., A_001). Each instantiation of an agent has exactly one Unique Identifier attribute value. The attribute is required.
Define Baselined Agents Correct
Agents Elicit Agents
Analyze Agents
Validate Agents
Baseline Agents Type. This attribute defines the specialization of the agent. For example, the Agent may be a User, Administrator, Development Staff, etc. Each instantiation of an agent has exactly one Agent Type attribute value. The attribute is required.
Role. This attribute defines the role an agent is performing. For example, in a DLS, the role may be junior librarian, senior librarian, borrower, system administrator, etc. Each instantiation of an agent has exactly one Role attribute value. The attribute is required. Association. This attribute defines the association of the agent. For example, the agent may be associated with the company acquiring the system, with the development house, or with a component vendor. The Association attribute is optional.
Perspective. This attribute defines the perspective of the agent. For example, the agent may be viewing the system from a customer’s perspective or a developer’s perspective. Each instantiation of an agent has exactly one Perspective attribute values. The attribute is optional.
Relevance. This attribute defines why the agent is relevant to the model of the system. For example, how does the agent interact with the system to meet a business need. Each instantiation of an agent has one or more Relevance attribute values. The attribute is required. Other Agent Dependency. This attribute defines the other agents that are depended upon to accomplish goals. The agents may be needed to accomplish a goal when the product is being built or when the product is being used. Each instantiation of an agent has one or more other agent dependency attribute values. The attribute is optional.
Goals. This attribute defines the goals of the Agent. The goals may be related to building the product or using the product. Each instantiation of an agent has one or more Goal attribute values. The attribute is optional.
Ability. This attribute defines the ability, or skills, the agent has to accomplish the goals. Each instantiation of an agent has one or more Ability attribute values. The attribute is optional.
Assumptions. This attribute defines any assumptions about the Agent. Each instantiation of
an agent has one or more Assumptions attribute values. The attribute is optional.
Notes. This attribute defines any additional notes about the Agent. Each instantiation of an
agent has exactly one Agent Notes attribute value. The attribute is optional.
Agent Ontology
The most general class in the ontology is the Agent. Agents in this class are specialized as
enterprise (i.e., a company), people, and computer systems. Enterprise agents are specialized
into businesses involved in developing components, developing a customer's system, and a
customer. Associated with the development house are people who work for the company and
fill the roles of requirements engineer, software architect, and component engineer. The
agents may have one or more assertions (e.g., a system agent must have at least one system
goal) and they accomplish goals by performing activities.
Illustration
The support for defining system agents in the CARE approach is validated by applying it to
(part of) a DLS example. A DLS is selected as the example because it is a complex,
largescale, non-proprietary system with a rich set of functional and non-functional requirements.
The example is illustrated using the prototype of the CARE Assistant Tool. The prototype
supports a subset of the constructs in the meta-model, including the agents. ConceptBase [
The RE has a goal of defining the baselined system agents for the DLS. In this example, the routine to define the set of baselined system agents is composed of the tasks to Elicit, Analyze, Correct, Validate, and Baseline Agents. When the initial set of agents are defined, their analysis identifies errors of omission such as undefined attributes and errors of commis sion such as incomplete descriptions. The elicitation, analysis and correction of the defin itions is an iterative process. When they are considered to be complete, consistent, and correct by the RE, the customer is asked to validate the definitions. In an academic setting, we realize that the tasks are significantly simplified as we do not have real customers. Using the CARE process and product models for the definition of agents, the classes for the agents and instances for the DLS example are defined in O-Telos. Example is presented below for a junior librarian (refer to Figure 5 for a graphical representation).
User_Goals1: Goal_G_002
{* The DLS should be easy to use *} User_Goals2: Goal_G_004
{*The DLS should have high availability*} User_Goals3: Goal_G_005 User_Goals4: Goal_G_006 User_Goals5: Goal_G_007 User_Goals6: Goal_G_008 User_Goals7: Goal_G_009 {*The DLS should have fast performance even when the system is loaded with the maximum number of users *} {*The users should be able to access a large number of diverse objects*} {*The users should be able to search, browse, and retrieve objects quickly and efficiently from remote locations*} {*The librarians should be able to maintain the library quickly and efficiently*} {*The librarians should be able to provide reference support quickly and efficiently*} Individual junior_librarian in UserAgentClass with UniqueIdentifier
User_ID: "A_001" Association
User_Association:"Library Company Inc." Perspective
User_Perspective: "Customer" User_Type: "end user"
User_role: "junior librarian" Relevance
User_Relevance: "1. Interacts with borrowers to provide reference assistance. 2. Interacts with DLS to obtain library items. 3. Interacts with RE to provide domain expertise.
4. Interacts with RE to validate agent, goals, requirements" AgentDependency
Agent_Dependency1: UserAgent_A_004 AgentDependency
Agent_Dependency2: DeveloperAgent_A_009 Goals Type Role Goals Goals Goals Goals Goals
Goals
Goals Goals End User_Goals8: Goal_G_011 {*The DLS should be scaleable in order to accommodate new collections or additions to the current collections. *} User_Goals9:Goal_G_012
{*The DLS should be secure*} Ability
User_ability: "Trained in library science, 0-2 years experience" New agents identified in the CARE approach for the development house are the component engineers (CEs). The CEs are responsible for adding, modifying, and deleting COTS components into the repository. They are a source of technical expertise for the REs when matching and selecting possible COTS components. The component vendor, an enterprise agent, is another new addition when considering a COTS-aware approach. People agents working for the component vendor such as the technical sales representative or technical support personnel are also stakeholders in the system development.
We have already learned a number of lessons in developing this phase of the work. The formalization into O-Telos class definitions has encouraged the development of a complete, correct model. As the definitions were being developed, it became an iterative process to define, validate, and correct the definitions.
Attributes that were initially defined, but later appeared to have little value in the validation with the DLS example, were deleted. An example of this case was in the System Agent class. Initially, the name of an agent was included as an attribute. In the validation, it became clear that the role the agent was playing (e.g., junior librarian) was more relevant. As we modeled the interdependencies among agents, we encountered a problem while trying to strictly adhere to the i* framework. In i*, agents are allowed to be decomposed and refined, however goals are not. Due to the complexity of our model, we also need to decompose goals to ensure the models are straightforward to review and correct. A simple solution has been selected to work around the restriction: we represented the refinement of a goal on a separate diagram. If this extension can be formally added to the i* framework it may be valuable for the RE community.
The CARE research project is defining CARE process, product, meta-model, and tool support concurrently. The intent is to have a set of models and tool support that work together and are practical to apply to complex, large-scale systems. An iterative approach is being used to systematically extend and refine the models and tool support. As each part of the work matures, it can be used to detect problems such as incompleteness, inconsistency, or ambiguity in the other parts.
In this paper, our contribution is to present our preliminary work in the CARE approach that
supports the definition of agents. We present the process model, product model, and agent
ontology; the approach is illustrated with an example from a Digital Library System. A more
detailed description of the CARE is available in [
As we have only used one example system to validate the work, we recognize that additional validation with different systems is needed. The next example system we intend to use is a telepresence system. We also plan to extend and refine the CARE approach's models (process, product, meta) and tool support. More specifically, we propose to support reasoning about contradictory, non-functional goals using the NFR framework.