GSC Associates Proprietary and Confidential
UML and Human Performance Modeling
GSC Associates
2727 Xanthia Court
Denver, Colorado 80238-2611
+1-303-388-6355
Abstract
The purpose of this white paper is to investigate the potential for interchanging
information between ARL’s IMPRINT tool and UML 2.0. Because there appears to have
been no application of UML to a similar human performance modeling task in the past,
this paper first describes past research applying UML in two areas related to the one
under consideration: performance modeling (of entities other than humans) and human
action/interface specification. Next, short summaries of relevant aspects of UML and of
IMPRINT are given. These relevant aspects are then used to form the basis for an
approach to defining a UML 2.0 Profile for Human Performance Modeling. The major
innovation proposed here is using UML to model functions performed by humans, not
just functions performed by hardware and software. This approach may be expanded to
be broader in scope than just defining a relationship between UML and IMPRINT. This
is important because developing a more general profile for using UML in the field of
Human Performance Modeling (if not all of Cognitive Engineering) will be necessary to
gain wide enough acceptance to be supported by commercial UML products.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Table of Contents
1
Introduction ................................................................................................................. 3
2
Related research .......................................................................................................... 3
3
2.1
Introduction ......................................................................................................... 3
2.2
UML in performance modeling and related areas .............................................. 3
2.3
UML applied to human action and interface specification ................................. 9
2.3.1
Introduction to human cognitive engineering ............................................. 9
2.3.2
UML applied to human action and interface specification ....................... 10
Technical approach ................................................................................................... 12
3.1
Introduction ....................................................................................................... 12
3.2
Background information on IMPRINT ............................................................. 12
3.3
Background information on UML .................................................................... 13
3.3.1
References ..................................................Error! Bookmark not defined.
3.3.2
Quick summary of UML 2.0 ..................................................................... 14
3.3.3
Extending UML ........................................................................................ 16
3.4
4
Getting the approach accepted by the community .................................................... 20
4.1
Introduction ....................................................................................................... 20
4.2
The OMG process ............................................................................................. 20
4.2.1
Introduction ............................................................................................... 20
4.2.2
Precursor steps .......................................................................................... 21
4.2.3
Overview of the OMG process ................................................................. 21
4.3
5
UML and human performance modeling .......................................................... 17
Building support................................................................................................ 24
Next steps .................................................................................................................. 24
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
1 Introduction
This white paper investigates the potential for interchanging information between ARL’s
IMPRINT tool and UML 2.0. It develops a set of concepts that can be used for this
purpose and describes a potential UML 2.0 Profile for Human Performance Modeling
(see 3.4). It summarizes the relevant past research that applied UML in two areas related
to the one under consideration:
1. modeling (of entities other than humans) and
2. human action/interface specification (see 2.2 and 2.3).
Next, sections 3.2 and 3.3 give short summaries of the relevant aspects of UML and of
IMPRINT. These relevant aspects are then used to form the basis for the approach
described in 3.4 to defining a UML 2.0 Profile for Human Performance Modeling. This
approach may be expanded to be broader in scope than just defining a relationship
between UML and IMPRINT. This is important because developing a more general
profile for using UML in the field of Human Performance Modeling (if not all of
Cognitive Engineering) will be necessary to gain wide enough acceptance to be supported
by commercial UML products (see section 4).
The major innovation proposed here is using UML to model functions performed by
humans, not just functions performed by hardware and software. Traditional uses of
UML consider human activity to be external to the system being described.
2 Related research
2.1 Introduction
This section provides background data in two important areas. The first is the use of
UML in general (i.e., not human-specific) performance modeling and closely related
areas. The reason for exploring this area is that techniques used there (such as probability
distribution parameter specification, time specification, and decision/branching logic) are
expected to be portable to Human Performance Modeling. The second area addressed in
this section is the use of UML in human activity and interface specification. This includes
the use of UML models to describe the activities of humans as elements of an overall
model.
2.2 UML in performance modeling and related areas
Cortellessa, Singh, and Cukic [13] describe how non-functional requirements such as
reliability can be specified as part of the UML modeling process. They accomplished this
by associating reliability attributes with both component and connector elements (classes)
of UML diagrams. They then used familiar Bayesian inference techniques to infer an
overall reliability by composing the reliabilities of individual elements in a UML
Sequence diagram. This suggests the possibility that composite human performance data
might be captured and composite performance might be computed by similar techniques.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Fernandes, Machado, and Santos [14] show how UML can be used in industrial projects
to model embedded control systems that were previously modeled by Petri Nets. They
concluded that UML was an adequate unified representation language for industrial
projects, since it was:

intuitive for non-technical people,

it covered the main views of a system,

it was independent of the platform and

it was a standard.
This research suggests that aspects of human performance modeling traditionally
addressed by Petri Net models might also be addressed by UML models.
Alsaadi [16] describes how performance analysis may be based on information captured
with UML diagrams. In their approach they used the Collaboration diagram, Use Case
diagram, Deployment diagram, and the Sequence diagram facilities of earlier versions of
UML. By considering object instances that might be either permanent or transient in
nature as well as the multiplicity of relationships between object instances, they first
transformed the basic UML diagrams into diagrams more consistent with standard
queuing network (QN) analysis. They then related functional elements to the hardware
and software elements defined in UML Deployment diagrams. Unfortunately, they never
explicitly describe how the parameters of a QN are associated with their models using
standard UML concepts.
Hoeben [17] similarly addresses how UML models often lack some of the detail required
for performance estimation and shows how such information can be added. Similar to
Alsaadi [16] he uses several different UML diagram types to make performance
estimates. Figure 1 from his paper, reproduced below as Figure 1 in this paper, shows the
diagram types that he uses:
Figure 1. UML diagram types used to produce performance estimates
Hoeben is more specific than Alsaadi about how additional data needed for performance
prediction is obtained. In particular, the number of instances of various objects in the
deployment (such as communication links and servers) is explicitly collected and used.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Lindemann [18] proposes extensions to UML State diagrams and Activity diagrams to
allow the association of events with exponentially distributed and deterministic delays.
Rather than trying to understand and use UML extension mechanisms to capture this
information, his approach exports UML State diagrams and Activity diagrams from a
UML tool into text files. The information is then translated into a generalized stochastic
Petri Net (GSPN) and the performance data is entered using a Petri Net modeling tool.
Balsamo and Marzolla [20] use UML Use Case, Activity and Deployment diagrams
together with the UML extension mechanisms of UML Version 1.5 to drive a processoriented simulation model of an UML software specification. The (now obsolete) tagged
value extension mechanism is used to associate simulation parameters with UML
diagrams. (In UML 2.0. meta-attributes would be used instead (see 3.3)). This is
illustrated in their Figure 1, reproduced as Figure 2 below:
Figure 2. Methodology for simulation modeling of software systems
It is also useful to look at their Figure 3, reproduced as Figure 3 below, which uses the
“comment style” (the yellow boxes in the figure) of showing the values of tagged values
associated with activities within a UML Activity diagram. Compare this with Figure 9
that shows the approach proposed in the present paper.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Figure 3. Example web video simulation example
Balsamo and Marzolla note that:
“Use Case diagrams provide information about the workloads driving the system,
Activity diagrams show the internal dynamics of the system, and Deployment
diagrams show the mapping between software entities (processing steps) and
hardware entities (processors on which the software executes).”
What is striking both in their work and other typical uses of UML elsewhere is that
“processing” is normally thought in UML of as something that software - not humans does and that only the most general notion of “workload” for the system (not the user!) is
considered. Nothing limits the use of UML to such a narrow view.
Wieringa [21] provides a reasonably complete survey of structured and object-oriented
software specification methods and techniques, including UML 1.1. The paper is useful
because it provides an abstract look at what is common among many different historical
techniques.
Bernardi, Donatelli, and Merseguer [22] use UML Sequence diagrams and State Machine
diagrams for the validation and the performance evaluation of systems. Similarly to
Lindemann [18], they use GSPNs and propose an automatic translation of State Machine
diagrams and Sequence Diagrams into GSPNs. This work predates the development of
UML 2.0, which is capable of being at least semi-formally specified by defining pre- and
post-conditions and semantics using Object Constraint Language (OCL) [5], and so
echoes the familiar refrain about UML versions 1.5 and earlier:
“UML lacks a formal semantics and hence it is not possible to apply, directly,
mathematical techniques on UML models for system validation.”
This paper focus of formal semantics and is foundationally sound. It defines a wellspecified formal translation from UML State Machine diagrams to GSPNs. Unfortunately
is focuses on only State Machine diagrams and does not address how any of the other 15
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
diagram types on UML 2.0 might be formally translated, nor does it consider the use of
UML extension mechanisms to capture any needed attributes.
Gu and Petriu [24] develop XSLT transformations from UML models to LQN
performance models. This paper extends a graph grammar-based transformation of a
UML design model into a Layered Queueing Network (LQN) performance model
previously proposed by the authors. This earlier transformation was implemented in two
ways: first by using an existing graph-rewriting tool and secondly through an ad-hoc
graph transformation implemented in Java. The new approach uses UML extension
mechanisms as illustrated by Figure 6 from their paper, reproduced as Figure 4 below
(which uses the UML comment mechanism to show the values of tagged values (now
obsolete and replaced by meta-attributes in UML 2.0)) associated with activities:
Figure 4. UML Activity diagram with performance annotations
Martin, Lavagno, and Louis-Guerin [25] propose a UML profile called “Embedded
UML”. It is based on the POLIS approach to hardware-software co-design [42]. This
paper provides only a very high-level description with few details. What is interesting is
that trades similar to those that are made in hardware-software co-design also apply in
human-automated processing co-design, suggesting a general approach where the
functionality could be described generically and then trade studies conducted to
determine the best human, automated, or blended approach.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Finally, the UML Profile for Schedulability, Performance, and Time Specification,
Version 1.1 [7] developed by the Object Management Group is very relevant to the
present effort. Although as presently defined it uses UML 1.5, it is presently being
redefined to align it with the concepts in UML 2.0 [8]. The purpose of this profile as
stated in the document is:
“In March of 1999, the Analysis and Design Platform Task Force of the OMG
issued a request for proposal (RFP) asking for a UML profile for "schedulability,
performance and time".
The RFP called for "proposals for a UML profile that defines standard paradigms
of use for modeling of time-, schedulability-, and performance-related aspects of
real-time systems" that would:

Enable the construction of models that could be used to make quantitative
predictions regarding these characteristics.

Facilitate communication of design intent between developers in a
standard way.

Enable inter operability between various analysis and design tools.
This is just the first part of a larger initiative created by the Real-Time Analysis
and Design Work Group to develop a comprehensive solution to the modeling of
real-time systems. Subsequent parts are expected to deal with more general
quality of service aspects (i.e., beyond time-related issues, including availability,
reliability, etc.) and also with complex real-time systems.”
Despite the commonly held belief that UML was not suitable for purposes such as
performance modeling, the development of this profile demonstrated otherwise. The
profile summarizes the situation this way::
“Since the adoption of the UML standard, it has been used in a large
number of time-critical and resource-critical systems. (A significant
number of these can be found in the various books, papers, and reports
listed in the Bibliography at the end of this specification.) Based on this
experience, a consensus has emerged that, while a useful tool, UML is
lacking in some key areas that are of particular concern to real-time
system designers and developers. In particular, it was noticed that the
lack of a quantifiable notion of time and resources was an impediment
to its broader use in the real-time and embedded domain.
Fortunately, and contrary to an often expressed opinion, it was
discovered that UML had all the requisite mechanisms for addressing
these issues, in particular through its extensibility faculties. This made
the job much easier, since it was unnecessary to add new fundamental
modeling concepts to UML – so-called “heavyweight” extensions.
Consequently, the job consisted of defining a standard way of using
these capabilities to represent concepts and practices from the real-time
domain.”
One reference that describes such alleged shortcomings of UML is Martin [11].
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
The profile defines a general approach to modeling resources, time, schedulability, and
performance. A key concept is that of Quality of Service (QoS) offered by resources and
requested by services. The profile is based on UML 1.5 and uses its extension
mechanisms: Stereotypes (of classes) and tagged values (associated with classes).
Besides various representations for time-related objects, tagged values in the profile
represent the parameters of various statistical distributions (normal, exponential,
Bernoulli, uniform, binomial, etc.). The general approach applies not only to the models
in IMPRINT, but to other models used in related areas of cognitive and behavioral
engineering.
2.3 UML applied to human action and interface specification
2.3.1
Introduction to human cognitive engineering
It is important to understand the nature of the IMPRINT tool and how it fits into the
broader subject of cognitive engineering. As discussed later in this paper, getting an
approach to data capture (that is, a profile of UML 2.0) accepted by a larger community
than just users of one tool will be necessary before vendors will build support for such a
profile into their products. This paper relies on the description of the field and the lists of
tools developed by Mitre Corporation and documented in the paper “A Survey of
Cognitive Engineering Methods and Uses” for this purpose [44]. As described in that
reference:
“Cognitive engineering is an interdisciplinary approach to the development of
principles, methods, tools, and techniques to guide the design of computerized
systems intended to support human performance. The basic unit of analysis in
cognitive engineering is a cognitive system, composed of human and machine
agents in a work domain that is delineated by roles, work and communication
norms, artifacts, and procedures. Cognitive engineering draws on the disciplines
of cognitive psychology, cognitive science, computer science, human-computer
interaction, human factors, and related fields. The goal of cognitive engineering is
to develop systems that are easy to learn, easy to use, and result in improved
human-computer system performance.”
The Mitre paper goes on to give a long list of tools, theories and methods in each of
several categories:
1. Cognitive Task Analysis
2. Knowledge Elicitation
3. Computational Cognitive Modeling
4. Task Analysis
5. Computational Task Simulation
6. System Evaluation Methods
7. Theoretical Frameworks
8. Human Reliability Analysis
9. Cognitively-Oriented Methods
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
10. System-Oriented Methods
IMPRINT is categorized in the Mitre taxonomy as a Computational Task Simulation tool
along with the following additional tools:
1. CART (Combat Automation Requirements Testbed)
2. Micro Saint (System Analysis of Integrated Network of Tasks)
3. WinCrew
4. IPME (Integrated Performance Modeling Environment)
The importance of developing a UML profile that can also address the data capture needs
of these other products as well as products and technologies in other categories cannot be
overemphasized.
2.3.2
UML applied to human action and interface specification
Heumann [11] discusses how the Rational Unified Process (RUP) recognizes how Use
Case diagrams describe the way a system will be used, but they don't specify the system
user interface. RUP supplements Use Case diagrams with user experience (UX)
storyboards, based on the use cases, that add the process and techniques necessary to
design and build a user interface. While the approach is more oriented towards capturing
the data needed to develop user interface screens, it does suggest that a similar approach
might work with other information related to a user interface, such as human performance
requirements.
Agarwal and Sinha [12] describe the difficulties encountered by developers in defining
the behavioral aspects of a system. This and similar research was applied in the
development of UML 2.0 where two different sets of diagrams are provided - one set
addressing system structure and another addressing system behavior [2].
Amyot and Mussbacher [15] as well as Billard [23] describe the concept of Use Case
Maps (UCMs). UCMs are used as a visual notation for describing causal relationships
between responsibilities of one or more Use Case diagrams. They show how UCMs
bridge the gap between requirements and design by combining behavior and structure in
one view and by flexibly allocating scenario responsibilities to architectural components.
We determined that UML 2.0 provided an equivalent and standard way of interrelating
different UML diagrams, making UCMs no longer needed as an additional concept.
Biddle and Tempero [19] describe the concept of an Essential Use Case (diagram), which
is basically a Use Case diagram that is free of design implications. The two examples
from their paper shown as Figure 5 illustrate the difference between a use case with many
implied design decisions and one that is design free.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Figure 5 Essential vs. design-biased use case examples
One implication of the work of Biddle and Tempero is that design independent diagrams
(not only Use Case but also Activity) could be defined first. These diagrams could then
be refined in different ways to define specific design choices whose human performance
could then be compared.
Arnowitz, Fijma, and Verlinden [26] describe task layer maps used to communicate a
task analysis. Based on our analysis, UML 2.0 can be used to provide similar design
documentation. The authors do not consider this possibility.
Paternò [27] considers a cognitive engineering technique, ConcurTaskTrees (CCT), and
UML: how to relate them. While they recognize that “UML is the most successful modelbased approach to support software development” they incorrectly claim that “during the
evolution of UML little attention has been paid to supporting the user interfaces design
and development.” The paper also claims that “ConcurTaskTrees is one of the most
widely used notations for task modelling” however the Mitre taxonomy [40] fails to
mention this technique. While providing no details of how it might be accomplished, the
paper does suggest that:
“Representing elements and operators of a CTT model by an existing UML
notation. For example, considering a CTT model as a forest of task trees, where
CTT operands are nodes and operators are horizontal directed arcs between
sibling nodes, it can be represented as UML Class Diagrams. Specific UML class
and association stereotypes, tagged values and constraints can be defined to factor
out and better represent properties and constraints of CTT elements.”
Paris, Lu, and Vander Linden [28] provide a summary of task model editors and
extraction tools. They state:
“For example, UML is primarily a system modeling language, but it does include
some task-oriented information, primarily in the use-case diagrams and
potentially in the scenario diagrams and state diagrams. It also includes some
domain knowledge in its class diagrams. It is thus possible to extract task
modeling knowledge from these diagrams.”
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Their analysis completely neglects the fact that UML can easily be used to capture and
describe task models using the techniques described in the present white paper (see 3.4).
Instead, they focus only on trying to extract task model data from UML models
developed for other purposes.
3 Technical approach
3.1 Introduction
This section begins by briefly summarizing important, applicable characteristics and
capabilities of both the IMPRINT modeling tool (see 3.2) and of UML 2.0 (see 3.3) . This
information is then applied to define an approach to human performance modeling using
UML (see 3.4).
3.2 Background information on IMPRINT
The Improved Performance Research Integration Tool (IMPRINT) was developed for the
Army Research Laboratory (ARL) Human Research and Engineering Directorate
(HRED). IMPRINT is government-owned and consists of a set of automated aids to assist
analysts in conducting human performance analyses. IMPRINT provides the means for
estimating manpower, personnel, and training (MPT) requirements and constraints for new
weapon systems very early in the acquisition process [34]. For purposes of this white
paper, it is necessary to understand only a few of the features of IMPRINT. These may be
summarized as follows:

IMPRINT allows an analyst to evaluate a mission.

Missions are described by hierarchical refinement: missions are first into a set of
functions and then each function may be refined into a set of tasks.

While a large amount of information may be specified for each task, the following
items entered in the Task Information Time & Accuracy Tab in IMPRINT are the
most essential:
o Requirements

Time Standard: This time standard is the maximum acceptable time
by which the mission must be performed in order to be considered a
success.

Accuracy Standard


Accuracy Measure: The selection of one accuracy measure
(e.g. “Percent Steps Correct”) from a list of alternatives.
Criterion: The percentage of the time that the task must meet the time
and accuracy standards
o Estimated performance

Mean Time

Time Standard Deviation
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential


Time Distribution: The selection of one distribution (e.g., Normal)
from a list of distribution types.

Mean Accuracy

Accuracy Standard Deviation
The flow of events functions is specified by defining sequential connectivity
among tasks to form a network that may include branching logic. Branches may
be one of several types including: parallel branches, probabilistic branches, and
repeating branches. Within each function, the connectivity is similarly defined among
the tasks that comprise the function.
Based on the above list of concepts, if UML structural and/or behavioral modeling (see
can capture the above information in one or more of its diagram types (see 3.3.2), then it
should be possible to develop the mapping that this white paper is investigating. This
mapping is addressed in detail in 3.4.
3.3 Background information on UML
3.3.1
The definition of UML
UML 2.0 (the latest version) is formally defined by a set of specifications developed by
the Object Management Group (OMG). These specifications are:
1. Unified Modeling Language: Superstructure, version 2.0 [2]: The UML 2.0:
Superstructure defines the user level constructs required for UML 2.0.
2. Unified Modeling Language: Diagram Interchange, version 2.0 [3]: UML
Diagram Interchange is an XML-based mechanism for describing XML models in
a tool-independent manner. It replaces the previous XMI specification.
3. Unified Modeling Language (UML) Specification: Infrastructure, version 2.0 [4]:
The UML 2.0: Infrastructure defines the foundational language constructs
required for UML 2.0.
4. OCL 2.0 [5]: Object Constraint Language (OCL) is a formal language used to
describe expressions on UML models. Proper use of OCL is key to enabling
automatic translation of UML models into executable software
The previous, now obsolete, version of UML is version 1.5 [1]. UML 1.5 still has a
market presence as vendors and open-source projects update their code to UML 2.0. In
addition, in section 2.2 we describe how the UML Profile for Schedulability,
Performance, and Time Specification, Version 1.1 [7] applies UML to a problem space
very similar to human performance modeling.
Providing a complete description of UML 2.0 is beyond the scope of this white paper.,
Instead only a brief introduction is provided and the focus is shifted to look at the very
few features of UML 2.0 that are required in the suggested approach to profile
development. For further reading, there are two excellent tutorial style introductions to
the features of UML 2.0:
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
1. A paper by Bran Selic titled Unified Modeling Language version 2.0 [37]
provides a quick overview of UML 2.0 and especially how UML 2.0 differs from
previous versions of UML.
2. Two tutorials authored by Sparx Systems, a UML Tool vendor, provide very
readable introductions to UML 1.x [38] and UML 2.0 [39].
3.3.2
Quick summary of UML 2.0
The UML specification [1] describes UML as follows:
“The Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a software-intensive
system. The UML offers a standard way to write a system's blueprints, including
conceptual things such as business processes and system functions as well as
concrete things such as programming language statements, database schemas, and
reusable software components.”
UML 2.0 models visually described using one or more of 13 basic diagram types [39].
These diagrams are divided into two general sets: Structural Modeling Diagrams and
Behavioral Modeling Diagrams. Each of the diagram types is briefly described below:
Structural Modeling Diagrams
1. Structure diagrams define the static architecture of a model. They are used to
model the 'things' that make up a model - the classes, objects, interfaces and
physical components. In addition they are used to model the relationships and
dependencies between elements.
2. Package diagrams are used to divide the model into logical containers or
'packages' and describe the interactions between them at a high level
3. Class or Structural diagrams define the basic building blocks of a model: the
types, classes and general materials that are used to construct a full model
4. Object diagrams show how instances of structural elements are related and used
at run-time.
5. Composite Structure diagrams provide a means of layering an element's
structure and focusing on inner detail, construction and relationships
6. Component diagrams are used to model higher level or more complex
structures, usually built up from one or more classes, and providing a well defined
interface
7. Deployment diagrams show the physical disposition of significant artifacts
within a real-world setting.
Behavioral Modeling Diagrams
8. Behavior diagrams capture the varieties of interaction and instantaneous state
within a model as it 'executes' over time.
9. Use Case diagrams are used to model user/system interactions. They define
behavior, requirements and constraints in the form of scripts or scenarios.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
10. Activity diagrams have a wide number of uses, from defining basic program
flow, to capturing the decision points and actions within any generalized process.
11. State Machine diagrams are essential to understanding the instant to intant
condition or "run state" of a model when it executes.
12. Communication diagrams show the network and sequence of messages or
communications between objects at run-time during a collaboration instance.
13. Sequence diagrams are closely related to Communication diagrams and show the
sequence of messages passed between objects using a vertical timeline.
14. Timing diagrams fuse Sequence and State diagrams to provide a view of an
object's state over time and messages that modify that state.
15. Interaction Overview diagrams fuse Activity and Sequence diagrams to provide
allow interaction fragments to be easily combined with decision points and flows.
UML allows systems to be defined by successive refinement. Each entity in a diagram
can be refined by another diagram of the same type or a different type.
After considering how each of these diagram types might be used in human performance
modeling, we decided that Activity diagrams were most suitable. In UML, an activity
diagram is used to display the sequencing of a collection of activities. Activity diagrams
show the flow from a starting point to a finishing point and also describe the branching
logic that results in multiple possible paths in the progression of events contained in the
activity. Activity Diagrams may be also be used to detail situations where multiple,
parallel paths may occur in the execution of some activities. Activity Diagrams are often
used in business modeling where they detail the processes involved in business activities.
Figure 6 is an example of an Activity diagram showing branching logic as well as
multiple, parallel paths [39]. Note that in traditional usage of UML, Activity diagrams are
used to model software and hardware elements of a system, not the human elements.
However there is nothing about UML Activity diagrams that restricts their usage to only
the traditional purpose.
Figure 6. Example Activity diagram
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
It is also useful to further describe why the Use Case diagram is not the UML modeling
concept to use for human performance modeling. Use Case diagrams are a means for
specifying required usages of a system [2]. The key concepts associated with Use Case
diagrams are actors and the system under consideration (called the subject) to which the
Use Case diagram applies. The users and any other systems that may interact with the
subject are represented in Use Case diagrams as actors. The key observation is that
actors always model entities that are outside the system. The required behavior of the
subject is specified by one or more use cases, which are defined according to the needs of
actors. The activity of the actors themselves is not modeled in a Use Case diagram, but it
is precisely this activity that needs to be modeled in human performance modeling.
3.3.3
Extending UML
The extension mechanism of UML has undergone substantial revision between version
1.5 and 2.0. The UML profile for schedulability, performance and time specification [7]
that is described in 2.2 was finalized in 2002 and uses the mechanisms from UML 1.5.
Note that a new UML Profile for Modeling and Analysis of Real-Time and Embedded
systems (MARTE) [8] is currently under development with the OMG that will upgrade
the UML profile for schedulability, performance and time specification to be compliant
with UML 2.0, however the first draft of this work is not expected until November 2005 not in time for this white paper. Therefore we briefly describe both mechanisms here.
The UML Profile mechanism was specifically defined for providing a lightweight
extension mechanism to the UML standard. In UML 1.1, stereotypes and tagged values
were used as string-based extensions that could be attached to UML model elements in a
flexible way. In subsequent revisions of UML, including versions 1.4 and 1.5, the notion
of a Profile was defined to provide more structure and precision to the definition of
stereotypes and tagged values. Examples of stereotypes and tagged values used for
performance modeling were described in 2.2.
The UML 2.0 infrastructure and superstructure specifications have unified the profiling
mechanism with the rest of UML by recasting it as a specific meta-modeling technique.
Stereotypes have become specific meta-classes, tagged values have become standard
meta-attributes, and profiles have become specific kinds of packages.
As an example of extension in UML 2.0, consider Figure 456 from the UML 2.0
Superstructure specification [2]. Reproduced in Figure 7, it illustrates a simple stereotype
Clock is defined to be applicable to instances of the (standard) meta-class Class.
Figure 7. A stereotype
This example also illustrates a specific meta-attribute “resolution” that is associated with
each Clock. Note that a stereotype defines how an existing meta-class may be extended,
and enables the use of platform or domain specific terminology or notation in place of or
in addition to the ones used for the extended meta-class.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
It is also useful to consider the interchangeability of UML 2.0 models based on profiles.
Section 18.1.2 of UML 2.0 Superstructure specification [2] states the requirements that
drove the definition of the profile mechanism. Three of these are particularly applicable
to the present problem:
“2. It must be possible to interchange profiles between tools, together with models
to which they have been applied, by using the UML XMI interchange
mechanisms. A profile must therefore be defined as an interchangeable UML
model. In addition to exchanging profiles together with models between tools,
profile application should also be definable “by reference” (e.g. ““import by
name”); that is, a profile does not need to be interchanged if it is already present
in the importing tool. ...
9. The vast majority of UML case tools should be able to implement Profiles. The
design of UML profiles should therefore not constraint these tools to have an
internal implementation based on a meta-meta-model/meta-model architecture. ...
12. Models can be exchanged regardless of the profiles known by the destination
target. The destination of the exchange of a model extended by a profile may not
know the profile, and is not required to interpret a specific profile description. The
destination environment interprets extensions only if it possesses the required
profiles.”
These three requirements taken together imply that a profile itself can be externalized as
XML according to the rules of the UML 2.0 Diagram Interchange specification [3],
however a “general” UML design tool that imports the data will not be able enforce the
rules of the profile and interpret the intended semantics unless it implements (and
therefore understands the semantics of) the profile.
3.4 UML and human performance modeling
This section proposes a strategy for relating IMPRINT and UML based on the description
of key concepts in IMPRINT in 3.2 and of UML 2.0 in 3.3. Because the purpose of this
white paper was to investigate alternative approaches and determine a feasible approach
without actually defining the full mapping, this white paper stops short of defining the
full mapping.
The key features of the proposed approach are:
1. To insure that human performance modeling is accomplished in a uniform manner
suitable for use by a variety of cognitive engineering sub-disciplines and products,
a UML 2.0 UML Profile for Human Performance Modeling is proposed. This
profile will define a set of Stereotypes and associated meta-attributes to be used in
defining human performance models
2. The approach proposed here can be extended to many other aspects of cognitive
engineering, but this is beyond the scope of the present paper. In particular, the
scope of such a profile might be broadened to create a wider support base and to
adopt the common and well-understood technique of UML diagrams across more
of the cognitive engineering discipline. In particular, the technique seems
applicable to cognitive task analysis, computational cognitive modeling, and task
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
analysis in addition to computational task simulation programs such as IMPRINT
[44].
3. UML Activity diagrams are used to represent functions and the tasks that refine
functions. These diagrams can be part of a larger system design that integrates the
“functions” of the human with the “functions” of hardware and software elements
of the system, but how this might be accomplished is beyond the scope of the
present paper.
4. Meta-attributes (that is, attributes associated with Stereotype meta-classes) are
used to define task Requirements (Time Standard, Accuracy Standard, Accuracy
Measure, and Criterion) and task Estimated Performance (Mean Time, Time
Standard Deviation, Time Distribution, Mean Accuracy, and Accuracy Standard
Deviation).
5. The approach of using meta-attributes can be extended to other aspects of the
operatorTask of IMPRINT. This is beyond the scope of this white paper.
6. While this paper focuses on the UML -> IMPRINT direction of the mapping, the
inverse mapping is straightforward because XML diagram exchange can be both
exported from, and imported to, UML tools.
The approach is illustrated by using the example from Figures 3.21, 3.22 etc. in the
IMPRINT user manual. This example illustrates a series of steps related to disassembly
of a mechanical part. IMPRINT provides a Network Diagram that allows the
relationships between functions and/or tasks to be described. One such diagram (Figure
3-21 from the user manual) is reproduced in Figure 8 below. Notice how similar such a
diagram is to a UML Activity diagram.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Figure 8. An IMPRINT Network diagram
Figure 9 gives an example based on one of the steps (2. Removal of lower air baffle) in
Figure 8 above (and consistent with the data shown as “Function information) in Figure
3.22 of the IMPRINT User Manual). This figure shows an action (class) in a UML
Activity diagram (subclassed from a presumed Stereotype “operatorTask” class) together
with its attributes in typical UML diagram presentation style. (Details of attribute types
and their representation are pseudo-coded in this example to simplify the presentation.)
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
<<operatorTask>>
Removal of Lower Air
Baffle
timeStandard = (0:10:0)
accuracyStandard = 10
accuracyMeasure = “Percent Steps Correct”
criterion = 0.93
meanTime = (0:8:30)
timeStandard Deviation = 1.0
timeDistribution = Normal
meanAccuracy = 10
accuracyStandardDeviation = 1.0
Figure 9. Example action from a UML Activity diagram
Finally, note that while it is straightforward to envision the development and application
of this proposed UML 2.0 Profile for Human Performance Modeling, actually insuring
that the profile is used in practice will require that program management mandate its use
on each particular DoD program.
4 Getting the approach accepted by the community
4.1 Introduction
Significant effort will be required to integrate the UML extensions in a UML 2.0 Profile
for Human Performance Modeling into commercial UML products. To allow tool sets to
be interoperable it is essential that any such Profile for Human Performance Modeling
obtain the support of the UML community. UML was developed by the Object
Management Group and is the OMG's most-used specification. This implies that any
special profile of UML should be standardized within the OMG according to OMG
processes. Following these processes insures that the necessary degree of support and
consensus is obtained and that he profile will become a commercial success.
4.2 The OMG process
4.2.1
Introduction
It is important to understand the magnitude of the task involved in getting a profile
adopted by the OMG before undertaking such a task. It will require a multi-year
commitment but it can result in a profile that is implemented in commercial UML
products and accepted and used by a wide community of practice. This section describes
the major steps in the OMG process to aid in understanding the magnitude of the needed
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
commitment.
For
further
description
of
http://www.omg.org/gettingstarted/processintro.htm .
4.2.2
the
OMG
process,
see
Precursor steps
Before undertaking work within the OMG to standardize a Profile for Human
Performance Modeling, it will be important to develop and build the necessary consensus
that a market of sufficient size exists to implement and use the profile. The OMG
Hitchhiker's Guide [36] says it this way:
“Before a RFP can be crafted, one more extremely important task must be
accomplished: verifying that suppliers exist that are willing to respond to the
RFP and to commit to building its implementation. This effort should not be
interpreted as soliciting commitment but rather assessing interest within a
particular supplier community. Its intent is to avoid the embarrassment of
"sending out invitations and no one coming to the party".

Identify the industry problem to be solved.

Identify the high-level requirements associated with its solution.
 Canvas the supplier community to ensure there is interest in solving the
problem.”
Note that the OMG itself only develops specifications. It does not develop and
distribute software. Implementers of products that conform to the UML 2.0
Specification would need to be convinced to add support for the Profile for Human
Performance Modeling to their products. Building support is discussed further in
4.3.
A second necessary precursor to bringing any technology into the OMG for adoption is
that a complete “prototype” implementation is needed to demonstrate that the technology
exists and can be implemented. The OMG resists performing research as part of its
development process. The process is intended to document and develop consensus on one
or more existing solutions that can be packaged as a single OMG specification.
The last precursor step is that the government organization (or its contractor) would need
to establish membership in the OMG. OMG Membership for Government organizations
costs $12,000 per year. Government members can vote in all Task Forces and Special
Interest Groups and can attend all meetings. If a commercial organization (such as
MA&D) were to become an OMG member, membership at least at the Influencing
Member level would be required. The annual fee for such a membership is based on a
sliding scale based on the firm’s annual gross revenue. For example, firms with revenues
of 10 million to 99 million dollars a year pay a $5,000 annual fee.
4.2.3
Overview of the OMG process
The Object Management Group adopts specifications according to the process defined in
OMG Policies and Procedures Manual [35]. A guide to the Policies and Procedures
Manual is also available [36]. The first step to understanding the process is recognizing
that consensus must be reached among the OMG membership. In the process of building
this consensus, each member can contribute in two different roles:
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential

submitters of the technology, and

voters on the submission.
A single OMG member can serve in both roles are different times in the process.
Submitters write the specification that is submitted to the membership for approval
through a series of votes by the membership of different “committees” within the OMG.
Before describing the process it is necessary to understand the different committees that
would apply to this effort. In order starting from the top, these are:
1. Board of Directors (BOD): This committee provides overall direction to, and final
approval of, all work accomplished within the OMG.
2. Platform Technology Committee (TC): This committee is the umbrella committee
under which a number of different Platform Task Forces operate. (There is a
different TC for “Domain Technologies” that apply only to specific industries.)
3. Real-time, Embedded, and Specialized Systems Platform Task Force (TF): This
committee is the specific task force into whose charter any Profile for Human
Performance Modeling would likely fit. This TF is currently responsible for the
UML Profile for Scheduling, Performance, and Time [7] and the recent RFP to
undertake its revision [8].
A brief summary of the stages and steps within each stage in the OMG process that
would likely be required to develop and standardize a Profile for Human Performance
Modeling follow [35], [36]:
1. Request For Information (RFI) stage
a. The TF writes the RFI and votes to recommend that the parent TC issue it.
b. The TC votes to issue the RFI.
c. The TF accepts, reads, and analyzes responses to the RFI.
2. Request for Proposal (RFP) stage
a. Possibly using information received via the RFI, the TF writes and votes
to recommend that the parent TC issue it.
b. The OMG Architecture Board approves the RFP.
c. The TF's parent TC votes to issue the RFP. An Initial Submission deadline
is set at the time the RFP is issued.
d. On or before the Letter of Intent (LOI) deadline, one or more OMG
member companies submit LOIs. Note that by submitting an LOI the
organization is making a commitment to be involved in the submission
process. Also note that OMG membership is a requirement for submitting
an LOI.
e. On or before the Initial Submission deadline, which typically falls three
weeks before an OMG technical meeting week, all or most of these
companies will have submitted initial submissions.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
f. Interested OMG members read the submissions, and comment on them
during the meeting. A deadline is set for the receipt of revised
submissions.
g. During the interim between this meeting and the revised submission
deadline, interesting things may happen.
h. The revised submission deadline may be extended. There may be multiple
deadlines for revised submissions.
i. On or before the revised submission deadline, one or more revised
submissions may be submitted.
j. OMG members read and evaluate the revised submission (most likely) or
submissions (less likely). If most members consider the submission
worthy, a series of votes begins.
3. Adoption stage
a. If the votes are to begin at the meeting that immediately follows the
revised submission deadline, a procedural hurdle known as the "vote to
vote" is encountered.
b. The TF votes to recommend adoption to its parent TC.
c. The OMG Architecture Board votes on the submission.
d. The parent TC votes to recommend to OMG's BOD.
e. The BOD Business Subcommittee (BSC) reports to the BOD on Business
Committee Questionnaire responses from the submitters. What the OMG
is looking for in the responses is at least one submitter to agree to
incorporate the submission into a commercial product.
f. If at least one satisfactory response was received, the BOD votes to adopt
the specification. At this point, the submission becomes an official OMG
Adopted Specification, but does not receive a release number.
4. Finalization stage
a. The TC charters a Finalization Task Force (FTF).
b. The FTF performs the first maintenance revision on the specification,
resolving issues submitted to OMG, while simultaneously producing
implementations at their organizations.
c. The FTF-revised version of the specification is adopted as official OMG
technology, through the same series of votes as the original submission
(TF, Architecture Board, TC, and BOD). This time it receives a release
number, and is designated an available specification.
d. The document is edited into a formal OMG specification.
e. Typically, products reach the market around this time too.
As can be seen from the above process summary, a significant multi-year commitment is
necessary.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
4.3 Building support
Obtaining the support of the UML developer community is essential to getting any
Profile for Human Performance Modeling approved by the OMG. A list of commercially
available tools that support the OMG 2.0 Specification is available on the OMG’s web
site at http://www.uml.org/#Links-UML2Tools . At the time this white paper was written
(March 2005) the following products were on this list:

ARTiSAN's Real-time Studio

Computas' Metis with UML 2.0 Template

Embarcadero Describe

I-Logix Rhapsody

MetaMatrix MetaBase Modeler

No Magic's MagicDraw UML

Rational Software Architect and Modeler

Sparx Systems Enterprise Architect

Telelogic's TAU Developer and TAU Architect

Together Designer Community Edition
Note that the Rational Rose products of Rational Software (a subsidiary of IBM) are
NOT
compliant
with
the
UML
specification
(see
http://www306.ibm.com/software/rational/sw-atoz/indexR.html ). Rational Software Architect and
Rational Software Modeler could be used instead (see http://www306.ibm.com/software/rational/sw-atoz/indexS.html ). The support of at least one of these
developers must be sought prior to initiating the development of the profile.
5 Next steps
The next steps to follow in developing a UML 2.0 Profile for Human Performance
Modeling are:
1. Work out a detailed proof of concept example of a set of UML Activity diagrams
that specify the functions, tasks, and input parameters for a non-trivial human
performance model. The example should illustrate both refinement as well as
significant branching logic. We believe that this can be accomplished without first
defining a profile by using standard UML mechanisms of sub-classing and
attribute definition. Any of several different commercial UML products could be
used for this purpose.
2. Investigate how UML Activity diagrams of the sort defined here fit into the larger
milieu of system specification and system architecture definition. This should be
done by conducting a pilot project on a real system development (and may be
combined with the proof of concept example listed in Step 1). Being able to show
the value added by these more detailed and refined “human” Activity diagrams to
the overall process of defining a system with both human and automated elements
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
should increase the likelihood that the technique is accepted for use in future
developments.
3. Having the results of Steps 1 and 2 in hand, the first steps discussed in 4 (Getting
the approach accepted by the community) should be undertaken. In particular the
opportunity presented by such a profile should be discussed with UML tool
vendors and a presentation should be made at an OMG meeting about the
significance of the opportunity.
4. Once sufficient support is built, form a Task Force within the OMG to begin
developing the profile following the OMG development process.
5. Extend IMPRINT to import and export UML 2.0 Diagram Interchange format
XML.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Annotated bibliography
1. Object Management Group, OMG Unified Modeling Language Specification, Version
1.5, March 2003
The Unified Modeling Language (UML) is a graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a software-intensive system. The UML offers
a standard way to write a system's blueprints, including conceptual things such as business
processes and system functions as well as concrete things such as programming language
statements, database schemas, and reusable software components.
The UML represents the culmination of best practices in practical object-oriented modeling.
The UML is the product of several years of hard work, in which we focused on bringing
about a unification of the methods most used around the world, the adoption of good ideas
from many quarters of the industry, and, above all, a concentrated effort to make things
simple.
2. Object Management Group, Unified Modeling Language: Superstructure, version 2.0,
September 2003
This UML 2.0: Superstructure is the second of two complementary specifications that
represent a major revision to the Object Management Group’s Unified Modeling Language
(UML), for which the most current version is UML v1.4. The first specification, which
serves as the architectural foundation for this specification, is the UML 2.0: Infrastructure.
This UML 2.0: Superstructure defines the user level constructs required for UML 2.0. It is
complemented by UML 2.0: Infrastructure which defines the foundational language
constructs required for UML 2.0. The two complementary specifications constitute a
complete specification for the UML 2.0 modeling language.
3. Object Management Group, Unified Modeling Language: Diagram Interchange,
version 2.0, September 2003
The goal of this specification is to enable a smooth and seamless exchange of documents
compliant to the UML standard (in the following referred to as UML models) between
different software tools. While this certainly includes tools for developing UML models, it
also includes tools such as whiteboard tools, code generators, word processing tools, and
desktop publishing tools. Also, special attention is given to the Internet as a medium for
exchanging and presenting UML models.
Although a mechanism for exchanging UML models had been specified for UML 1.x using
XMI, namely the XML Metadata Interchange, (in the following referred to as XMI[UML]),
this mechanism did not fully fulfill the goal of a model interchange. Foremost, it did not
include the exchange of diagram information. This mechanism was only capable of
transporting information on what elements are contained in a UML model but not the
information on how these elements are represented and laid out in diagrams. Thus, if a UML
model is stored in one UML tool and then loaded in a different UML tool (or even the same
tool) using XMI[UML], all diagram information is lost. This limitation is not due to XMI
itself but instead to the fact that the UML metamodel does not define a standard way of
representing diagram definitions.
4. Object Management Group, Unified Modeling Language (UML) Specification:
Infrastructure, version 2.0
This UML 2.0: Infrastructure is the first of two complementary specifications that represent
a major revision to the Object Management Group’s Unified Modeling Language (UML),
for which the previous current version was UML v1.5. The second specification, which uses
the architectural foundation provided by this specification, is the UML 2.0: Superstructure
(ptc/03-08-02).
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
The UML 2.0: Infrastructure defines the foundational language constructs required for UML
2.0. It is complemented by UML 2.0: Superstructure, which defines the user level constructs
required for UML 2.0.
5. Object Management Group, OCL 2.0, OMG Final Adopted Specification, October
2003
This specification contains defines the Object Constraint Language (OCL), version 2.0. OCL
version 2.0 is the version of OCL that is aligned with UML 2.0 and MOF 2.0.
The Object Constraint Language (OCL) is a formal language used to describe expressions on
UML models. These expressions typically specify invariant conditions that must hold for the
system being modeled or queries over objects described in a model. Note that when the OCL
expressions are evaluated, they do not have side effects; i.e. their evaluation cannot alter the
state of the corresponding executing system.
OCL expressions can be used to specify operations / actions that, when executed, do alter the
state of the system. UML modelers can use OCL to specify application-specific constraints
in their models. UML modelers can also use OCL to specify queries on the UML model,
which are completely programming language independent.
6. Object Management Group, OMG Unified Modeling Language Specification, Version
1.3, 2001
The Unified Modeling Language (UML) is a language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML represents a collection of the best
engineering practices that have proven successful in the modeling of large and complex
systems.
7. Object Management Group, UML Profile for Schedulability, Performance, and Time
Specification, Version 1.1, January 2005
Since the adoption of the UML standard, it has been used in a large number of time-critical
and resource-critical systems. (A significant number of these can be found in the various
books, papers, and reports listed in the Bibliography at the end of this specification.) Based
on this experience, a consensus has emerged that, while a useful tool, UML is lacking in
some key areas that are of particular concern to real-time system designers and developers.
In particular, it was noticed that the lack of a quantifiable notion of time and resources was
an impediment to its broader use in the real-time and embedded domain.
Fortunately, and contrary to an often expressed opinion, it was discovered that UML had all
the requisite mechanisms for addressing these issues, in particular through its extensibility
faculties. This made the job much easier, since it was unnecessary to add new fundamental
modeling concepts to UML - so-called "heavyweight" extensions. Consequently, the job
consisted of defining a standard way of using these capabilities to represent concepts and
practices from the real-time domain.
Over time, a number of different modeling techniques and concepts have emerged within the
real-time software community. Each technique has fostered its own diverse set of
terminology and notations. One of the intentions behind this specification is to provide a
common framework within UML that fully encompasses this diversity but still leaves
enough flexibility for different specializations. In particular, focus was placed on properties
that are related to modeling of time and time-related aspects such as the key characteristics
of timeliness, performance, and schedulability.
8. Object Management Group, UML Profile for Modeling and Analysis of Real-Time and
Embedded systems (MARTE), Request For Proposals, February 2005
This Request for Proposals solicits submissions for a UML™ profile that adds capabilities
for modeling Real Time and Embedded Systems (RTES), and for analyzing schedulability
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
and performance properties of UML specifications. The new profile is intended to replace
the existing UML Profile for Schedulability, Performance and Time (formal/03-09-01).
9. ISO/IEC 10746:1998. Reference Model of Open Distributed Processing. Available
from
the
world
wide
web:
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm
The rapid growth of distributed processing has led to a need for a coordinating framework
for the standardization of Open Distributed Processing (ODP). This Reference Model
provides such a framework. It creates an architecture within which support of distribution,
interworking and portability can be integrated.
The Reference Model of Open Distributed Processing, ITU-T Rec. X.901 | ISO/IEC 10746-1
to ITU-T Rec. X.904 | ISO/IEC 10746-4, is based on precise concepts derived from current
distributed processing developments and, as far as possible, on the use of formal description
techniques for specification of the architecture.
10. Heumann, Jim. User experience storyboards: Building better UIs with RUP, UML,
and use cases. November 2003. The Rational Edge. Available from the world wide web
http://www106.ibm.com/developerworks/rational/library/content/RationalEdge/nov03/f_usability_jh
.pdf
Use cases describe the way a system will be used, but they don't specify the system user
interface (UI). User experience storyboards, based on the use cases, add the process and
techniques necessary to design and build a user interface that will meet requirements and
allow users to exercise all the system behavior described in the use cases. These storyboards
provide a firm foundation for the detailed UI design and also facilitate communication
among development team members -- especially between the creative team that designs the
UI and the architects and developers who design and implement the system. This paper
provides a complete example including branching and conditional execution based on use
actions.
11. Glinz, Martin. Problems and Deficiencies of UML as a Requirements Specification
Language. Proceedings of the 10th International Workshop on Software Specification
and Design. IEEE Computer Society. 2000. p 11.
In recent years, UML has become a standard language for modeling software requirements
and design. In this paper, we investigate the suitability of UML as a semiformal
requirements specification language. Using the Teleservices and Remote Medical Care
(TRMCS) case study as an example, we identify and demonstrate various problems and
deficiencies of UML, particularly concerning use case models and system decomposition.
We also investigate whether and how the deficiencies can be overcome and how potential
alternatives could look.
12. Agarwal, Ritu and Atish P. Sinha. Object-oriented modeling with UML: a study of
developers' perceptions. Communications of the ACM, Volume 46 , Issue 9 (September
2003). Pages: 248 - 256.
Prior research exploring the effectiveness of the OO approach has found that developers
experience problems in modeling the behavior-related aspects of an application. In UML,
sequence (interaction) diagrams capture a system's behavioral aspects in terms of messages,
sequencing of messages, and invocation of operations by messages. In turn, those diagrams
can help tackle the difficult problem of allocating behavior among object classes in a UML
class diagram. Given the interdependence of class and interaction diagrams in UML, it is
critical that both researchers and practitioners address this issue and find ways to enhance the
usability of those diagrams.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
13. Cortellessa, Vittorio, Harshinder Singh, and Bojan Cukic. Early reliability assessment
of UML based software models. Proceedings of the third international workshop on
Software and performance table of contents, Rome, Italy (2002). ACM Press. Pages: 302
- 309.
The ability to validate software systems early in the development lifecycle is becoming
crucial. While early validation of functional requirements is supported by well known
approaches, the validation of non-functional requirements, such as reliability, is not. Early
assessment of non-functional requirements can be facilitated by automated transformation of
software models into (mathematical) notations suitable for validation. These type of
validation approaches are usually as "transparent" to the developers as possible.
Consequently, most software developers find them user friendly and easy to adopt.In this
paper we introduce a methodology that starts with the analysis of the UML model of
software architecture followed by the bayesian framework for reliability prediction. We
utilize three different types of UML diagrams: Use Case, Sequence and Deployment
diagrams. They are annotated with reliability related attributes. Unlike traditional reliability
growth models, which are applicable late in the lifecycle, our approach bases system
reliability prediction on component and connector failure rates. In mature development
environments, these may be available as the result of reuse. Throughout the lifecycle, as the
developers improve their understanding of failure rates and their operational usage, system
reliability prediction becomes more precise. We demonstrate the approach through a case
study based on a simple web-based transaction processing system.
14. Fernandes, João M., Ricardo J. Machado, and Henrique D. Santos. Modeling
industrial embedded systems with UML. Proceedings of the eighth international
workshop on Hardware/software codesign. ACM Press (2000) Pages: 18 - 22 .
The main purpose of this paper is to present how the Unified Modeling Language (UML)
can be used for modeling industrial embedded systems. By using a car radios production line
as a running example, the paper demonstrates the modeling process that can be followed
during the analysis phase of complex control applications. In order to guarantee the
continuity mapping of the models, the authors propose some guidelines to transform the use
case diagrams into a single object diagram, which is one of the main diagrams for the next
development phases.
15. Amyot, Daniel and Gunter Mussbacher. Bridging the requirements/design gap in
dynamic systems with use case maps (UCMs). Proceedings of the 23rd International
Conference on Software Engineering.IEEE Computer Society (2001). Pages: 743 - 744
Two important aspects of future software engineering techniques will be the ability to
seamlessly move from analysis models to design models and the ability to model dynamic
systems where scenarios and structures may change at run-time. Use Case Maps (UCMs) are
used as a visual notation for describing causal relationships between responsibilities of one
or more use cases. UCMs are a scenario-based software engineering technique most useful at
the early stages of software development. The notation is applicable to use case capturing
and elicitation, use case validation, as well as high-level architectural design and test case
generation. UCMs provide a behavioural framework for evaluating and making architectural
decisions at a high level of design. Architectural decisions may be based on performance
analysis of UCMs. UCMs bridge the gap between requirements and design by combining
behaviour and structure in one view and by flexibly allocating scenario responsibilities to
architectural components. They also provide dynamic (run-time) refinement capability for
variations of scenarios and structure and they allow incremental development and integration
of complex scenarios. Therefore, UCMs address the issues mentioned above.
16. Alsaadi, Ahmad. A performance analysis approach based on the UML class diagram.
Proceedings of the fourth international workshop on Software and performance. ACM
Press (2004). Pages: 254 - 260.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
A data model, or UML class diagram of a software system, is of central importance to the
computing time and the disk usage a software system exhibits. It can be normalized or
denormalized to better utilize the components of a computer system or to offer acceptable
performance values.This paper describes an approach to software performance analysis that
is based on the UML class diagram. It predicts the performance values for use cases
operating on persistent data collections as well as whether and how much normalization or
denormalization a UML class diagram may need, in order to ensure that these use cases meet
their performance objectives.
17. Hoeben, Fried. Using UML models for performance calculation. Proceedings of the
second international workshop on Software and performance. ACM Press (2000). Pages:
77 - 82.
UML models will quite often lack some of the detail required for performance estimation.
This paper explores some ideas to automatically remove layers of indirection and abstraction
that hinder straightforward performance evaluation of UML models. Using UML makes the
information accessible (since it is a widely know language) and reduces the extra effort (and
overhead) needed for performance engineering. Much information normally present in UML
models can be used for performance engineering, and adding extra information is relatively
straightforward. Using these ideas in a CASE tool allows automatic performance
calculations based on models at varying levels of detail. And by breaking-down performance
requirements at each design refinement they become tangible and more meaningful during
development and testing.
18. Lindemann, Christoph, et. al. Performance analysis of time-enhanced UML diagrams
based on stochastic processes. Proceedings of the third international workshop on
Software and performance. ACM Press (2002) Pages: 25 - 34.
In this paper, we propose extensions to UML state diagrams and activity diagrams in order to
allow the association of events with exponentially distributed and deterministic delays. We
present an efficient algorithm for the state space generation out of these UML diagrams that
allows a quantitative analysis by means of an underlying stochastic process. We identify a
particular stochastic process, the generalized semi-Markov process (GSMP), as the
appropriate vehicle on which quantitative analysis is performed. As innovative feature the
algorithm removes vanishing states, i.e. states with no timed events active, and considers
branching probabilities within activity diagrams. Furthermore, we introduce a performance
evaluation framework that allows a system designer to predict performance measures at
several steps in the design process. The applicability of our approach for practical
performance and dependability projects is demonstrated by an UML specification of the
General Packet Radio Service, a packet switched extension in GSM wireless networks.
19. Biddle, Robert, James Noble, and Ewan Tempero. Essential use cases and
responsibility in object-oriented development. Proceedings of the twenty-fifth
Australasian conference on Computer science - Volume 4. Australian Computer Society,
Inc. (2002) Pages: 7 - 16.
Essential use cases are abstract, lightweight, technology-free dialogues of user intention and
system responsibility that effectively capture requirements for user interface design. We
describe how essential use cases can also drive object-oriented development directly, without
any intervening translation, and allowing user interface development and object-oriented
development to proceed in parallel. Working with essential use cases yields some
unexpected further benefits: the crucial common vocabulary of responsibilities lets designers
trace directly from the essential use cases to the objects in their design.
20. Balsamo, Simonetta and Moreno Marzolla. A simulation-based approach to software
performance modeling. Proceedings of the 9th European software engineering conference
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
held jointly with 11th ACM SIGSOFT international symposium on Foundations of
software engineering. ACM Press (2003) Pages: 363 - 366.
Software performance is the process of predicting and evaluating whether the software
system satisfies performance goals defined by the user. Early identification of unsatisfactory
performance of Software Architecture (SA) can greatly reduce the cost of design change.
The reason is that correcting a design flaw is more expensive the later the change is applied
during the software development process.
The Software Performance Engineering methodology has been the first comprehensive
approach to the integration of performance analysis into the software development process.
Since then, various classes of performance models of software systems have been considered
in the literature, including models based on simulation.
In this paper we consider the derivation of a simulation model from a SAs pecification. The
approach we describe can be easily extended to model complex architectural patterns
involving, for example, simultaneous resource possession and arbitrary types of blocking
behaviors. We develop an algorithm for translating annotated UML specifications of
software systems into simulation models. We consider SA expressed in term of Unified
Modeling Language (UML) Use Case, Activity and Deployment diagrams. The diagrams are
annotated according to a subset of the UML Profile for Schedulability, Performance and
Time Specification (referred as UML performance profile). Annotations provide parameters
to the simulation model.
21. Wieringa, Roel. A survey of structured and object-oriented software specification
methods and techniques. ACM Computing Surveys, Volume 30 , Issue 4 (December
1998) Pages: 459 - 527.
This article surveys techniques used in structured and object-oriented software specification
methods. The techniques are classified as techniques for the specification of external
interaction and internal decomposition. The external specification techniques are further
subdivided into techniques for the specification of functions, behavior, and communication.
After surveying the techniques, we summarize the way they are used in structured and
object-oriented methods and indicate ways in which they can be combined. This article ends
with a plea for simplicity in diagram techniques and for the use of formal semantics to define
these techniques. The appendices show how the reviewed techniques are used in 6 structured
and 19 object-oriented specification methods. This article contains a comprehensive set of
128 references.
22. Bernardi, Simona, Susanna Donatelli , and José Merseguer. From UML sequence
diagrams and statecharts to analysable petri net models. Proceedings of the third
international workshop on Software and performance table of contents. ACM Press
(2002). Pages: 35 - 45.
In this paper we study the use of Sequence Diagrams and Statecharts of the Unified
Modeling Language (UML) for the validation and the performance evaluation of systems.
We assume that the system is specified as a set of Statecharts and that Sequence Diagrams
are used to represent "executions of interest". UML lacks a formal semantics and hence it is
not possible to apply, directly, mathematical techniques on UML models for system
validation. To reach this goal we propose an automatic translation of Statecharts and
Sequence Diagrams into Generalized Stochastic Petri Nets, and a composition of the
resulting net models suitable for reaching a given analysis goal. The translation into Petri
nets is based on the abstract syntax of the UML Collaborations and of the State Machines
packages (from which Sequence Diagrams and Statecharts are derived) and the construction
of the complete model heavily uses compositionality.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
23. Billard, Edward A. Operating system scenarios as Use Case Maps. Proceedings of the
fourth international workshop on Software and performance. ACM Press (2004) Pages:
266 - 277.
This paper summarizes the analysis, design, implementation, and performance analysis of an
object-oriented operating system. The analysis applies Use Case Maps (UCMs) to provide a
high-level abstraction of the behavior scenarios for state transition, character output, network
access, and disk access. The UCM for state transitions is converted into a queueing network
for simulation study of I/O-bound versus CPU-bound systems. An overview of the later
stages emphasizes UML for architecture and detailed collaboration, as well as Java
examples. The performance of the disk sub-system is analyzed by instrumenting the Java
code, and the results show that design choices can affect the throughput.
24. Gu, Gordon P. and Dorina C. Petriu. XSLT transformation from UML models to
LQN performance models. Proceedings of the third international workshop on Software
and performance. ACM Press (2002) Pages: 227 - 234.
A graph grammar-based transformation of a UML design model into a Layered Queueing
Network (LQN) performance model was previously proposed by the authors of this paper.
The actual transformation was implemented in two ways: first by using an existing graphrewriting tool, and secondly through an ad-hoc graph transformation implemented in Java.
This paper extends the previous work of the authors by proposing a third approach to
implement the UML to LQN transformation by using XSLT. Recommended by the World
Wide Web Consortium (W3C) the Extensible Stylesheet Language for Transformations
(XSLT) is a flexible language for transforming XML documents into various formats
including HTML, XML, text, PDF, etc. The input to our XSLT transformation is an XML
file that contains the UML model in XML format according to the standard XML Metadata
Interchange (XMI). The output is the corresponding LQN model description file, which can
be read directly by existing LQN solvers. The paper compares the relative advantages and
disadvantages of the XSLT transformation with the previous approaches proposed by the
authors, describes the principles of the XSLT transformation and applies it to a case study.
This paper includes references to the body of research dedicated to transforming UML
models into different kinds of performance models
25. Martin, Grant, Luciano Lavagno, and Jean Louis-Guerin. Embedded UML: a merger
of real-time UML and co-design. Proceedings of the ninth international symposium on
Hardware/software codesign. ACM Press (2001). Pages: 23 - 28.
In this paper, we present a proposal for a UML profile called `Embedded UML'. Embedded
UML represents a synthesis of various ideas in the real-time UML community, and concepts
drawn from the Hardware-Software co-design field. Embedded UML first selects from
among the competing real-time UML proposals, the set of ideas which best allow
specification and analysis of mixed HW-SW systems. It then adds the necessary concept of
underlying deployment architecture that UML currently lacks in complete form, using the
notion of an embedded HW-SW `platform'. It supplements this with the concept of a
`mapping', which is a platform-dependent refinement mechanism that allows efficient
generation of an optimised implementation of the executable specification in both HW and
SW. Finally, it provides an approach which supports the development of automated analysis,
simulation, synthesis and code generation tool capabilities which can be provided for design
usage even while the embedded UML standardisation process takes place.
26. Arnowitz, Jonathan, Duco Fijma, and Jouke Verlinden. Communicating a task
analysis with task layer maps. Proceedings of the conference on Designing interactive
systems: processes, practices, methods, and techniques. ACM Press (2000). Pages: 346 353.
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
Modern user interface design methods, regardless of their extremely diverse viewpoints, all
seem to agree that a document outlining a task analysis is essential for good user interface
design. However, most representations of task analysis are difficult to understand. This
difficulty makes the transition to dialogue design difficult, especially for multidisciplinary
design teams with few shared skills and terminology. Using techniques borrowed from the
study of parallel processing, the authors have developed a technique of task analysis
representation called Task Layer Maps. Task Layer Maps are both quick and easy to
understand. This technique helps design teams to quickly come up with a dialogue design
and also allows checking that design for conformance with the task analysis.
27. Paternò, Fabio. ConcurTaskTrees and UML: how to marry them? CNUCE-C.N.R.,
Via V.Alfieri 1, 56010 Ghezzano, Pisa, Italy. Undated, Available from the world wide
web
at:
http://giove.cnuce.cnr.it/Guitare/Document/ConcurTaskTrees_and_UMLnew.htm
Nowadays, UML is the most successful model-based approach to support software
development. However, during the evolution of UML little attention has been paid to
supporting the user interfaces design and development. In the meantime, the user interface
has become a crucial part in most software projects, and the use of models to capture
requirements and express solutions for its design a true necessity. Within the community of
researchers investigating model-based approaches for interactive applications particular
attention has been paid to task models. ConcurTaskTrees is one of the most widely used
notations for task modelling. In this position paper there is a discussion of how the two
approaches can be integrated and why this is a desirable goal.
28. Paris, Cécile, Shijian Lu, and Keith Vander Linden. Environments for the
Construction and Use of Task Models. To appear in The Handbook of Task Analysis for
Human-Computer Interaction. Edited by Prof. Dan Diaper & Prof. Neville Stanton.
Lawrence Erlbaum Associates. (In press) Available from the world wide web:
http://www.calvin.edu/~kvlinden/distributions/Paris-VL-Lu-HTA-2003.pdf
Task models are useful because they support the design and evaluation of
interactive systems from the point of view of the intended users. Unfortunately,
they are also difficult to build. To help alleviate this problem, tools have been
built that aid in the construction of task models in a variety of ways, in the hope
that designers will be encouraged to build explicit task models and reap the
benefits of their use and reuse. This chapter will review the range of tools that
have been built, and, as an example, will discuss ISOLDE, an environment that
integrates an heterogeneous set of such tools and supports the construction, use,
and reuse of task models.
29. Roth, E. M., Patterson, E. S., & Mumaw, R. J. Cognitive Engineering: Issues in UserCentered System Design. In J.J. Marciniak, Ed. Encylopedia of Software Engineering
(2nd Edition). NY: John Wiley and Sons.
Cognitive engineering is an interdisciplinary approach to the development of principles,
methods, tools, and techniques to guide the design of computerized systems intended to
support human performance (Norman, 1981; Woods and Roth, 1988a; 1988b). The basic
unit of analysis in cognitive engineering is a cognitive system, composed of human and
machine agents in a work domain that is delineated by roles, work and communication
norms, artifacts, and procedures. Cognitive engineering draws on the disciplines of cognitive
psychology, cognitive science, computer science, human-computer interaction, human
factors, and related fields. The goal of cognitive engineering is to develop systems that are
easy to learn, easy to use, and result in improved human-computer system performance
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
30. Keller, John et. al. Cockpit System Situational Awareness Modeling Tool. Available
from the world wide web: http://techreports.larc.nasa.gov/ltrs/PDF/2004/mtg/NASA2004-2chpsaat-kal.pdf
This project explored the possibility of predicting pilot situational awareness (SA) using
human performance modeling techniques for the purpose of evaluating developing cockpit
systems. The Improved Performance Research Integration Tool (IMPRINT) was combined
with the Adaptive Control of Thought-Rational (ACT-R) cognitive modeling architecture to
produce a tool that can model both the discrete tasks of pilots and the cognitive processes
associated with SA. The techniques for using this tool to predict SA were demonstrated
using the newly developed Aviation Weather Information (AWIN) system. By providing an
SA prediction tool to cockpit system designers, cockpit concepts can be assessed early in the
design process while providing a cost-effective complement to the traditional pilot-in-theloop experiments and data collection techniques.
31. Campbell, Gwendolyn E. and Janis A. Cannon-Bowers. Human Performance Model
Support for a Human-Centric Design Process, Naval Air Warfare Center Training
Systems
Division.
Available
from
the
world
wide
web:
http://www.manningaffordability.com/s&tweb/PUBS/HPM-HumanCentricDesign/HPMHumanCentricDesign.pdf
For years, systems designers following a traditional design process have made use of models
of hardware and software. A human-centric design process imposes additional requirements
and analyses on the designer, and we believe that additional types of models – models of
human performance – are necessary to support this approach to design. Fortunately, there
have been recent technological advances in our ability to model all aspects of human
performance. This paper will describe three specific applications of human performance
modeling that we are exp loring to support the design of human-centric systems, such as
future Navy ships. Specifically, this technology can be used to generate team design
concepts, to provide human-centric decision support for systems engineers, and to allow
simulation-based evaluation of human performance. We believe that human performance
modeling technology has matured to the point where it can play a significant role in the
human-centric design process, reducing both cost and risk.
32. Martin, Edward A., Bryan E. Brett, and David G. Hoagland, Tools For Including
Realistic Representations Of Operator Performance In DoD Constructive Simulations.
Proceedings of the AIAA Modeling and Simulation Technologies 1999. Available from
the world wide web: http://www.hec.afrl.af.mil/publications/CARTConstruct.pdf .
Military weapon systems are normally built to satisfy a set of requirements levied by the
war-fighter. All these weapon systems are manned in some sense, yet tools for quantifying
the effectiveness with which a crew-station must support operator performance are lacking.
Analysts and decision-makers need a means to readily model and understand the effects of
human performance on total weapon system effectiveness when translating operational
requirements into system requirements. This paper discusses the research and demonstration
activities being conducted by the Combat Automation Requirements Testbed (CART)
Program within the Air Force Research Laboratory / Human Effectiveness Directorate.
CART will demonstrate how human-in-the-loop and constructive operator models and data
can be integrated with Simulation-Based Acquisition activities for the purpose of defining
crew-station requirements. Utilizing the Army's IMPRINT human-performance modeling
environment, CART will provide High Level Architecture (HLA) interfaces that enable
human performance models to interact with constructive models of systems. A second
extension will incorporate the ability to represent the goal-oriented nature of human
performance. Modelers and analysts will be able to define operator goal states and priorities
that dynamically drive task network models based on changing states and events in
simulated military environments
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
33. Mitchell, Diane Kuhl Mental Workload and Workload Modeling Tools. Army
Research Laboratory, Aberdeen Proving Ground, MD 21005-5425. ARL-TN-161 April
2000. Available from the world wide web: http://www.arl.army.mil/ARLDirectorates/HRED/imb/imprint/ARL-TN-161.pdf .
The author of this report provides an overview of mental workload theory and mental
workload measurement. She also describes the development, application, and validation of
the mental workload modeling tools developed by the Human Research and Engineering
Directorate of the U.S. Army Research Laboratory (ARL). These ARL tools, VACP (visual,
auditory, cognitive, psychomotor) option in the improved performance research integration
tool (IMPRINT) and WinCrew, can help the designers of military systems to assess the
mental workload associated with different configurations of soldiers and equipment involved
in the performance of a mission. System designers can conduct this assessment in the
concept development phase of system design and reduce the need to build costly system
mock-ups.
34. Improved Performance Research Integration Tool (IMPRINT), User’s Guide, Version
7. US Army Research Laboratory, Human Research and Engineering Directorate.
October 2003.
The Improved Performance Research Integration Tool (IMPRINT) was developed for the
Army Research Laboratory (ARL) Human Research and Engineering Directorate (HRED).
IMPRINT is government-owned and consists of a set of automated aids to assist analysts in
conducting human performance analyses. IMPRINT provides the means for estimating
manpower, personnel, and training (MPT) requirements and constraints for new weapon
systems very early in the acquisition process.
35. Object Management Group. Policies and Procedures of the OMG Technical Process.
Version
2.3.
1
May
2003Available
from
the
world
wide
web:
http://www.omg.org/docs/pp/04-05-01.doc
This document outlines the policies and procedures used by the Architecture Board and
Technology Committees (collectively the "Technical Plenaries") of the Object Management
Group, Inc. These policies and procedures may change by vote of those groups as their needs
and purposes change (see Section 6).
36. Object Management Group. The OMG Hitchhiker's Guide. A Handbook for the OMG
Technology Adoption Process. Version 6.0. Available from the world wide web:
http://www.omg.org/docs/omg/01-08-01.doc .
This document is a handbook that serves as an aid to navigating through and complying with
the OMG technology adoption process. While the guide was written with those responsible
for shepherding the process in mind, it will serve as a useful interpretive tool for anyone
wishing to understand the process better.
37. Selic, Bran. Unified Modeling Language version 2.0. Rational developerWorks.
Available
from
the
world
wide
web:
http://www128.ibm.com/developerworks//rational/library/05/321_uml/
So-called "model-driven" development (MDD) methods, which are based on higher levels of
abstraction and greater use of automation compared to traditional methods, have already
demonstrated their potential for radical improvements in the quality of software and the
productivity of development. Since the role of modeling languages is crucial to the success
of MDD, a major revision of the industry-standard Unified Modeling Language (UML) was
recently completed. While several important new modeling capabilities were added -- such
as the ability to more accurately capture software architectures -- the dominant characteristic
of this revision is the heightened precision of the language definition that enables greater
GSC Associates Proprietary and Confidential
GSC Associates Proprietary and Confidential
levels of automation. This article explains how this was achieved and also describes other
highlights of UML 2.0.
38. Sparx Systems. Creswick, Victoria, Australia. UML Tutorial - Part 1. Available from
the world wide web: http://www.sparxsystems.com.au/UML_Tutorial.htm .
The Unified Modeling Language has quickly become the de-facto standard for building
Object-Oriented software. This short tutorial provides a very high level introduction to
UML, and suggests some further reading.
39. Sparx Systems. Creswick, Victoria, Australia. UML 2.0 Tutorial. Available from the
world wide web: http://sparxsystems.com.au/UML2_tutorial/UML2_Tutorial_Intro.htm.
UML 2 semantics are explained in detail in this UML 2.0 tutorial which expands on the
UML Tutorial - Part 1 which is based upon UML 1.x. It is recommended that newcomers to
UML read UML Tutorial - Part 1 to familiarize themselves with the basic UML concepts
and models before reading the UML 2.0 tutorial. The UML 2.0 tutorial details all 13 of the
UML diagram types supported by the Enterprise Architect of Sparx Systems.
40. Mitre Corporation, A Survey of Cognitive Engineering Methods and Uses. Available
from the world wide web: http://mentalmodels.mitre.org/cog_eng/index.htm
41. Balarin, F., Chiodo, M., P. Giusto, Hsieh, H., Jureeska, A., Lavagno, L., Passerone,
C., Sangiovanni-Vincentelli, A., Sentovich, E., Suzuki, K., and Tabbara, B. HardwareSoftware Co-Design of Embedded Systems: The POLIS Approach, Kluwer, 1997.
This book is the seminal one on hardware-software co-design approaches. Originating from a
1988 meeting at Magneti Marelli, a major European producer of automotive electronic
subsystems, the POLIS project headed by Balarin (Cadence Berkeley Labs; Berkeley, CA),
developed into a research methodology and supporting software for solving complex design
challenges. Along with colleagues from Italy and Japan, the Berkeley scientists discuss the
importance and design of embedded systems, models and representations, synthesis,
interface synthesis and the real-time operating system, verification, interfacing to external
hardware and software, design examples, the syntax of SHIFT, and future directions. A
glossary is included. What POLES stands for remains a mystery.
GSC Associates Proprietary and Confidential