UML and Human Performance Modeling
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.
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 References 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
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.
Related research
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 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.
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:
[pic]
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.
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:
[pic]
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.
[pic]
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 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:
[pic]
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.
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].
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.
3 UML applied to human action and interface specification
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
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 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.
[pic][pic]
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.”
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.
Technical approach
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).
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
▪ 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 Background information on UML
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:
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].
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.
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.
[pic]
Figure 6. Example Activity diagram
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 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.
[pic]
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.
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.
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 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.
[pic]
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.)
[pic]
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.
Getting the approach accepted by the community
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.
2 The OMG process
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 commitment. For further description of the OMG process, see .
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.
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:
• 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.
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.
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 . 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 ). Rational Software Architect and Rational Software Modeler could be used instead (see ). The support of at least one of these developers must be sought prior to initiating the development of the profile.
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 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.
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).
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 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:
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
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.
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.
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 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.
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.
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:
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:
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
30. Keller, John et. al. Cockpit System Situational Awareness Modeling Tool. Available from the world wide web:
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:
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: .
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
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: .
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:
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: .
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:
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 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: .
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: .
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:
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.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- colorado department of health and human services
- metaphysics and human life
- small business and human resources
- bergen county health and human services
- science and human behavior summary
- strengths and weaknesses performance review
- schumann resonance and human body
- safety and security performance phrases
- china and human rights
- human performance evaluation form
- philosophy and human existence
- texas health and human services child care