A Knowledge-Based Environment for Modeling and Simulating Software Engineering Processes.
The design and representation schemes used in constructing a prototype computational environment for modeling and simulating multiagent software engineering processes are described. This environment is called the articulator. An overview of the articulator's architecture identifying five principal components is provided. Three of the components, the knowledge metamodel, the software process behavior simulator, and a knowledge base querying mechanism, are detailed and examples are included. The conclusion reiterates what is unique to this approach in applying knowledge engineering techniques to the problems of understanding the statics and dynamics of complex software engineering processes.
Introduction
Modeling the process of software engineering represents a promising approach toward understanding
and supporting the development of large-scale software systems. The software
process is the collection of related activities, seen as a coherent process subject to reason-
ing, involved in the production of a software system [Wil86]. A software process model is
a prescriptive representation of software development activities in terms of their order of
execution and resource management A software process meta-model is a representation formalism
which provides necessary components to create various types of software process
models [Wil86].
A meta-model of the software process should possess the capability to include major properties
of contemporary software development practice. Recent evaluations on software process
models [CKSI87, SFG85] suggest that effective software process models should address
organizational and technical dimensions including 1) detailed descriptions of software pro-
cesses, products and settings; 2) their interactions; management and exception handling
during the performance of software processes; and
and project-specific processes. We present a meta-model which uses a knowledge representation
language to specify all these aspects and further provides mechanisms to investigate
the interactions among these dimensions.
An automated modeling environment for software development should be powerful enough
to support model validation and verification. By simulating a specified software process, its
environment and its users can collectively detect faults, inconsistencies, or anomalous behavior
in a process prescription. Emerging conflicts in time schedule and resource allocation,
for example, are some common anomalies in multi-agent process plans [DLC87]. Complex
faults, on the other hand, may concern the configuration of task decomposition and organizational
settings as well. The environment should also assist in determining possible solutions
for contingencies encountered in task execution. These solutions are based on particular resource
and knowledge configurations, hence they should be setting-specific, project-specific,
agent-specific and time-specific. As such, by simulating task execution, this enables a user
to predict development progress on a more realistic basis and compare different process
models. We describe the design of such an environment which utilizes our software process
meta-model.
In the next section, we provide some background to our approach. In Section 3, we present
the system architecture of the Articulator and discuss important issues covered in the design
and use of the Articulator. Following this, we will discuss some of the subsystems in turn:
Section 4 discusses the knowledge base, which stores our meta-model of software processes;
Section 5 gives accounts for the simulation of the Articulator meta-model; and Section 6
presents the query mechanism. We then conclude with a summary of novel contributions of
the Articulator project.
Background
As we noted earlier, there has been growing interest focused on the problem of modeling,
analyzing, and automating various aspects of software engineering processes [Sca88]. Wileden
[Wil86] suggested a modeling framework based upon use of a software process meta-model.
Osterweil followed with a paradigmatic approach which cast the software process meta-model
into what he called a process programming language - a language for programming
prescriptive process models into a software development environment [Ost87].
Since then, much research effort has been directed to the design and implementation of
languages for software process automation, and to the construction of more realistic mod-
els. For example, many researchers have introduced process language constructs including
rules and pattern matching [Kai88], behavioral patterns [Wil88], graphic finite-state machines
[HK89] and agent-task-product relations [Gar89]. But none provides a direct means
for querying the status or state of a modeled software process. Others including [SFG85]
and [HL88] use knowledge representation languages and deductive planning mechanisms for
software process modeling. But overall, these efforts lead to closed, single agent (i.e, globally
controlled) systems. Further, with the exception of [HK89] and [Gar89], most efforts do not
explicitly reference or use empirical sources for their software process models.
Modeling and simulating complex organizational processes performed by people requires
an empirically based, multi-agent open systems framework [GS86, Hew86]. For instance,
[CKI88] and [BS89] are examples of recent empirical studies aimed at providing more realistic
descriptions of multi-agent software processes. But their modeling efforts have not been cast
in the form of a language or computational environment.
We seek to resolve these shortcomings in modeling and automating (ie, simulating) software
processes. This allows us to identify what is new about our work presented here. Our
approach uses a software process meta-model derived from an established approach for empirical
studies of computing in organizational settings. In addition, it allows us to model
multi-agent software processes in an open systems manner, meaning that process conflicts
can arise that must be resolved locally (ie, through agent-agent interactions), rather than
through automated global control. The environment supports the simulation of these multi-agent
process models. The meta-model, individual process models, and process simulation
traces can each be queried both directly and deductively. In the sections that follow, we will
describe each.
3 The Architecture and Users of the Articulator
The Articulator is a knowledge-based environment for studying software processes. It provides
a meta-model of software processes, an object-based language to specify models of software
processes and an automated simulation mechanism. The system architecture of the Articulator
consists of five subsystems (Figure 1): the knowledge base, the behavioral simulator,
the query mechanism, the instantiation manager, and the knowledge acquisition manager.
The Articulator has been prototyped over a two-year period using the KnowledgeCraft TM
knowledge engineering environment on a T I \Gamma ExplorerII TM [Car86].
The knowledge base implements the Articulator meta-model by an object-based approach.
The meta-model consists of the web of resources and situations, which is a model of software
development, the representation of agent's task performance skills. The Software Process
Specification Language (SPSL) is a user interface enabling users to define customized software
process models based on the meta-model. The knowledge base is defined within an
object-based knowledge cluster. Section 4 provides more details of the Articulator knowledge
schema.
The instantiation manager manages the relationships between the meta-model, the customized
software process models and their instances. It maintains all these relationships
according to creation time and lines of inheritance, as well as retrieving the correct instance
when requested. In contrast to conventional database systems, there is no explicit boundary
among the meta-model, the software process model and their instances. All of them can be
manipulated and modified as an associated instance to the old one whenever needed.
The behavioral simulator controls the simulation of a given software process model and
creates a process trajectory 2 over a development period. In this regard, behavioral simulation
is a symbolic execution of a software process model described in SPSL notation.
Mechanisms to perform software process activities are implemented within the behavioral
simulator. In terms of the representation of software processes, there are three types existing
in the Articulator: the prescriptive process model before execution, the simulated trajectory
of the prescription, and the descriptive recorded development history. Each of them serves
a different purpose in the Articulator, but bears the same form of representation. Section 5
provides a more detailed view of the behavioral simulator.
The query mechanism supports logical rules for various types of deductive queries. It
helps users access information in the Articulator efficiently. The information sources are the
knowledge base, i.e., the meta-model, the software process models and their instances. Using
object inheritance techniques and backward-inference mechanisms, the query mechanism
process trajectory is a sequence of snapshots of software development over a period of time.
AN ADVANCED CASE ENVIRONMENT
PROJECT MANAGERS, SOFTWARE PROCESS EXPERTS
S.P. MODEL M
S.P. MODEL 2
INSTANIATION MANAGER
KNOWLEDGE BASE
KNOWLEDGE ACQUISITION
QUERY MECHANISM KNOWLEDGE ACQUISITION
QUERY MECHANISM KNOWLEDGE ACQUISITION
QUERY MECHANISM
S.P. MODEL 1

Figure

1: The System Architecture of The Articulator
reasons about information and knowledge to determine answers to several types of questions.
Section 6 for a description of the query mechanism.
The knowledge acquisition manager is an interface for the Articulator to get a software
process model and associated data. The knowledge acquisition manager takes a structured
description of agents, tasks, and resources as inputs, then translates it into a configured
software process model. It also assesses the information gathered from software development
projects controlled by the Articulator and stores them for later use. An automated knowledge
acquisition manager for interactive capturing of model refinements and real-time software
process data has not been implemented yet, but simple mechanisms for model and data
input are currently in use.
Users of the Articulator fall into three categories: process researchers, project managers,
and software developers. Software process researchers study software process models in order
to identify ones that are highly efficient, satisfy different performance requirements, or reveal
subtle software process dynamics requiring further study. These users define various types
of software process models, test them by simulation, compare the simulation results with
observed development histories, and refine them according to certain criteria. This is an
iterative, incremental process; it continues until an acceptable model of software processes
is achieved which fits in a particular infrastructure. These users may potentially modify the
meta-model as well when it is necessary to incorporate new features into it.
Software project managers select or configure an existing software process model which
suits their project needs and essentially provides guidance (a plan) for how to carry it
out successfully. Managers use the Articulator to get access to a software process model,
instantiate it according to their local project situations, simulate and refine it in order to
create a plan for development, and realize it in their own organizational settings. When they
encounter unexpected problems during a planned development project, they can consult the
Articulator to find plausible solutions and to evolve the model based on the solution. This is
similar to the suggested use of the Callisto system used in computer manufacturing processes
[SFG85].
Software developers use the Articulator through a CASE environment [Sca88]. In this
way, the Articulator helps to coordinate their development activities according to a prescriptive
model, and serves as both an active agenda mechanism and an information exchange
center. At the same time, all the development activities are recorded into a history of development
and can be fed back to managers in order to monitor development progress. This
history will then be used by software process researchers as an empirical source of observation
on the practical character of the software process model in use. It can also be used in
validating the model or in making modifications to it.
4 The Articulator Meta-model
This section presents the Articulator meta-model stored in the knowledge base. It is an
object-based representation of a software development infrastructure that consists of the
web of resources and situations and the agent's task performance skills.
4.1 The Web of Resources and Situations
The web of resources and situations describes an infrastructure of developers, organizations,
tasks, and other resources, through which software systems are engineered. It is intended
to provide an articulate view of the many aspects of software engineering processes within a
single formalism. The theoretical scheme underlying the Articulator meta-model is the web
model of computing introduced by Kling and Scacchi [KS82]. This web model replies upon
empirical studies to make explicit a variety of connections between computing technologies,
artifacts, activities, together with their embedding social situations and organizational in-
frastructure. It also focuses equal attention to how people and their computing systems
interact, cooperate, compete, and conflict with each other in the course of their work.
In computational form, the web consists of clusters of attributed objects and relations
linking them, together with various processing mechanisms. Each of the objects is defined as
a model of a type of the components in the software process and represented as a schematic
class. These objects are further divided into several subclasses. A subclass is divided repeatedly
until an empirically observable level of detail is reached. Furthermore, every schematic
class has a set of attributes specifying its own properties, a set of relations linking to other
classes, and may have many instances to inherit its defined properties and relations with
their defined values. Several high level classes in the web of resources and situations are
shown in Figure 2. We briefly discuss its main components and their relationships here 3 .
The top level abstraction of the Articulator meta-model consists of three major objects:
resources, agents, and tasks. They are linked together through two relations: agents perform
tasks and tasks use resources. This abstraction captures our fundamental understanding of
software development processes, and in a larger sense, complex organizational activities.
A resource, as a model of general objects and products, portrays the general properties
of organizational objects and is the root of the Articulator meta-model in terms of the IS-A
relation. Accordingly, resources are objects used in tasks by agents. In the Articulator
meta-model, tasks consume and produce resources, which in turn alter the values of resource
3 The current implementation of the web represents more than 500 object classes and nearly 2000 relations.
Most object classes include 10 or so attributes. In addition, there are over 200 rules and procedures which
support behavioral simulation and query processing.
ROLE
AGENT
ACCOMMODATION (INDIVIDUAL)
NEGOTIATION (COLLECTIVE)
INDIVIDUAL PRIMARY TASK
COLLECTIVE PRIMARY TASK
ARTICULATION TASK
INDIVIDUAL AGENT
COLLECTIVE AGENT
ORGANIZATION

Figure

2: Part of The Web of Resources and Situations along the IS-A Relation
attributes. These attributes include among others name, current status, function description,
location, ownership, and usage in tasks and by agents.
An agent represents a collection of behaviors and associated attributes. An agent's behavior
emerges during the performance of tasks (including communications, accommodation,
and negotiation) given the agent's set of skills, available resources, affiliated agents, and organizational
constraints or incentives - that is, given the agent's circumstantial situation.
We use agents as a general model of developers, development teams, and organizations. We
also include development tools such as computers or software programs as a subclass of
agents.
An agent's ability to perform tasks is defined by its working load, its agenda, its selected
work style, and its working tasks together with its behavior controller (its "self"). An agent
may also have skill, experience, and knowledge of task performance. In order to perform a
task, an agent must possess the necessary resources and rights of information access. Living
in an organizational infrastructure, an agent may have affiliations with other organizations
and play different roles in different organizational situations [Gar89, KS82]. Besides these,
agents have a knowledge representation which specifies their potential behaviors, and this
behavior can also be dynamically simulated. These aspects will be discussed later.
There are several types of agents in the Articulator meta-model. Individual agents are
single entities, such as a single developer or a single machine. Collective agents, such as
teams and organizations, have infrastructures defined for a group of agents to work together,
thereby enlarging their efforts. In a collective agent, individual agents work cooperatively
or competitively to achieve their collective and individual goals. However, collective agents
can also be in conflict over how to achieve their goals, as well as over which goals are worth
achieving in what order.
A task models organizational work and development processes. Tasks represent situations
for work and processes in terms of a network of actions (i.e. operators), that agents perform
which manipulate the web of resources and situations. A task, defined as a structural hierar-
chy, is used to represent both a semi-formal plan of the actual task before it is carried out (a
prescription) and the actual execution trajectory of the task after it has been done (a descrip-
tion). Both of these include a hierarchy of task decomposition and a non-linear performance
sequence. We model two types of organizational work: primary tasks and articulation tasks
[BS87], which distinguish development-oriented tasks from coordination-oriented tasks. The
hierarchy of task decomposition may include multi-level nested decomposition, iteration and
multiple selection. Levels of specification depend on user requirements and can be modified
as requested. At the bottom level of this hierarchy are actions. Actions are basic processing
units within the processing mechanism. Further, an action links to a procedural specifica-
tion, such as a LISP function or a forward-chaining mechanism, which propagates updates
through the current state (or instance) of the web of resources and situations.
Interesting properties of a task include: assigned and authorized performers; task hierarchy
and execution ordering; schedule; duration, deadline, start time and finish time; and
resources planned to be consumed or produced by the task.
The Articulator meta-model is an open system [Hew86]. It has the following special
characteristics:
ffl The boundary of the meta-model and its interface with the outside world is deter-
minable, though not necessarily static. The meta-model, besides manipulating its own
resources, communicates with the outside world. Such communication of the Articulator
meta-model with the outside world is made possible through acquiring or providing
resources.
ffl All the resources in the web have their own life cycle. Every instance of a resource is
either created by some task, or introduced by the outside world, persists for a period
of time, and then is consumed by other tasks or exported to the outside.
ffl An agent's power to manipulate the web of resources and situations is limited and
configurable. This manipulation power includes possession or control of resources,
rights of information access, and rights of task performance. This power can be restricted
to some constraint over a period of time. On the other hand, this power may
be reconfigured at any time by authorized agents. In this way, centralized control,
distributed control, or something in between, can be modeled in the Articulator meta-
model. Also, differences in relative power among interacting agents can give rise to
conflicts in task performance. These conflicts can thus alter the task situation from
focus on performance to resolution of conflict.
ffl The web of resources and situations is a densely interrelated infrastructure. By defi-
nition, any entity in the web is associated with many other objects through relations.
With this kind of infrastructure, execution of a task can cause many implicit side effects
besides its intended behavior. For example, in a development task, a manager agent
may assign a task to a developer agent without allocating the necessary resources for
task completion. This will not cause any problem in task assignment, but will surely
delay the task execution since the developer agent will have to spend time to find the
resources required for task execution. The consequence and implication of side effects
are of interest because they resemble real situations in many ways.
Establishing a model of a software development process is made possible by using the
Articulator meta-model. Different types of software process models can be defined. For
example, a software production-process model, such as the Waterfall model [Gar89, HK89,
Ost87, Wil88] or the Automation model [Gar89] can be specified by the Articulator as
a hierarchy of software development activities and their suggested prescriptive execution
sequence. A software production-setting model can be viewed as a mixed task representation
of primary tasks and articulation tasks. As an example to be used later, we define a simple
working team here. A development team, called Team-A, belongs to company F and has
three members: Mary, Joe and Peter. The team is responsible for the task of designing the
FOO system, which consists of two component tasks: architecture design and detail design.
This small example essentially shows a setting, a development team and a task assigned to
the team. Figure 3 gives a specification of the example in SPSL, while other details, such as
resource specification, detailed process prescription will be provided later.
;; Company-F is an organization in the model.
(define-object Company-F
(is-a
;; Team-A is a team in Company-F and has two members, Mary and Joe.
(define-object Team-A
(is-a TEAM)
(team-belong-to-organization Company-F))
(define-object Mary
(is-a PEOPLE) LEGEND:
(individual-in-collective-agent lower-case words: Reserved key terms.
(task-execution-strategy Finish-one-FIFS) UPPER-CASE words: Reserved object types.
(accommodation-strategy Switching)) Upper-case starting word: Defined objects.
(define-object Joe
(is-a PEOPLE)
(individual-in-collective-agent
(task-execution-strategy Finish-one-FIFS)
(accommodation-strategy Waiting))
;; Task Design-FOO has two subtasks and is assigned to Mary and Joe.
(define-object Design-FOO
(is-a TASK-CHAIN)
(task-force-assigned-to-agent Joe Mary)
(production-task-has-component Architecture-design Detail-design))
;; Subtask Architecture-design is assigned to Mary
(define-object Architecture-design
(is-a TASK-CHAIN)
(task-force-assigned-to-agent Mary))
;; Subtask Detail-design is assigned to Mary and Joe
(define-object Detail-design
(is-a TASK-CHAIN)
(task-force-assigned-to-agent Mary Joe)
(task-force-has-predecessors Architecture-design))

Figure

3: An SPSL specification of Team-A. Five classes of objects are defined in terms of
their associated attributes. Other details are omitted for simplicity. The task specification
performed by this team is given in Fig 7.
4.2 Model of Agent's Task Performance Skill
An agent's behavior during the software process is the way it performs tasks, given its plans
and emerging circumstances. In other words, it is the trajectory of task execution that
constitutes the agent's behavior. The behavioral specification is a knowledge representation
of task performance skill [Str88]. An agent's task performance skill is represented according
to a three-level paradigm, where each level is a space specifying a particular type of knowledge
and operators to manipulate it. This three-level paradigm is similar in concept with other
multi-level problem-solving architectures, such as those in [Gen83, Ste81].
The domain space stores information and knowledge of an application domain. This is
an agent's personalized domain knowledge and is generally a subset image of the web. It is
limited by the agent's manipulation power, i.e. its possession of resources, its information
access and its rights of task performance. Operators in the domain space are actions that a
designated agent can perform within the application domain.
The task space stores operational knowledge of the manipulation and reasoning of domain
information and knowledge, i.e. the specification of tasks. In other words, operators in the
domain space are also objects in the task space. They are associated and configured to
create meaningful tasks. Other objects in the task space are entities used for the evolution
of these tasks. Operators in the task space are meta-actions that manipulate tasks in the
domain space. Also, meta-tasks (e.g. how to organize, staff and plan primary tasks) in the
task space are combinations of meta-actions.
The strategy space stores strategic knowledge which directs tasks of organizational work
and task performance, such as control structures. Objects in the strategy space, just as
in the tasks space, are meta-tasks defined in the task space and other associated entities.
Operators in the strategy space are super-meta-actions 4 , which manipulate meta-tasks in
order to determine their control structures.
In this representation, when an operator is applied to a state 5 of its space, it creates a new
state. The application of an operator is a step in the application of a task which consists
of a set of ordered operators. In terms of the three spaces, task execution is a reasoning
process for how to apply an operational specification (an object in the task space), which
is a task in the domain space, on (the state of) the domain space to infer to a new state
through continuous application of operators according to specified plans. Meta-reasoning is
a process of applying a strategic specification, (an object in the strategy space), on a state of
the task space to infer to a new state through continuous application of operators according
4 Super as in super-class, class, sub-class hierarchies.
5 A state refers to a snapshot of interrelated object-attribute values in the web. Thus a new state represents
updates of object-attribute values or relations in the current state.
to the strategic specification. Two types of task performance skill are modeled: individual
task performance and collective task performance.
Individual task performance models the agent's ability to perform tasks individually. It
is conceptualized as a combination of reasoning and meta-reasoning processes in all three
spaces. When a problem is presented, the agent first chooses a strategy to deal with it.
Meta-reasoning is then performed to create a meta-task for the problem, which in turn can
be used to produce a copying action on a problem-solving method, i.e. a task in the task
space. Next, the task is performed in the domain space to produce a resolution. When a
solution or a task for a problem is known and available, reasoning is the only process issued
to create the solution.
Collective task performance skill refers to an agent's ability to work with other agents
through interactions to get things done jointly. This collective intelligence, based on individual
task performance, supports three basic kinds of interaction: communication, synchronization
and articulation. Communication among agents is a way to exchange information.
In communication, agents exchange their knowledge about the web of resources and situations
by sending and receiving messages. Through message exchange, they can transfer their
manipulation power. They can also integrate individual efforts by combining exchanged
individual products together. Synchronization among agents arrange schedule for a group
of agents come together in order to perform collective tasks. For a collective task, all its
performers have to be present for them to be executed. On the other hand, these agents are
normally executing their own individual tasks while some of them may initialize collective
tasks at any moment. Synchronization arranges schedules for collective tasks and is responsible
for the follow-up actions when this fails. Articulation, at last, handles unexpected events
which stop normal task performance. Articulation is the way to amplify individual skill and
intelligence in a workplace [BS87, GS86, Hew86, MS89, Str88] and is discussed in [MS89].
5 Behavioral Simulation
With the specification of a software development process model and a set of agents, behavioral
simulation is defined as the agents' symbolic execution of task specification using available
resources over a period of time. The trajectory of this symbolic execution is recorded as
the predicted development history of the process and the behavior of the agents is exhibited
through their simulated task performance.
The behavioral simulation generally begins with a set of agents with their behavioral
specification defined according to their current task performance knowledge and skill. These
agents are given a set of tasks as their assignment. A set of resources is also provided along
Action AN+M
Action A2+M
Action A1+M
Time N+M
Time N Time N+1 Time N+2
Action AN
Action A2
Action

Figure

4: The Behavioral Simulation of Agents
with the tasks. Some of these resources will be consumed during the task performance.
Others will only be used and returned (i.e. reusable resources). All these objects are specified
within a single state as the initial instance of a process model as the starting position. A
state is used to model the trajectory at a different instance in time. Each state is created
by actions, and actions are linked as tasks. Figure 4 suggests a description of this behavior
simulation. In the picture, TimeN, TimeN+1 are states and lines represent actions. Actions
use some resources which are represented as circles. Overlapped circles indicate resource
requirement conflicts, which can be resolved either through synchronization or articulation
[MS89].
There are several requirements to be observed during the behavioral simulation:
1. The task assignments are stable, if not otherwise explicitly changed. This is to say
that all the agents must finish their assigned tasks before the simulation is done.
2. At any time instance, an agent cannot perform two actions simultaneously. But, an
agent may perform several tasks concurrently during a period.
3. At any time instance, an agent can not work on more tasks than its available supply
of resources allow
4. The preconditions associated with in an action must be satisfied before it can be
executed. These preconditions include resource requirements, partial ordering of exe-
cution, and execution authorization.
;; run the current action. The rule selects the agent, its agenda, and
;; its current action as the conditions. It then starts execution
(p Run-action :context t
-instance !? ()
-schema-name !agent?
-controller-goal Controller-action-checked
-agent-has-agenda !agenda?
(AGENDA
-instance !? ()
-schema-name !agenda?
-current-slot !c-slot?
-time-slot-allocation !slots?
(ACTION
-instance !? ()
-schema-name !action?
-schema-name (select-current-action !? !slots? !c-slot?)
-?
(format t "Start to execute action ~A~&" $!action?)
(new-value $!agent? 'controller-parameter1 (current-p-l $!slots? $!c-slot?))
(new-value $!agent? 'controller-goal 'run-action))

Figure

5: An SPSL rule for an individual-agent action
The behavioral simulation starts from the initial state and simulates the agents' activities
performing their assigned tasks. Simulation of task performance is accomplished by
# of Agents # of Tasks # of Actions Agent-Task Agent-Action Communication
One One Many 1
One Many Many 1 - Scheduling for One Agent
Many Many Many 1 - N 1 Communication among the Agents
Many One Many Synchronous Combination of Results
Many One Many M - 1 M - 1 Synchronization of Performance
Many Many Many M - N M - 1 All the Above

Figure

Types of Task Performance by Agents
execution of the task specification in top-down fashion. The higher levels of a task hierarchy
provide information about work assignment and resource allocation. The lower levels
of the task hierarchy provides links to procedural definitions which are executable in order
to create new states. At each simulation step, symbolic execution is done by first propagating
necessary information from high levels to lower ones, checking preconditions of an
action, and then invoking the associated procedural definition to propagate changes. All the
changes from different agents are then combined to form a new state of the software process
model. Two things condition the new state and the task execution. First each agent selects
the executing action out of its own choice. The selected action is among its current work
assignments. The choice can be influenced but not determined by outsiders. Second, there
are probably conflicts in resource requirements and the changes which need to be solved
through articulation [MS89]. Part of the symbolic execution of an action is shown in Figure
5 where the rule gets an agent and its agenda, finds its current action, and starts to execute
the action symbolically.
The final result of the behavioral simulation is a trajectory over a period of time, in
which every action of the tasks is performed once by a subset of the agents at a time
instant. These trajectories can be made persistent and evolvable. Such trajectories can be
subsequently studied according to different criteria in order to analyze information about
task performance, such as the agents' behavior during execution, their productivity, resource
utilization, alternative "what-if" scenarios, and other interesting properties. However, the
task execution is not guaranteed to finish successfully. Problems may rise due to unexpected
events that need to be articulated. Articulation of task performance also affects the above
criteria and their consequences can be tracked as well [MS89].
Based on the Articulator meta-model, many types of agents and tasks can be assigned
to a software development process. This means that behavioral simulation can be divided
into several types according to the number of involved agents, tasks, and the communication
patterns between the agents shown in Figure 6.
Let us consider our earlier example of Team-A (Figure again. The example is input
into the Articulator and then simulated by the behavior simulator. In the example, there
are two agents performing task "Design FOO". The task specification and work assignment
are shown in Figure 7. The resource requirements of Design-FOO are also given, but we can
only show a single requirement here as in Figure 8. In addition, Mary has another task, and
thus sends a message to Peter, another member in Company F, for assistance.
Due to space limits, we only present a summary report in Figure 9 of the simulation here,
which is obtained from the trajectory history and provides condensed information about the
simulation. Then we discuss the types of behavior demonstrated in this example.
This behavioral simulation involves multiple agents performing a single task that requires
the combination of each agent's task results. Initially, it has three agents and two tasks.
However, our example focuses on one which is performed by two agents in combination.
During the performance, a task-action ordering emerges. When either of two actions can be
executed at the same time, an agent selects one randomly.
The agents communicate twice in the simulation. At time 3, Mary sends a work assignment
to Joe, who reads the message at time 5 and begins to perform the task at time 7.
Mary sends a file to Peter at time 9, who reads it at time 12.
Lack of resources occurs twice, and both are resolved through accommodation. At time 7,
when Joe tries to start his task execution, the Valid-document-spec, a document created by
action Validating-architecture-design, does not exist at the moment. Since Joe chooses
a waiting strategy to accommodate (Figure 3), he simply waits for the resource. Fortunately,
the resource becomes available at time 8, so he continues. At time 8, Mary encounters the
same problem. She prefers to switch to another task as her accommodation strategy, so she
selects to perform another task: Send-file-to-peter and resume the original task at time
10, when the resource is available.
The task execution completes in eleven time steps by two agents. In total, there are 22
time steps from two agents of which 12 are used to perform the task, 1 for
waiting and 1 for switching. The other time steps ("slack time")
could be utilized for other task performance if needed.
6 The Query Mechanism
The query mechanism accepts user queries to retrieve information from the the Articulator
meta-model, the software process models and their instances.
The query functions are built in bottom-up fashion. A set of atomic functions, implemented
as forward-chaining rules, are used to get very basic information about attributes
Detailed Design
Architectural Design
Design-FOO
Task has component
Task has successor
LEGEND
A3
ACTIONS:
A1: Establish system structure A2: Decompose system
A3: Establish subsystem interface A4: Inform Joe about the task
A5: Document architecture design A6: Validate architecture design
A7: Design module structure A8: Develop data representation
A9: Detail subsystem interface A10: Design system interface

Figure

7: Task Decomposition of Design-FOO. The unshaded actions (indicated by circles)
are assigned to Mary and the shaded actions are assigned to Joe.
;; System-data-structure-spec is a resource manipulated in Design-FOO.
;; It is created by Developing-data-representation, and used in
;; Defining-algorithm and Designing-system-interface.
(define-object System-data-structure-spec
(is-a DOCUMENT)

Figure

8: A Resource Specification by SPSL
and relations. They are atomic because they only retrieve attributes and relations. Such a
set of rules is used to find if a designated relation exists between two objects. Higher level
functions involve the knowledge representation and provide information about the represen-
tation. Users are encouraged to develop their own queries using the facilities we provide.
The main concern in the query mechanism is to provide a set of functionally-complete basic
facilities.
There are four types of queries supported in the query mechanism: meta-knowledge
queries, information queries, history queries and what-if queries.
A meta-knowledge query provides the definition of an entity and its related terminology
in the Articulator. It is based on the information given when an object is defined, which
is stored as meta knowledge. An example definition of meta knowledge appears in Figure
10. This function is intended to help new users to understand the Articulator meta-model.
Users can also provide their own meta-knowledge for models they defined, in order to help
guide other users' interactions with a given model. A meta-knowledge query is in form of
q-WHAT. For example, Figure 10 also lists a meta-knowledge query about company F and the
question is shown in the figure.
An information query provides information about either a state of a software process
model or the model itself. It is generally concerned with resource values and configurations.
Typical questions answered include "Is Peter a member of Team-A at time 1?", "What are
the relations linking Peter and Mary now?", etc. An information query has several basic
functions for this kind of deductive retrieval. For example, q-is checks the existence of
an entity in the status, and q-relation finds the relations which link two given entities.
6 DOCUMENT-ARCHITECTURE-DESIGN IDLE IDLE
9 SEND-FILE-TO-PETER DEVELOP-DATA-STRUCTURE IDLE

Figure

9: Summary of Simulation Result
Through the use of an information query, every value and every relation within a state can
be retrieved without difficulty.
More complicated queries have been implemented as examples of query building using
these basic functions. For example, q-follower and q-predecessor are used to find follower
actions and predecessor actions of a given action along relation
task-force-has-follower. These two queries are useful for users to check the configuration
of the tasks they perform. They are implemented by the q-relation query using
task-force-has-follower as the given relation. Another example is to get all component
modules of a given software project, implemented as q-soft-configuration. Many such
queries with specific requirements can be built in the same manner. In Figure 11, we provide
some information queries about our simple model of Company F.
A history query traverses a trajectory of states created in a simulation, collects a record of
changes on specified entities, then summarizes them to give clear and condensed information
about these changes. Typical information provided in history queries includes the activities
performed by the agents in the simulation period and the resources consumed or produced
by agents or teams. Other specific queries may ask about the consequence of a particular
action, a value change, or an inserted relation.
Implementation of the history query is based on information queries and the instantiation
manager. The former provides facilities to retrieve information within a state, while the latter
gives the capability to traverse within the state trajectory. Also a history query has a facility
to sum up gathered information. The simulation result presented in Figure 9 comes from a
;; Definition of meta-knowledge schema in SPSL with definitions for explanation.
(define-object Meta-knowledge
(is-a SCHEMA)
(methods-and-procedures)
;; Definition of meta knowledge for RESOURCE
(define-object Meta-resource
(is-a META-KNOWLEDGE)
(definition "RESOURCE is the basic entity in KB. It provides basic
descriptions about entities in the meta-model. Every object
must be a class of RESOURCE or an instance of RESOURCE.")
(methods-and-procedures "A resource can be created, used, and consumed")
(reason-or-explanation NA)
(literature-available "mi"))
(attach-meta-schema 'RESOURCE 'Meta-resource)
;; Meta-knowledge query - WHAT question:
(:RELATED ?ENTITY IS-A RESOURCE)
(BIND ?DEFINITION (GET-VALUE (GET-META-SCHEMA ?ENTITY) 'DEFINITION)) !)
(= ?DEFINITION "There is no such an entity in KB") ! fail)
;; Example of use of WHAT question: what is Company-F?
(q-WHAT Company-F ?DEFINITION)
"Company-F is a software vendor. It develops software on SUN systems.
Currently it has three members: Mary, Joe and Peter."

Figure

10: Meta-knowledge in SPSL and Its Queries
;; IS question: Is Mary in the meta-model?
(q-is Mary)
true
;; RELATION question: How are Mary and Joe related?
(q-RELATION Mary Joe)
Mary individual-in-collective-agent Company-F collective-agent-has-member Joe.
;; It means Mary and Joe are both in Company-F
;; FOLLOWER question: What are the followers of Develop-data-representation?
(q-follower Develop-data-representation ?what)
(Design-system-interface

Figure

11: Examples of Information Query
history query.
A what-if query includes a combination of simulation and history queries. It starts from
a given state, or a modification of a state in the middle of a sequence trajectory, and calls
the behavior simulator to simulate the given updated scenario. When the simulation is done,
a history query is activated to gather required information. What-if queries are designed to
facilitate testing of the hypothesis scenario and handling of unexpected events.
7 Conclusion
Within the Articulator project, we propose some novel contributions to the study of software
engineering processes using a knowledge engineering environment. We create a tractable
open-system model of software processes and resource infrastructures that are articulated by
agents working in development settings. We explore relationships among the components,
such as software processes, development resources and developers, within the model and
their impact on the software development products, processes, and workplace settings under
study. We also provide formalisms to represent task performance skill. We present a meta-model
of software processes which is suitable for describing software process models. All
these contributions are further enhanced through the simulation of the dynamics of software
process models as a basis for querying the state of values in the represented model, the
simulated trajectory and the recorded process history. As the Articulator becomes more
complete, we hope to provide a framework to further assist the interactive empirical study
of large scale software development projects.



--R

Understanding Software Maintenance Work.
Work Structures and Shifts: An Empirical Analysis of Software Specification Teamwork.
Carnegie Group Inc.
A Field Study of the Software Design Process for Large Systems.
On Building Software Process Model Under the Lamppost.
Cooperation Through Communication in a Distributed Problem Solving Network.
Information Management in Software Engineering
An Overview of Meta-level Architecture
Analyzing Due Process in the Workplace.
Offices Are Open Systems.
Software Process Modeling: Principles of Entity Process Models.


The Web of Computing: Computer Technology as Social Organization.
Negotiation: A Collective Problem-Solving Approach
Software Processes are Software Too.
The USC System Factory Project.
Representation of activity knowledge for project management.
MOLGEN Part 2: Planning and Meta-Planning
The Articulation of Project Work: An Organizational Process.
This is IT: A Meta-Model of the Software Process
Software Process Modeling: A Behavioral Approach.
--TR
This is IT: a metamodel of the software process
Understanding software maintenance work
Software processes are software too
On building software process models under the lamppost
A field study of the software design process for large systems
Breakdowns and processes during the early activities of software design by professionals
A methodology for studying software design teams: an investigation of conflict behaviors in the requirements definition phase
Software process modeling: a behavioral approach
A plan-based intelligent assistant that supports the software development
Work structures and shifts
Software process modeling
The integration of computing and routine work
Analyzing due process in the workplace
Offices are open systems
Intelligent Assistance for Software Development and Maintenance
ISHYS

--CTR
Peiwei Mi , Walt Scacchi, Process Integration in CASE Environments, IEEE Software, v.9 n.2, p.45-53, March 1992
C. Bellettini , E. Damiani , M. G. Fugini, User opinions and rewards in a reuse-based development system, Proceedings of the 1999 symposium on Software reusability, p.151-158, May 21-23, 1999, Los Angeles, California, United States
Pankaj K. Garg , Peiwei Mi , Thuan Pham , Walt Scacchi , Gary Thunquest, The SMART approach for software process engineering, Proceedings of the 16th international conference on Software engineering, p.341-350, May 16-21, 1994, Sorrento, Italy
Markku Oivo , Victor R. Basili, Representing Software Engineering Models: The TAME Goal Oriented Approach, IEEE Transactions on Software Engineering, v.18 n.10, p.886-898, October 1992
Darren C. Atkinson , Daniel C. Weeks , John Noll, Tool support for iterative software process modeling, Information and Software Technology, v.49 n.5, p.493-514, May, 2007
Kari Rnkk , Yvonne Dittrich , Dave Randall, When Plans do not Work Out: How Plans are Used in Software Development Projects, Computer Supported Cooperative Work, v.14 n.5, p.433-468, October   2005
Christopher M. Lott, Process and measurement support in SEEs, ACM SIGSOFT Software Engineering Notes, v.18 n.4, p.83-93, Oct. 1993
Nazim H. Madhavji , Kamel Toubache , Ed Lynch, The IBM-McGill project on software process, Proceedings of the 1991 conference of the Centre for Advanced Studies on Collaborative research, October 28-30, 1991, Toronto, Ontario, Canada
David Raffo, Evaluating the impact of process improvements quantitatively using process modeling, Proceedings of the 1993 conference of the Centre for Advanced Studies on Collaborative research: software engineering, October 24-28, 1993, Toronto, Ontario, Canada
G. Fugini , C. Bellettini, Corrigenda: a hierarchy-aware approach to faceted classification of object-oriented components, ACM Transactions on Software Engineering and Methodology (TOSEM), v.8 n.4, p.425-472, Oct. 1999
G. Fugini , C. Bellettini, A hierarchy-aware approach to faceted classification of objected-oriented components, ACM Transactions on Software Engineering and Methodology (TOSEM), v.8 n.3, p.215-262, July 1999
Maria Letizia Jaccheri , Gian Pietro Picco , Patricia Lago, Eliciting software process models with the
Vincenzo Ambriola , Reidar Conradi , Alfonso Fuggetta, Assessing process-centered software engineering environments, ACM Transactions on Software Engineering and Methodology (TOSEM), v.6 n.3, p.283-328, July 1997
knowledge based systems;knowledge-based environment;statics;software process behavior simulator;articulator;knowledge base querying mechanism;modelling;prototype computational environment;simulating software engineering processes;design;dynamics;representation schemes;modeling;programming environments;knowledge metamodel;software engineering