Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

UML and Human Performance Modeling

VIEWS: 66 PAGES: 36

									                    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
    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
3     Technical approach ................................................................................................... 12
    3.1       Introduction ....................................................................................................... 12
    3.2       Background information on IMPRINT ............................................................. 12
    3.3       Background information on UML .................................................................... 13
      3.3.1    ReferencesError! Bookmark not defined.Error! Bookmark not
      defined.
      3.3.2          Quick summary of UML 2.0 ..................................................................... 14
      3.3.3          Extending UML ........................................................................................ 16
    3.4       UML and human performance modeling .......................................................... 17
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       Building support................................................................................................ 24
5     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 process-
oriented 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 well-
specified 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 model-
based 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       the    OMG        process,   see
http://www.omg.org/gettingstarted/processintro.htm .

4.2.2      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://www-
306.ibm.com/software/rational/sw-atoz/indexR.html ). Rational Software Architect and
Rational Software Modeler could be used instead (see http://www-
306.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://www-
106.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 graph-
      rewriting 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_UML-
new.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 User-
Centered 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/NASA-
2004-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-the-
      loop 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/HPM-
HumanCentricDesign.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/ARL-
Directorates/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://www-
128.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. Hardware-
Software 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

								
To top