EMMA Knowledge Representation

This report describes the metamodel for EMMA, an Evolution-Memory Management Assistant, a system to be developed by CoGenTex as part of the Evolutionary Development of Complex Systems (EDCS) program, funded by DARPA and Rome Laboratory. This metamodel is presented in fulfillment of the requirement for the first contracted deliverable.

EMMA, an Evolution-Memory Management Assistant, is being designed to support the collaborative development and evolution of complex systems. EMMA will manage the collection "evolution memory" for a software system, which will contain information about the context in which design decisions are made, including plans for future system evolution. Software developers will have the opportunity both to draw from this memory to understand the reasons for past decisions and the consequences of evolutionary changes, and to add to it, to make their own insights available for future system evolution.

Our approach to supporting software evolution in EMMA is to let the developers' goals for software evolution drive the way design knowledge is acquired and presented. EMMA will support the communication and management of information about the goals and plans for system development. In this way, we believe that EMMA will help system developers to collaborate as the system is being developed, and will also help future system maintainers in analyzing the impact of system design changes. EMMA will use its knowledge of the system's development goals to select information that is relevant to a developer's evolution task and will display it in a form that directly supports that task.

Evolution information in EMMA will be organized in a knowledge base designed around four interrelated concepts:

system development goals,
plans for achieving those goals,
assumptions under which the goals are to be achieved, and
change events that may alter goals, plans, or assumptions.

Goals, plans and assumptions provide context for design decisions by relating lower-level decisions to higher-level purposes and to the assumptions under which decisions are made.

Evolutionary change events can arise in EMMA in two different ways. In a top-down fashion, a change event makes explicit a possible evolution direction for a system, so that developers may anticipate and plan for future changes. In a bottom-up fashion, a change event may appear as an "exception" to a low-level goal, signaling a problem or opportunity that may necessitate a change to higher-level design decisions. Using the interrelationships among change events, plans, and goals, EMMA will be able to trace the anticipated impacts of evolutionary changes.

EMMA will acquire and present information through a Java-based hypertext interface. This interface will support the developer in browsing and updating the EMMA knowledge base of system development goals, assumptions, and evolution directions. These in turn can be linked to source documents (requirements or specifications stored in various collaborative and software development tools). The hypertext used in focused presentations (such as presenting the results of tracing the impact of a hypothetical change event) will be dynamically generated by CoGenTex's advanced text generation system.

By managing information about design decisions and directions for change, EMMA will help developers to understand the issues involved in changing systems and to be proactive in planning for system evolution.

EMMA Metamodel for System Development and Evolution

In this section, we describe EMMA's metamodel for collaborative system development, which is intended to capture the most important issues involved in system evolution.

Goals, Plans, and Solutions

For developers to reason about system evolution, they need to understand the goals for the system and its components. The development process consists of communicating such goals among the development team, creating plans for achieving those goals, and carrying out those plans. Plans may be changed in light of changes in requirements, assumptions about the operating environment, or the developers' understanding of the issues.

In the EMMA metamodel for system development, a goal will always be to build some system or system component that solves some problem or addresses some need. We will use the term solution, adopted from the domain of business system development, to refer to the system, system component, or other software engineering artifact that is created to achieve a specific goal. For EMMA, the exact nature of a solution (whether it is code, or design, or hardware, or only documentation) is not relevant; the important information for EMMA is the goal that the solution achieves, and the context or assumptions under which the solution achieves it. Because of EMMA's indifference to the exact nature of a solution, EMMA will be able to link up with a wide variety of different tools for maintaining system artifacts: text editors, graphical modeling tools, etc.

A plan in the EMMA metamodel is a strategy for creating a solution fulfilling some goal by partitioning system responsibilities among components, each of which must fulfill some simpler subgoal. For example, a plan for building a complex system might involve partitioning the system into user interface, data structures, and algorithms, each of which would have its own goal to fulfill.

In the EMMA metamodel, each goal may have a number of alternative plans for achieving that goal. In turn, each plan may be associated with a number of subgoals, which represent steps in the plan. In this way, complex high-level goals are decomposed into simpler, more specific low-level goals. Then solutions to higher-level goals are constructed by composing low-level solutions according to the associated plans.

The collection of goals, plans, subgoals, and their associated solutions will be referred to as a solution structure. A simple solution structure is shown in Figure 1.

Figure 1: EMMA Solution Structure

Collaboration: Goal Owners and Contractors

Another aspect of software development supported by EMMA's metamodel is collaboration. In developing a solution to meet some high-level goal, developers proceed by factoring each goal into smaller subgoals. Often, the subgoals are worked on by different developers who must coordinate their actions. To facilitate this coordination, the EMMA metamodel has a notion of the owners and contractors for goals. The owner of a goal is responsible for that goal and any solution developed to achieve it. A contractor for a goal is a developer who is working towards achieving the goal. Only a goal owner may change the requirements associated with the goal, but a contractor for a goal is able to create, modify, and act on a plan for achieving the goal.

Negotiation and Discussion Among Collaborators

There are two main models for collaboration that are commonly used:

Top-down models, in which the goals are established at the top-level, and carried out at lower levels, and
Peer-to-peer models, in which all participants are treated as equals.

The main problem with a pure top-down approach is that it lacks flexibility; if the original partitioning of the tasks turns out to be inappropriate, it can be very difficult to change it. On the other hand, pure peer-to-peer collaboration can become very unstructured and unwieldy; it is difficult to keep focused on the ultimate goals for the project as a whole.

In designing the EMMA metamodel, we adopted the structure of the top-down approach, but at the same time we took steps to address its inflexibility:

The hierarchy in the EMMA metamodel is a hierarchy of goals, not a hierarchy of workers or of tasks. The metamodel does not prescribe any order for carrying out tasks, and it does not specify who may or may not work on various tasks. A developer may simultaneously be working on several goals at once, and the owner for one goal may be a contractor for another. Also, tasks performed in order to accomplish goals can occur in whatever order is specified by the organization's policies or process methodology. The EMMA solution structure provides a way of organizing the results of the development tasks without prescribing how those tasks are done.
EMMA explicitly supports evolution of the goals for a system.
EMMA supports "bottom-up" as well as top-down influences on a system's design. Often the final requirements for a system or for a component of a system are arrived at only after a period of negotiation and discussion. A goal owner asks "Can you give me this?" and the contractor responds, "No, but I can give you this similar thing that will do just as well in most cases." The EMMA metamodel is designed to support such communication and record it, so that this crucial information about how requirements evolved will be available to support future reasoning. EMMA's exception mechanism (described here) provides this support.

Much of the information that we intend to manage for EMMA is information that is already being produced in large software projects, but is not currently organized and maintained to support system development and evolution. We believe that the structure of goals, plans, and subgoals, with their associated owners and contractors, will provide a powerful framework for communicating this information needed to develop and evolve a complex system.

Context

In designing a new system, developers need to keep in mind two different kinds of information:

properties of the desired system: what functionality the users of the system (where the "users" might not be human; they might be other systems) can expect the system to provide, and
contextual information: assumptions about users, other systems, computational infrastructure and operating environment on which the system can rely.

Typically, a system's requirements combine both types of information, but very often much of the background information about the expected behavior of users and the properties of the operating environment is left implicit. The lack of documentation of implicit assumptions makes it very difficult to uncover the impact when this kind of information changes.

The EMMA metamodel explicitly distinguishes between functional requirements for the system and the context within which the system is developed. The context consists of background information that is needed to understand a system's functional requirements, including:

the definitions of terms used in the requirements,
assumptions about the domain, users and the operational environment, and
properties of other systems with which the system being built must interact.

The context provides a framework within which the solution is to be constructed, and describes the system's role within that framework.

In the EMMA metamodel, the context associated with a goal will include the answers to the following sorts of questions (not intended to be exhaustive):

What sort of users will be operating the system, and what kind of training will they have?
How many users will operate the system simultaneously?
Into what sort of operating environment will the system be placed?
What resources (COTS products, tools, etc.) will be used with the system being developed?
What are the properties of those resources on which we can we rely?
What are the meanings of the terms used in the requirements documents?

Goals occurring at different levels of the solution structure will have different associated contexts. The context for a component of a system will include information not only about external systems and users, but also about other components with which it must interact.

In understanding the design of a solution, this kind of context information is as important as the functional requirements that the solution must meet. This is especially true for system evolution. When putting a system into a new environment, it is crucial to understand what assumptions about the environment were made by the original developers. If some of these assumptions are no longer valid, then the system will likely need to be redesigned. Being able to trace the assumptions to the specific system components that rely on them would greatly improve the efficiency of responding to system changes.

Evolutionary Changes

An innovative feature of the EMMA metamodel is the explicit support for evolutionary changes of a system's design. The following list, from a description of Lockheed-Martin's Transportation Information System Scenario, illustrates some of the support for evolution that may be needed for a large, complex system, the Global Transportation Network (GTN) system. We plan to design EMMA to meet these sorts of needs.

opportunistic architectural changes resulting from changes or improvements in technology on which the system depends (for example, migration from traditional client/server to web-based architecture),
COTS component replacement for performance, obsolescence, or other reasons (e.g., replacing COTS infrastructure components by new components having improved functionality or performance, while retaining architectural integrity),
planned architectural evolutions that have been anticipated, planned and initiated by the evolving organization (e.g., adding new feeder systems, replacing old ones, adding major chunks of new functionality, moving to higher levels of compliance within the DIICOE specification),
unforeseen, internally generated changes arising from data quality problems or changes in externally controlled events, systems, or interfaces (e.g., a feeder system is upgraded or does not match its documented interfaces),
changes necessitated by internal or external V&V result (e.g., performance problems may drive redesign of some components),
needs for analyzing the system at the architectural level to determine or predict the impact of changes without incurring the cost of implementing them, and
requests to apply or redeploy GTN or subsets in new ways (e.g., migration from a centralized architecture to distributed architecture to reduce vulnerability and to provide GTN-like capability to local theaters).

To provide these kinds of support for evolution, EMMA will explicitly record information about system design and requirement changes that is currently only maintained informally, if at all.

In supporting system evolution, the EMMA metamodel distinguishes two different types of change:

top-down evolution due to change events, which reflect changes in the goals or context for some part of a system, and
bottom-up evolution due to exceptions, which reflect problems or opportunities encountered in carrying out some plan.

Below we describe these two types of evolutionary changes in more detail.

Top-down changes: Anticipated Directions for Evolution

While modern software development methodologies do a fairly good job of making explicit the requirements that the system and its components must meet, there is comparatively little support for recording the thoughts of customers and developers about likely directions of evolution for the system.

This lack represents a missed opportunity in planning for the system's evolution. As has been pointed out by Boehm [WinWin], the final requirements of a system are only decided after a period of negotiation among all the stakeholders: government agencies, end-users, developers, etc. During this negotiation, many of the system features that customers or end-users would like are "scoped out"; to save money, time, or effort, these requirements are left to future enhancements. Later, these dropped requirements are often reinserted, not during the initial development, but during the maintenance and enhancement stage of the system's lifecycle. Unfortunately, the original thinking about these enhancements is often lost. The scoped-out requirements are treated as brand new requirements, and they are often implemented in an ad hoc way that makes the system more difficult to understand and maintain.

To address this problem of lost reasoning about evolution, we introduce the notion of a change event. A change event is a possible change to the goals or context for a system. When developing a system developers need to record not only the initial requirements, but also

the likely directions for evolution, and
the developers' anticipated responses to possible evolutionary changes.

By keeping track of this information, EMMA will help current developers to plan for evolution and will also give future maintainers a head start towards understanding the impact of changes.

In determining the possible evolution directions for a system, developers, customers, and end-users need to think about the following sorts of questions (not intended to be exhaustive):

Are there aspects of the requirements that are currently out of scope, but will likely need to be addressed in future versions of the system? For example, the requirement that a system should be multi-user, or that it should be distributed, is often dropped to simplify the design of the first release. Such requirements often reappear as directions of change for future releases.
Can some requirements be thought of as special cases of more general requirements that might be needed in the future? For example, the requirement that a tool record previous values of variables set by the user is just a special case of the requirement that the tool maintain a history of users' interactions. In the future, a more complete history mechanism may be required.
Which requirements are volatile, so that they might disappear or be changed significantly in the case of a likely change in technology? For example, a requirement that a system never uses more than 1 megabyte of RAM is made obsolete by the dropping price of memory.
Do some requirements lump together different things that might need to be separated in the future? For example, requirements for a user interface may not distinguish between the needs of system administrators and the needs of programmers, but this distinction may be important for future releases.
If a requirement is parameterized, (for example, the requirement that the system should support 5 users) are the parameters fixed, or are they likely to change in the future? If the latter, what are the ranges of possible future values of the parameters?
Are there assumptions about the capabilities of a COTS application that might no longer be true for a new release? For example, the initial design of a system might reflect the need to work around a COTS tool's lack of CORBA-compliance, or lack of support for multiple users.

When a system is decomposed into a number of components, many of the change events relevant to a component will appear in the evolution directions of the system as a whole. However, additional change events may be introduced at lower levels of system decomposition. Each component will have certain expectations from other components, and will provide certain functionality to other components. Because of this, there will be change events described in terms of these cross-level dependencies that are not derived directly from top-level evolution directions. Another kind of change that is only relevant for low-level system goals is a change of implementation infrastructure or programming language.

Bottom-up Change Events: Exceptions

In addition to those "top-down" change events that developers could, in principle, plan for, there inevitably will be unforeseen circumstances that force changes to the design of a system. In partitioning the requirements for a large system into requirements on individual system components, developers often find that the original development plan needs to be modified. This can be due either to a problem or an opportunity discovered in working on a system component. A problem occurs when a developer discovers that the requirements for some component cannot be met (given the time and effort devoted to it). This might happen because the requirements were unrealistic, or because of unforeseen bugs or limitations in tools or COTS components. An opportunity occurs when a developer working on one component discovers a solution to a problem some other developer is facing. Another type of opportunity occurs when a new COTS tool is released that solves some of the problems in older versions.

In these cases, the design of the system may change in order to work around problems or to take advantage of an opportunity. In the EMMA metamodel, this kind of "bottom-up" change will be called an exception, in analogy with the exceptions that may be raised in a programming language. Faced with a problem or opportunity occurring at a low-level goal, a contractor for that goal may "raise an exception" to inform the goal owner about the need for a design change. Like the exceptions in a programming language, an EMMA exception may be either "handled" by working around the problem, or "propagated upwards" to be taken care of at a higher level.

An exception raised by a contractor often amounts to an acknowledgement that in some way, the requirements for a system or system component cannot be completely satisfied. A goal owner asks of its contractor "Can you give me this?". In raising an exception, the contractor responds "No, but I can give you this similar thing that will work just as well in most cases." For example, a developer might use an exception to indicate that the system will be unable to handle requests from more than 5 users at a time. An exception might also indicate that some component will only work correctly if its inputs arrive in a particular order. Another kind of exception is a request for some kind of service or information that is needed to fulfill some goal. For example, a contractor for a goal may report: "I can only meet these requirements if somebody else provides me with certain functionality."

The EMMA metamodel provides a framework for recording such exceptions and the responses to them so that this history can help future system maintainers understand the interrelationships between the goals of the system's components.

Ultimately, every exception that is not handled at some level will become a limitation on or assumption about the operation of the system being developed. Such an exception may either limit the kinds of environments into which the system can be put, or it may limit the kind of user behavior to which the system must respond. For example, the limitation might be expressed as a demand that users follow a particular policy or protocol when using the system.

EMMA's Notion of Evolutionary Rationale

After all exceptions have been handled in one way or another, the system's goals and context can be redescribed in a purely top-down fashion. However, it is useful for the point of view of evolution to know the rationale for a goal or assumption: Where did it come from? Is it ultimately derived from facts about the domain, or is it there for design or implementation reasons?

We anticipate several uses for this network of dependencies among goals and their contexts:

When a system is placed into a new environment, the assumptions under which the system was developed may no longer hold. A system maintainer would like to be able to trace from an assumption occurring in the top-level context to all those lower-level goals that depended on that assumption. This information would help to determine what system components need to be modified to accommodate the new environment.
In system maintenance, it is useful to be able to identify system components that fulfill goals that are no longer needed. These components can then be eliminated for efficiency or changed to meet some new goals.

Comparison with other Tools and Methodologies

The EMMA metamodel has some similarities with other approaches to recording and reasoning about assumptions and goals of systems and system components. In this section, we discuss these similarities and what we believe to be the unique features of the EMMA metamodel.

EMMA and Design-by-Contract

EMMA's approach to system development by partitioning into components, each of which must satisfy certain requirements, is similar to the idea of "Design by Contract" [Meyers]. An EMMA solution structure can be thought of as a contract for building a solution and also for future evolution of that solution. However, Design by Contract as it is usually interpreted does not provide any mechanism for discussion and negotiation about the nature of the contract; it is a purely top-down development. The EMMA metamodel is unique in providing for exceptions, which allow for "contract negotiation" in which bottom-up influences can affect the final design for a system.

Each goal in an EMMA solution structure represents functionality that the contractor promises to provide (by building a solution). The context associated with a goal represents commitments made by the goal owner (which can reflect functionality provided by other contractors, or guarantees about the users or operating environment). This view of system development is compatible with (but not limited to) the concept of required and provided interfaces for components [Euclid, TRP, CBSE]. The provided interface describes the external behavior the component must satisfy, while the required interface describes the demands the component makes on (or services required of) other components. The EMMA notion of exceptions is broader than the usual notion of required interfaces, however. Exceptions allow a component to make demands not only on other components, but also on users and on the environment. Thus in an iterative development model, some of the high-level goals for the system may ultimately reflect the needs of particular components. This is important for system developers to know, since evolutionary changes may modify or eliminate components and thus make some system requirements obsolete.

IBIS/REMAP

IBIS (Issue Based Information Systems) [IBIS] is a model for representing discussions such as those that a group might have prior to making a decision about a course of action. IBIS sorts the information about how such a discussion progressed into several categories of discussion objects:

Issue. An issue is usually a question that needs to be answered, such as "How shall we accomplish such-and-such?". Such questions are the starting points for discussions.
Position. A position is a proposed answer to a question, or a proposed approach to addressing an issue. For example, if the issue is "How shall we get a system with such-and-such properties?" there may be two main alternative positions: (1) "Build it" and (2) "Buy it."
Argument. An argument is a reason for supporting or objecting to a position. For example, the position called "Buy it" may have a supporting argument "It is quicker" and may have an objecting argument "No current products have a flexible enough interface."

A problem with IBIS is that discussions can grow to be enormously complicated, and there is no support for relating the discussions to decisions that have been actually made in the development of a system. Partly this is because IBIS was intended to be a general model for representing discussions, and was not created with software engineering specifically in mind. REMAP (Representation and Maintenance of Process knowledge) [Remap] is an extension to IBIS that adds new types of objects and relationships specifically to support the software development process. In addition to the objects supported by IBIS, REMAP also provides the following additional ones:

Requirement. By introducing requirements, REMAP helps to focus discussions towards the ultimate objectives for the project.
Decision. While IBIS simply records the alternative positions, REMAP provides more history information about a project by also recording decisions made.
Constraint. REMAP explicitly records the constraints that design decisions place on the artifacts being developed.
Design Object. REMAP also explicitly represents the system design artifacts that are at issue in discussions.
Assumption. REMAP makes explicit the assumptions behind arguments.

Relationship with EMMA

REMAP captures some of the same kind of information as the EMMA metamodel. In particular, REMAP is like EMMA in attempting to relate design objects to the assumptions under which those objects were designed. The main focus of REMAP is to record the reasons for deciding among alternative design artifacts. However, in REMAP the relationship between assumptions and design artifacts is indirect: Assumptions are related to arguments, which are related to decisions, which affect design artifacts. EMMA more directly records assumptions as they are relevant to a solution. In contrast to IBIS and REMAP, EMMA structures system information not around issues to be addressed, but around the goals for the system and its components. EMMA also specifically addresses evolution. We believe that this will provide a tighter structure to the information and will allow a more efficient use of the information in future evolution.

One promising approach is to combine REMAP with EMMA. EMMA would provide the overall structure that would serve to focus system information around particular system development goals. REMAP could then be for discussions leading to a decision among alternative plans in the EMMA solution structure.

WinWin

IBIS and REMAP take discussions to be about objective, factual issues. In contrast, the WinWin model [WinWin], also funded by EDCS, recognizes that different stakeholders may have different objectives for a project and different views about what is relevant and what is important. WinWin makes the idea of negotiations among multiple stakeholders explicit in the model. The objective of a WinWin discussion is to find a set of win conditions that are acceptable to all of the diverse participants in a project.

Relationship with EMMA

We will not attempt to describe the WinWin model in detail, but instead will summarize the key points that are relevant for EMMA:

By keeping track of the sources for requirements (Which stakeholders demanded which requirements? To what extent were the requirements a compromise between different objectives?) WinWin can help future maintainers to understand the issues involved in system evolution. The objectives of the different stakeholders can be revisited at a later time to see if the reasons for the original development decisions still apply.
WinWin explicitly records when requirements are "scoped out" because of lack of resources or because of conflict with other requirements. System requirements that have temporarily been put to the side are good candidates for possible directions of evolution directions for the system.

EMMA has several features in common with WinWin. In particular, both systems support collaboration, recording of goals and assumptions, and recording possible directions for system evolution. However, these two systems are appropriate at different stages of a system's life cycle. WinWin is most appropriate during the initial negotiation of requirements among customers, end-users, and developers. Unlike WinWin, EMMA assumes that the developers are, in some sense, all on the "same team" and are trying to accomplish the same ultimate goals. EMMA is therefore more suited for goal-directed development after the initial requirements have stabilized and in planning for future evolution.

FAMILIAR

FAMILIAR [Familiar] is another EDCS project. The goal of FAMILIAR is to support system evolution by maintaining more detailed information about purposes associated with software artifacts. FAMILIAR is intended to help maintain a repository of systems and system components (or devices) together with information about the behavior and functionality of these devices.

Relationship with EMMA

FAMILIAR plans to maintain the following EMMA-relevant information about devices:

Design decisions.
Alternative designs for systems.
Features of systems.
Goals for systems.
Tradeoffs between goals.
Design rationale.

(In addition, FAMILIAR maintains detailed specifications of system functionality, which is not a focus of EMMA.) The main role for FAMILIAR is to support reasoning about properties of systems and system components. In contrast, EMMA's focus is on the goals and assumptions of the developers collaborating to build those artifacts. In principle, these two tools could successfully work together: the sort of information about system components that originates in FAMILIAR could be used to construct an EMMA goal node describing that solution.

MORALE

The MORALE system [Morale], is a suite of tools for mission-oriented legacy system evolution (also an EDCS project). There are three main components of this system: (1) Requirements Analysis, (2) Architectural Assessment, and (3) Reverse Engineering. The most relevant aspect for EMMA is in the requirements analysis component, where mission scenarios are used to elicit the goals for a legacy system and to map requirements to components.

Relationship with EMMA

While MORALE is for reengineering legacy systems, EMMA is intended to support the initial development of new systems. Like FAMILIAR, MORALE supports reasoning about the requirements and functionality of systems and system components, but does not support either planning for evolution or collaborative system development.

Although MORALE has a notion of goal, it is different from the EMMA notion:

MORALE is concerned with mission goals. These are goals that govern the behavior of a system as it is being used in a particular mission. For example, a mission goal might be to control an airplane or to support a business transaction. Mission goals view the system itself as an active agent that is trying to accomplish certain tasks.
EMMA is concerned instead with development goals. These are goals of the developers of the system. For example, a development goal may be to build a system that is user-friendly and that uses a minimum amount of processor power. Development goals view the developers as the active agents, and view the system as an artifact with certain properties.

Requirements for a system must of course be developed taking into account mission goals. However, the focus of EMMA is on the development process that takes place after these requirements have been determined; EMMA is concerned with how developers go about building a system to meet the requirements.

As with FAMILIAR, there is the potential for cooperation between MORALE and EMMA: the reverse-engineered system requirements produced by MORALE could in principle be used to provide EMMA goal structures for reasoning about evolution.

Unique Features of EMMA

There are several features of EMMA that are unique among the systems that we have looked at:

EMMA supports collaborative, goal-directed activity.
EMMA supports "bottom-up" changes.
EMMA directly supports planning for evolutionary changes during system development.

We believe that these features are crucial for a tool that will be used as a system is being developed and will also support future evolution. Without the support for collaboration in the early stages of a system's development, it is very unlikely that the developers will be motivated to record the sort of information that will be needed for future evolution and maintenance.

Feature Comparisons: EMMA and Other Tools

As can be seen in the chart below, the functionality provided by EMMA is quite complementary with the other tools discussed above. The features that EMMA does not address are (1) support for negotiations among stakeholders, which WinWin provides, (2) support for formal reasoning about functionality, which FAMILIAR provides, and (3) support for discussion about issues, which REMAP provides. (Note: Because phrases such as "supports reasoning about directions of evolution" can mean very different things in different tools, this chart should only serve as a starting point for comparing the systems.)

Supports...	*EMMA*	*REMAP*	*WinWin*	*FAMILIAR*	*MORALE*
Goal-based collaboration?	Yes	No	No	No	No
Reasoning about directions of change?	Yes	No	Yes	No	No
Bottom-up requirement changes?	Yes	No	No	No	No
"What If" reasoning about evolution?	Yes	No	No	No	No
Reasoning about alternatives?	Yes	Yes	Yes	Yes	No
Reasoning about components?	Yes	Yes	Yes	Yes	Yes
Reasoning about assumptions?	Yes	Yes	Yes	No	Yes
Negotiations among stakeholders?	No	No	Yes	No	No
Discussion of issues?	No	Yes	Yes	No	No
Analysis of legacy systems?	No	No	No	Yes	Yes

Figure 2: Feature Comparisons Among Information Management Tools

Conceptual Interaction Among EMMA and Other Information Management Tools

All the tools described above capture information about systems and system components that are currently not recorded. EMMA is intended not to replace these other methodologies, but to complement them by supporting collaborative system development in the following ways:

planning for evolutionary change,
supporting bottom-up evolution, and
supporting traceability among requirements and assumptions.

Figure 3 shows at a conceptual level the potential data flows that could connect EMMA with WinWin, REMAP, MORALE and FAMILIAR. The requirements, assumptions, and evolution directions that EMMA uses could be supplied as the result of a session with WinWin. Also, "bottom-up" changes (exceptions) due to low-level problems could be propagated from EMMA back up to a WinWin session. Requirements and goals for a legacy system or a system component could be elicited using MORALE, or developed in FAMILIAR and this information could then be used in the EMMA goal associated with a component.

The relationships among EMMA and the other methodologies can best be illustrated in terms of the stage of the development process during which they will be used:

Initial Requirements Analysis

Initially, before a system is designed, the various stakeholders must negotiate over the requirements for the system as a whole. Because the objectives of the stakeholders are not identical, many requirements will be abandoned or deferred because they conflict with objectives of other stakeholders. Some desirable system features will not be included because they are too expensive to implement or too difficult to integrate with other desirable features. This reasoning about tradeoff and about objectives of different stakeholders is the stage at which WinWin is most appropriate.

For legacy systems that need to be modified, it is necessary to try to reverse-engineer the requirements and goals for a system before the new design can be created. MORALE is intended for this circumstance.

This information taken from WinWin or MORALE could be used to form the initial goal for the EMMA solution structure. Requirements that are dropped or deferred in WinWin could give rise to change events in EMMA.

Planning the System's Design

Once the initial requirements for the system have stabilized, it is necessary to construct a plan to fulfill those requirements. This plan must take into account the assumptions under which the system to built will operate, the resources available for building it, and the possible future changes to the system's requirements or assumptions. Here EMMA can be used to record information about development history that will be needed for future evolution, and also to support developers in organizing the various interconnected goals involved in building a large system.

Deciding Among Alternative Plans

In fleshing out the plan for building a system, there will often be several alternative approaches to accomplishing the same goal. The pros and cons of the various alternatives, and the resulting decisions can best be recorded in a REMAP discussion. The results of the REMAP discussion could then be used to update EMMA's notion of the active plan for that goal.

Bottom-up Feedback and Redesign

Based on problems or opportunities encountered by developers in designing and implementing the system requirements, "bottom-up" changes (exceptions) could be propagated from EMMA back up to a WinWin session. These exceptions could initiate another, better-informed round of negotiations among stakeholders.

Developing Solutions

Once the structure of goals is produced, the developers must create system components meeting those goals. At this point, developers may use information about systems and system components produced with MORALE or FAMILIAR to build solutions out of reusable parts.

After Components are Designed

As components are designed and constructed, they can be stored in a repository for possible future reuse. To support this reuse, it is necessary to record contextual information about the components, including

what they are supposed to accomplish,
what they depend on,
what are alternative approaches to accomplishing the same thing, etc.

This information could be taken from the EMMA solution structure and could be recorded in a system such as FAMILIAR, which will also support subsequent reasoning about components.

After a System is Fielded

After a system is fielded, there will frequently be a need to modify the system to fix bugs, address new requirements, or operate under a new set of assumptions. To support these sorts of modifications, it is important to be able to recall the relationships among the system components so that the impact of the changes can be understood. EMMA is also intended to provide support for this phase. The EMMA metamodel allows maintainers to view the operating assumptions and goals under which system components were built. It allows for the impact of changes of assumptions to be traced. It also allows evolution scenarios to be "played out" to help developers see the consequences of anticipated evolutionary changes.

Conceptual Dataflows among EMMA and other Related Tools

The following figure shows conceptually how system information could be shared between EMMA and the other tools discussed in this chapter.

Figure 3: Conceptual Dataflows Among EMMA and other Related Tools

Knowledge Structures for EMMA

In this section, we will make the EMMA metamodel concepts more precise, to serve as requirements for the EMMA design.

EMMA Solution Structures

We will use the term solution structure to mean the structure of the goals and plans associated with the development of a solution (a system or component built to satisfy a set of requirements). As shown in Figure 1, the backbone of a solution structure consists of a hierarchical collection of goals and plans. A goal represents what is to be achieved (a system meeting certain requirements is to be developed). Immediately under a goal in a solution structure lies a collection of alternative plans, each of which represents an approach to achieving that goal by splitting it into a number of simpler subgoals. Immediately under a plan node are the associated subgoals. A solution structure thus has a single apex, which is the top-level goal, and a branching structure of plans and subgoals underneath.

Figure 1 shows a sample solution structure. The solution structure as a whole is associated with Goal 1, to build a design environment. There are two alternative plans for achieving Goal 1, namely Plan A: Build graphical environment, and Plan B: Build text-based environment. Under Plan A, the goal is to be accomplished by first fulfilling Goals A.1 and A.2: writing the data structures and the algorithms, and building the graphical user interface. The subgoals of Plan B, Goals B.1 and B.2, involve instead writing a parser and building an interface to a text-editor.

The plans immediately underneath a goal are alternatives (thus the use of the keyword "or" in the figure). Only one plan needs to be followed in order to achieve a goal, although it is certainly possible that several plans could be pursued simultaneously. In contrast, all of the subgoals immediately underneath a plan must be fulfilled in order to carry out the plan (thus the use of the keyword "and" in the figure). Associated with each goal is a solution (not shown in figure), which is some object fulfilling the goal. The solutions associated with subgoals will usually be components of the solution associated with a higher-level goal.

In designing a system, developers split up the top-level goals into smaller and smaller subgoals until they reach a point where the low-level goals are simple and straightforward. At this point, each subgoal can be achieved directly, either by designing some system component to achieve the goal, or by reusing an existing component.

Figure 4: Relationships Between Goals and Plans in EMMA

Terminology

In discussing solution structures, we will use the term node to refer to either a plan or a goal. We will use the directions higher and lower to refer to nodes that are, respectively, closer to or farther from the apex. For any node, the parent is the node immediately above it, and a child is a node immediately below it. We will use the term grandparent of a node to mean the parent of the node's parent, and we will use the term grandchild of a node to mean a child of that node's child. Nodes that have the same parent will be referred to as siblings. A node with no children will be called a leaf node.

In the EMMA solution structure, goals and plans alternate: every child of a goal is a plan, and every child of a plan is another goal. Therefore, a grandchild or grandparent of a goal will be another goal. As will be described later, each plan has one distinguished goal, called the working goal, which is that plan's working copy of its parent goal. The other children of a plan will simply be called subgoals of that plan. Figure 4 above shows these relationships for a simple EMMA solution structure. For each relationship, represented by an arrow, the name of the inverse relationship is shown in parentheses.

Goal Nodes

Associated with each goal node of the solution structure will be the following data:

The solution annotation: an annotated reference to an object (or a place-holder for such an object) fulfilling the goal.
The specification of the solution: a description of the properties satisfied by the solution.
The context for the solution: a description of the background assumptions, terminology, and resources under which the solution was developed (or will be developed, for an incomplete solution structure).
The elaboration of the goal: a collection of alternative plans for achieving that goal. Of these alternatives, one will be designated as the active plan. The active plan may change, as we will describe later. In some circumstances, it might be advantageous to pursue several alternative plans in parallel (using one plan as a backup in case the other plan fails), but in the initial version of the EMMA metamodel we will not support this possibility.
The collaboration information for the goal node: a description of collaborators working on various aspects of the goal and their roles (either owners or contractors).
The evolution information for the goal node: a description of changes that have affected the goal or might affect the goal in the future.

These elements of the solution structure will be described more fully in the following subsections. Evolution information, because it is common to both goal nodes and plan nodes, will be described in its own section.

The Solution Annotation

The solution annotation is information about the solution (system or system component) that is being constructed to fulfill a goal. It consists of the following attributes:

The name of the solution.
A description of the solution.
An annotated reference to a solution object.

An annotated reference is a link to an external object that is annotated with a description of the nature of the link. The EMMA metamodel does not prescribe the nature of the solution being developed, whether it is code, or specification, or graphical design, etc. Therefore, it is necessary for developers to define the semantics of links using annotations.

The solution will be some artifact representing a system or system component that fulfills the specification. When a system is first being developed, the reference to the solution object is empty, but is filled in when there is some artifact corresponding to the solution. This external link will be maintained for future system evolution.

The Specification

The specification for a solution node describes what should be true of the solution. The specification consists of:

The formal or informal type of the desired solution.
An informal description of the desired features of the solution.
A list of properties that the solution should possess. Each property consists of:

A name for the property.
A formal or informal statement that should hold of the solution.
An annotated reference pointing to the source of the property. The source of a property can be an external requirements document, or it can be another node of the EMMA solution structure.

The Context

The context provides the background information under which the solution is developed. It includes assumptions about the environment or about the behavior of users, the definitions of terms used in specifications, and the resources used in creating the solution.

The context for a solution plan or goal will have the following parts:

a list of terms used in the specification of a solution, together with their definitions.
a list of assumptions under which the solution is being built. An assumption has the same structure as a property (described above).
a list of resources relied on in building the solution. Resources represent solutions (systems or system components) that are used by a goal node but are produced elsewhere. A resource has the following parts:

A solution annotation.
A specification.

The context for a low-level goal node may in general differ from that of higher-level goals, for several reasons:

A resource occurring in the context of one goal may reflect a solution that is produced by a sibling goal. In such a case, the resource's solution annotation will contain a reference to the sibling goal that produced it.
Terms may be introduced at a certain level of the solution structure that are only meaningful at that level.
New assumptions may be introduced or assumptions may be eliminated in light of low-level information.

The Elaboration of a Goal Node

A goal is elaborated by creating a number of alternative plans for achieving that goal, with one plan chosen as the active plan. Associated with the choice of active plan is a justification, explaining why the active plan was chosen over other alternative plans, and under what circumstances might the choice change. This justification could be represented either as hypertext documentation (with hypertext links to the referents of terms occurring in the justification). Alternatively, a more sophisticated discussion of alternatives could be recorded using a tool such as REMAP.

The Collaboration Information

Associated with each goal in a solution structure is the list of developers responsible for working on that goal. An owner (or owners) of a goal is someone (a developer or a project manager) who has the right to change the context or the specification of the goal. A contractor for a goal is a developer who has the right to create a plan for achieving the goal. (The contractor then becomes the owner of that plan and its subgoals.)

Plan Nodes

Associated with each plan node of the solution structure will be the following data:

The elaboration of the plan. A plan is elaborated by giving

a working goal for the plan (describing what the plan is trying to achieve-this is derived from the parent of the plan node, as is described below), and
a number of subgoals that contribute towards fulfilling the working goal.

The collaboration information for the plan node. This specifies the owner of the plan.
The evolution information for the plan node: a description of changes that have affected the plan or might affect the plan in the future.

The Collaboration Information for a Plan Node

Unlike goals, which have both owners and contractors, a plan has only an owner. The owner of a plan will always be a contractor for the parent goal of that plan, and will be an owner of the subgoals of that plan.

The Elaboration of a Plan Node

The elaboration of a plan consists of a working goal, together with a number of auxiliary subgoals. The working goal for a plan is a kind of working copy of the plan's parent goal. Usually, the working goal and the parent goal for a plan share copies of the same solution annotation and specification. When this is not the case, an exception must be raised (described here). The context of the working goal for a plan will in general be different from that of the parent goal for the plan: solutions produced by one of the subgoals can appear in the context of the working goal as resources.

The auxiliary subgoals will in general differ from the main goal in context, solution annotation and specification. The solution for a subgoal will be only a part of the solution for the main goal. The context for a subgoal will often be a subset of the context of a main goal (because the subgoal may not need all the solutions produced by sibling subgoals).

Associated with the elaboration of a plan is a justification describing how the solutions produced by the subgoals contribute towards the solution of the working goal, and how the working goal relates to its grandparent goal. As with the justification for the elaboration of a goal, this justification can be either ordinary text, hypertext, or a structured argument such as might be recorded using REMAP.

Evolution Information

The evolution information for a goal or plan node consists of information about changes that have affected or will affect that goal. This evolution information consists of the following aspects:

A list of published change events
A list of subscribed change events
A list of anticipated responses to change events
A list of change event records
A list of exception records

Change Events

A change event is a named change affecting a solution structure. A change event may indicate a change to the specification of the solution being developed, or a change to the assumptions about the way the solution will be used. For example, often an initial version of a system is developed to run on a single machine with a single user. However, the developers often are aware that ultimately the customer will want to run the system in a distributed, multi-user environment. In that case, "make distributed" or "make multi-user" are two possible change events that the developers should be planning for.

A change event consists of

the name of the change event,
a description of the change,
a description of the circumstances under which the change might occur, and
(optionally) a goal delta (a description of how a goal should change, by adding, deleting or replacing specifications, properties, assumptions, resources, or terms).

Exceptions

An exception is an unplanned change event resulting from a problem or opportunity occurring at a lower node that affects higher nodes. Exceptions represent bottom-up changes rather than top-down changes.

A contractor for a goal may conclude that the goal cannot reasonably be met, for technical or other reasons. (Or the contractor may simply believe that a different goal is preferable.) The EMMA metamodel allows for a good deal of flexibility in handling such a situation. One possible course of action would be this:

The contractor creates a new plan node under the original goal.
The contractor makes a copy of the original goal. This copy becomes the working goal for the plan.
The contractor modifies the copy to produce a goal that he or she thinks is more reasonable.
An exception is raised, informing the owner of the original goal of the proposed change.
If the change is approved, then the contractor may continue working on his plan.
Alternatively, the owner of the original goal may send a counter-proposal.

Depending on the policies governing the development project, the contractor may be allowed to continue work on the changed goal while waiting for approval.

Another kind of exception is a request by a contractor for a goal to the goal's owner asking for some additional resource, or clarification, or information.

An exception consists of the following information:

The name of the exception.
A description of the exception.
The name of the contractor raising the exception.
The name of the node from which the exception is being raised.
Optionally, a goal-delta describing a proposed goal change.

Published and Subscribed Change Events

The owner of a goal may choose to add a change event to the list of published change events, indicating that that node is responsible for broadcasting that change event, when appropriate.

An owner or contractor of a goal or plan may also choose to add a change event to the list of subscribed change events associated with that node. This indicates that the node is interested in knowing about that type of change.

Anticipated Responses to Change Events

An anticipated response to a change event describes how the node will respond to a received change event to which it subscribes. There are four sorts of planned responses that a node may record:

For a goal node, the planned response may specify that the active plan should be switched. For example, there might be two alternative plans for acquiring a needed component: (1) Build it, and (2) Buy it off-the-shelf. The current plan might be to build the component, because there are no COTS products that meet the developers' needs (although Microsoft has one in the works). If the event "Microsoft releases it" should occur, then the active plan would switch from Build it to Buy it.
For a goal node, the planned response may specify that the goal should be changed (that is, either the context or the specification). If this response is taken, a goal-delta (described above) specifying the change will also be sent to the active plan node.
For a plan node, the response may specify that a goal-delta (described above) should be sent to the working goal or some subgoal.
For a plan node, the response may specify that a new subgoal be created, or that an existing subgoal be deleted.
In response to receiving a change event, a node may broadcast a secondary change event. For example, the current plan might call for a PC-based solution because of the prohibitive cost of Unix machines. In response to an event, "Additional funding becomes available," a node may broadcast a secondary event, "Switch to Unix." This example shows how high-level changes that would involve administrative decisions can be connected to low-level changes that would affect technical work. The use of this secondary broadcast capability is potentially more powerful than simply switching to an alternative plan. The new change event can be subscribed to by many different nodes, leading to several coordinated changes of plans.
A node may, in response to a change event, simply broadcast an exception, informing its parent that it is not capable of responding to the change event satisfactorily.

Change Records and Exception Records

A change event record consists of either

a change event received by the goal, together with a description of what was done in response, or
a change event sent by the goal, together with a description of the circumstances under which it was sent.

The possible responses are as described above for anticipated responses.

An exception record consists of either

an exception that was raised by that node, together with the circumstances under which it was raised, or
an exception received by that node, together with the actions taken in response.

Unlike change events, to which a node must subscribe, an exception raised at a node is always received by its parent node. There are two classes of responses to an exception:

The exception may be handled. There are several actions that can be taken in order to handle an exception:

A goal node may switch to an alternative plan in response to an exception.
The exception may be marked as handled external to EMMA. When the developer takes this option, he must annotate the exception record with a description of how the exception was handled.
A plan node may create a new subgoal, or delete an existing subgoal.
A plan node may send a goal-delta to its working goal or one of its subgoals.

The exception (or a translation-this is described below) may be propagated upwards.

There can be several responses to one received exception: the exception might be partially handled, and a secondary exception might also be raised.

Handling an exception externally

An exception may be marked as handled externally if it was possible to handle the exception in a way that makes no change to the EMMA solution structure. For example, a contractor for a goal might feel that some term occurring in an assumption or solution property is ambiguous or not sufficiently clear. The contractor might raise an exception indicating this ambiguity and his interpretation of this term. If the owner of the goal accepts this interpretation, he can mark the exception as handled externally. In such a circumstance, it may not be appropriate to propagate the clarification to higher levels, because it might involve low-level concepts that will not be meaningful at higher levels.

Propagation of an exception

Propagation of an exception upwards allows for translating a low-level exception into one that is more meaningful at higher-levels. For example, the low-level message "Such-and-such compiler does not correctly handle C++ templates" can give rise to the more general message, "The current design cannot be implemented using the such-and-such compiler." By recording the causal relationships between low- and high-level exceptions, the EMMA metamodel makes it possible to trace the low-level causes for high-level design or plan changes. At the same time, the exception propagation mechanism allows problems to be translated into more general, high-level terms that are appropriate for the recipients.

Consistency and Completeness of the EMMA Solution Structure

Although the long-term benefit of the EMMA solution structure is that it supports the system's evolution, an important short-term benefit is that the solution structure keeps track of consistency and completeness of a solution.

Consistency Conditions

The following invariants must always be maintained for any EMMA solution structure:

Any element (resource, assumption, or term) occurring in the context of a subgoal for a plan must also appear in the context of the working goal.
An assumption occurring in the context of the working goal for a plan must either be inherited from grandparent goal, or must be associated with a raised exception (as described above).
A resource occurring in the context of the working goal for a plan must either be:

inherited from the context of the grandparent goal, or
a solution produced by a sibling goal.

If the definition of a term in the context of the working goal for a plan differs from that of its grandparent goal, an exception must be raised. Any node may introduce new terminology, but it cannot redefine existing terminology without notifying higher-level nodes.
The solution annotation and specification of the main goal for the working goal for a plan must be the same as that of its grandparent goal, or else an exception must be raised.

Completeness Conditions

For a solution structure to be complete, the following conditions should hold:

All leaf nodes should have solutions associated with them.
Each raised exception received by a node should have an accompanying response: either it must be recorded as handled, or it should be recorded as propagated upwards.
Each exception raised by a node should have an accompanying explanation of why it was raised.
Every change event received by any node should have a record of how it was handled.
For every change event subscribed to by any node, there should be a planned response.
Every change event subscribed to by any node should be published by some node.
Every plan should have a justification for its decomposition into subgoals.
Every goal should have a justification for its choice of the active plan.

These completeness conditions will be used to generate status reports tailored for a specific developer. These status reports will remind the developer of actions that need to be taken that are relevant to goals and plans that the developer is working (either as an owner or a contractor).

How the EMMA Solution Structure Evolves

In this section, we describe very briefly how we envision that the EMMA solution structure for a system might evolve.

Initially, a developer or a project manager starts a solution structure for a new system by creating a new top-level goal and making himself the owner. Then the developer fleshes out the goal by performing the following tasks:

Creating the solution annotation by

naming the solution structure,
naming the system to be built,
giving a description of the system, and
providing annotated references (hypertext links) to the relevant requirements or specifications documents.

Creating the specification for the solution and annotating the properties with references (hypertext links) to the source documents.
Creating the context using the results of discussions with clients about the operating environment and expected behavior of users. The developer adds to the context definitions (and/or references to source documents) for all terms occurring in the assumptions or specifications
Creating change events representing possible upgrade paths or other changes to assumptions or requirements. These change events will be based on discussions of requirements with clients and other stakeholders (such as might be recorded in WinWin). The change events are added to the list of "published events" for the goal node.
The developer fills out the contractors list for the goal with the names of people who will be working on that goal.

The solution structure can grow by

Creating a new plan node for the goal and providing an annotated solution, specification and context. The creator of a new plan node becomes the owner of that node and its subgoals.
Creating a number of subgoals for a plan.
Entering the names of contractors for a subgoal.
Entering a justification for the plan's decomposition into subgoals.
Subscribing to those change events the plan node is interested in, and entering anticipated responses to them.
Raising an exception to signal any problem or a discrepancy between a plan's working goal and the plan's parent goal. (The circumstances when an exception must be raised are described below.)

Conclusion: The Use of EMMA in Software Development and Evolution

How can the network of dependencies described above be used in software development and evolution? The idea behind EMMA is that when an evolutionary step occurs, it will always be initiated by some change of goals or context at some level of the solution structure. EMMA can help in understanding the impact of such a change by tracing through the dependency relationships to discover what subgoals are affected by the change. The tracing can be used in the reverse direction, as well, to find out what high-level goals depend on what components of the system solution. This makes analysis of the impact of changes much more focussed.

The EMMA metamodel is designed to support system development and evolution in the following ways:

It supports structured, goal-directed communication about system development. EMMA provides a framework for recording information about the expectations and responsibilities of all members of the development team.
EMMA presents information about the solution status of a development project, tailored for each developer. This solution status information includes uncompleted goals and goals that have become inconsistent because of changes to requirements or assumptions.
EMMA provides evolution assistance in several ways:

It provides a mechanism for "anticipations". A developer can anticipate future changes in requirements, assumptions and resources, and can use Emma to record a plan for responding to these changes. These recorded anticipations can provide a valuable head-start for future system developers charged with responding to such changes.
It provides a new feature for "raising an exception". This is a mechanism that allows for high-level requirements or assumptions to be changed to take into account problems encountered in implementation. A developer who runs into problems in fulfilling a goal can raise an exception to request a modification to the requirements that is more realistic or easier to implement.
It supports the enactment of changes. Emma does this by tracing the impact of a change and following the previously recorded plans for changes. Emma then distributes information about changes to the contractors who must respond to those changes, and keeps track of the completion status of the response.

Bibliography

CBSE. Ning, J. Q., Miriyala, K., and Kozaczynski, W., "An Architecture-driven, Business-specific, and Component-based Approach to Software Engineering," Proceedings of the 3rd International Conference on Software Reusability, Rio de Janeiro, Brazil, November 1994.

Euclid. B. W. Lampson, J. J. Horning, R. L. London, J. G. Mitchell, and G. L. Popek. "Report on the Programming Language Euclid," ACM SIGPLAN Notices, 12(2), February 1977.

Familiar. Dean Allemang and Sidney Bailin, "Concept of Operations for FAMILIAR", draft technical report, March 1997.

Ibis. J. Conklin and M. Begeman, "gIBIS: a hypertext tool for exploratory policy discussion," ACM Transactions on Office Information Systems, Vol. 6, pp. 303-331, October, 1988.

Meyers. Meyer, B., "Applying 'Design by Contract'," IEEE Computer, October 1992.

Morale. G. Abowd, A. Goel, M. McCracken, M. Moore, C. Potts, S. Rugaber, and L. Wills, "Mission-Oriented Legacy System Evolution Through Architectural Recovery and Evaluation," to appear in ICSE-97 Workshop on Migration Strategies for Legacy Systems.

Remap. Balasubramaniam Ramesh and Vasant Dhar, "Supporting Systems Development by Capturing Deliberations During Requirements Engineering," IEEE Transactions on Software Engineering, Vol. 18, No. 6, June 1992.

TRP. Jin W. Chang and Colin T. Scott, "TRP Support Environment (TSE)," International Workshop on CSCW and the Web, 1996.

WinWin.Mingjune Lee. "Foundations of The Winwin Requirements Negotiation System." Technical Report TR-96-501, USC Center for Software Engineering, University of Southern California, University Park, Los Angeles, April 1996.

EMMA Knowledge Representation

TABLE OF CONTENTS

Introduction: EMMA, an Evolution-Memory Management Assistant

EMMA Metamodel for System Development and Evolution

Goals, Plans, and Solutions

Collaboration: Goal Owners and Contractors

Negotiation and Discussion Among Collaborators

Context

Evolutionary Changes

Top-down changes: Anticipated Directions for Evolution

Bottom-up Change Events: Exceptions

EMMA's Notion of Evolutionary Rationale

Comparison with other Tools and Methodologies

EMMA and Design-by-Contract

IBIS/REMAP

Relationship with EMMA

WinWin

Relationship with EMMA

FAMILIAR

Relationship with EMMA

MORALE

Relationship with EMMA

Unique Features of EMMA

Feature Comparisons: EMMA and Other Tools

Figure 2: Feature Comparisons Among Information Management Tools

Conceptual Interaction Among EMMA and Other Information Management Tools

Initial Requirements Analysis

Planning the System's Design

Deciding Among Alternative Plans

Bottom-up Feedback and Redesign

Developing Solutions

After Components are Designed

After a System is Fielded

Conceptual Dataflows among EMMA and other Related Tools

Knowledge Structures for EMMA

EMMA Solution Structures

Terminology

Goal Nodes

The Solution Annotation

The Specification

The Context

The Elaboration of a Goal Node

The Collaboration Information

Plan Nodes

The Collaboration Information for a Plan Node

The Elaboration of a Plan Node

Evolution Information

Change Events

Exceptions

Published and Subscribed Change Events

Anticipated Responses to Change Events

Change Records and Exception Records

Handling an exception externally

Propagation of an exception

Consistency and Completeness of the EMMA Solution Structure

Consistency Conditions

Completeness Conditions

How the EMMA Solution Structure Evolves

Conclusion: The Use of EMMA in Software Development and Evolution

Bibliography