Visual Modeling of Engineering Systems with UML

Tutorial Objectives

The big difference between object-oriented design and development, and the more traditional procedural style is that the former must not only support a well-defined sequence of processes, but be well decoupled so that the system can be easily pulled apart, reconfigured, and maintained. This requires extra decisions on how functionality should be distributed among the system components -- however, if this is done well, then enhanced flexibility can result from the application of object-oriented principles (D'Souza et al., 1998).

We are interested in understanding the extent to which the Unified Modeling Language (UML) can support descriptions of system behavior, system structure, and system processes. Hence, the objectives of this tutorial are as follows:

  1. To explain the goals and benefits of UML.
  2. To explain role of visual modeling languages (in particular UML) in representing the mission, behavior, structure, and performance of engineering systems.
  3. After we figure out how OCL can be connected to UML, hopefully this item will also include "preliminary performance assessment" of engineering systems.

The tutorial does not cover:

  1. UML diagram notation and semantics. These details are covered in the supporting tutorial .
  2. Systems engineering development processes (e.g., models of systems engineering lifecycle development).

Understanding the capabilities and limitations of UML applied to the development of a broad range of everyday products (e.g., a portable CD player; traffic intersection) is a prerequisite to abstracting multiple discplines to properly annotated information representations, and allowing for communication among disciplines and multiple contextual views.

To this end, a medium-term goal is exploring uses of UML in systems composed of software and hardware, definitions of system requirements, logical models (i.e., models that do not commit to an implementation technology). physical models, and models amenable to reuse.

TABLE OF CONTENTS

  1. Visual Modeling with UML
    Purpose : Explain role of visual modeling languages, particularly UML, in representing the behavior and structure of engineering systems.
    Topics : Importance, history and uses of UML; Object-Oriented Concepts; Elements of UML; Engineering System Development with UML.

  2. Representing System Functionality with Use Cases
    Purpose : Explain how use cases can describe system functionality.
    Topics : Textual use cases; Use case diagrams (describing user requirements);

  3. Simplified Models of System Structure
    Purpose : Explain how UML diagrams can model system structure.
    Topics : Specifying Classes; Identifying Relationships among Classes; Creating Object and Class Diagrams;

  4. Simplified Models of System Behavior
    Purpose : Explain how UML diagrams can model system behavior.
    Topics : Sequence and Collaboration Diagrams; Elements of Real-Time Systems; Common Mistakes.

  5. Modeling State-Dependent System Behavior
    Purpose : Explain how state machines can capture logical and state-dependent system behavior.
    Topics : Statechart Diagrams (Capturing state-dependent behavior); Activity Diagrams (Specifying behavioral logic).

  6. Extensions to Standard UML
    Purpose : Explain extensions to standard UML needed to assess performance of engineering systems.
    Topics : Adding Properties with Tagged Values; Extending Semantics with Constraints; Object Constraint Language (OCL).

  7. Databases and Visual Modeling Tools
    Purpose : Explain capabilities, benefits and limitations of commerial visual modeling tools.
    Topics : Development Objectives; Commercial Visual Modeling Tools.

  8. Questions and Exercises

  9. References and Web Resources

Visual Modeling with UML

Visual Modeling Formalisms and Benefits

Visual modeling formalisms map real-world products and processes to a graphical representation or blueprint. These formalisms use symbols to represent real-world entities.

Task Modeling Formalism
Architecture and Design Visual Modeling Languages
Calculations Algebra
Algorithms Programming Languages

Table 1. Appropriate Modeling Formalisms for Engineering Development

Fundamentally, the visual modeling languages are concerned with capturing, communicating, and levering knowledge. See Table 1. The information and knowledge needed to accomplish these goals need not be as complete or precise as needed for algebraic calculations for mathematical algorithms.

Visual modeling languages achieve these goals, in part, with mechanisms for displaying modeling elements in many different ways -- specific viewpoints tend to emphasize some aspects of a system, and push others into the background -- and at multiple levels of detail/abstraction.

Hence, systems engineers can employ visual modeling languages for the capture and representation of business and engineering processes, and the preliminary representation of system architectures.

Challenges

The challenges for visual modeling of engineering systems stem from the rapidly increasing size and complexity of systems that must be developed, and the range of modeling activities (e.g., models of system structure and behavior) that must be supported.

Because no single person can possibly understand every aspect of the design, a general understanding of the system will be spread across a team. Languages are needed for:

These problems are not new. Well known problems in traditional engineering system development and communication among project stakeholders include:

Carefully designed procedures are needed to keep the complexity of system development in check. Sources of complexity include: distributed systems; changing and uncertain requirements; critical performance requirements; new and emerging technologies; the need to integrate new/emerging technologies with legacy systems.

This goal can be achieved in part through "..a separation of concerns" to the systems engineer and through the use of abstraction to make sub-processes as simple as possible (Oliver). Another mechanism for keeping the complexity of system development in check is traceability -- between customer requirements and requiremnts allocated to the system design/architecture.

Introduction to UML

What UML tries to do?

UML provides a domain-neutral representation of engineering system products and processes. The home of UML lies in the development of computer software, and historically, software development techniques have been considered separately from hardware development.

A little history

Insert graphic for versions of UML development ....

[History UML versions]

UML usage.

Few restrictions are placed on UML's usage -- in fact, it applies to a multitude of different types of systems, domains, and methods or processes.

The UML syntax that is simple enough for practitioners and end-users to learn and understand in a short time, and yet, provides a more rigorous definition of syntax and semantics than most of its competitors (Meilich, 2001).

UML is the de-facto standard for the development of SW with broad application ranges. UML enables the capturing, communication, and leveraging of strategic, tactical, and operational knowledge to facilitate increasing value by increasing quality, reducing costs, and reducing time-to-market while managing risks and being proactive in regard to ever-increasing change and complexity. Within a system-intensive process, a method is applied as a process to derive or evolve a system.

The most recent version of UML (i.e., UML 2.0) improves its suitability for real-time systems, allowing for standardized interpretations and analysis as relevant for embedded systems. Together with its stereotyping features, UML has the potential to unify the still rather distinct communities of hardware and software design, enabling true system design.

What UML does not try to do?

What UML is not:

Fundamentally, the UML is concerned with capturing, communicating, and levering knowledge.

The Elements of UML

The essential ingredients of UML are as follows:

Synthesis of Models for System Structure and System Behavior

In the OO development process with UML, architectures are created by systematically considering both the system behavior and structure.

[Relationships-Things-Behavior]

and a series of diagrams to capture required system functionality, system behavior, and system structure.

The building blocks are as follows:

  1. Things and Events

    As engineers, we are interested in developing system requirements and creating models of engineering systems that will eventually be built and used. The elements and behavior of these engineering systems are the "things" or "objects" we care about.

    The concept of distinguishable objects is one of the most fundamental notions of humanity. Several aspects of objects are used to describe or specify them (Oliver, 1997):

    1. Name of the object;
    2. All the properties of the object that are important for the problem of current interest;
    3. All the tasks, actions, or functions that are to be performed by the object for the problem of current interest;
    4. All the inputs that the object accepts and outputs it generates;
    5. How to connect the object (i.e., its interfaces);

    An event is an occurrence at a specific time and place. Systems engineers need to plan for and react to the following types of events:

    A key challenge for systems engineers is identifying and tracing sequences of events caused by entities external to the system. Indeed, a useful catalyst for establishing system requirements is to ask the question "...what events occur that will affact the system being studied (or developed)?" Later in the design process, additional events are introduced with the creation of logical design alternatives and selection of technologies. Tables of events can be constructed for various aspects of expected system behavior.

  2. Relationships

    A relationship is a naturally occuring association among specific things. Because things (or objects) are built from things, we need a way to express (e.g., counting and enumerating) how things relate to each other and how things within the system are connected to the surrounding environment. The notion of interconnection provides a way of showing which parts are connected to each other, and which parts are not. Relevant concepts include:

    Interconnection Description Appropriate Formulation
    Context description How objects are connected to the external environment?
    Assembly description How objects are connected within the system boundary?

    Table 2. Types of Interconnection Relationships in Systems

    In formulating system relationships, we wish to meet the design specifications and understand how various design concerns can be separated (or assigned) to different objects (or subsystems) and collaborations among objects designed to meet a mutual goal. Ideally, the system should be loosely coupled and easily reconfigurable, and yet, not have operational performance that is severely degraded from optimal.

  3. Aggregation

    Systems are built from smaller subsystems; large objects are built from smaller objects. Aggregation allows use to consider an object as a unit, ignoring its parts, thereby simplifying our viewpoint of the system.

  4. Diagrams

    Diagrams are simply a graphical representation of some aspect of a system.

    [Pathway of OO Development]

Models of system structure and system behavior are supported through the following diagram types:

Major Area View Diagram
System Structure Static View Class Diagram
Use Case View Use Case Diagram
Implementation View Component Diagram
Deployment View Deployment Diagram
System Behavior State Machine View Statechart Diagram
Activity View Activity Diagram
Interaction View Sequence Diagram
Collaboration Diagram
Model Management Model Management View Class Diagram

Table 3. Classification of UML Diagrams for each Major Area

UML provides coverage for nearly all aspects of engineering system development, including, representation of system requirements, system structure, and system behavior.

Object-Oriented Concepts

The key elements of object-oriented development are as follows:

Object-Based Development of Engineering Systems

Representing System Functionality with Use Cases

Use Case Development

A requirements engineering process is characterised as a structured set of activities that are followed to create and maintain a systems requirements document. To obtain insight in this process, a description of the activities is needed, the inputs and outputs to/from each activity are to described, and tools are needed to support the requirements engineering process.

In UML-driven development the generation of system requirements through use case modeling activities proceeds as follows:

[Use case Management]

Figure 2. Pathway of development for use cases

User requirements are developed in an iterative process involving elicitation of goals and scenarios, identification of high-level system objects, and generation of system requirements. This process needs to take into account viewpoints of the project stakeholders, define a system vocabulary, and eventually, identify the domain objects and attributes.

Management of use cases should be viewed as akin to lifecycle management of requirements. Use cases need to be validated with users, and updated to mirror and reflect the changing needs of a project.

Prepare for Use Case Modeling

In a top-down approach to use case modeling, the activities are roughly as flows:

Perform Initial Use Case Modeling

Activities include:

Expand on Use Case Modeling

The outcome of initial use case modeling should be a conceptual picture of what the system will do. In this section we expand on use case modeling descriptions and map these descriptions to object models. Activities include:

Organize the Use Cases

Activities include:

Combining Top-Down and Bottom-Up Development

The top-down approach to use case model development assumes that enough is known about the system to provide a general description, and then decompose goals for system into detailed scenarios (i.e., snipets of system behavior).

[Development Pathways]

Figure 8. Top-down and Bottom-up Pathways of Development

In the bottom-up approach to use case development, scenarios are used to structure use cases (Amour, pg. 31). Scenarios are generated for so-called ideal behavior, and required alternatives to ideal behavior (i.e., what to do when something goes wrong). These scenarios can be organized into use cases corresponding to system goals.

Examples

Simplified Models of System Structure

Elements of System Structure

By definition, structure is an arrangement of parts, or constituent particles, in a substance or body (Merriam Webster, 1981). A description of the system structure should contain: (1) a list of the parts; (2) how the components are connected; (3) what portion of the total system behavior is carried out by each component.

Creating Object and Class Diagrams

The first thing you must do when building a static model of your system is find appropriate classes that represent the abstractions the problem domain represents. A step-by-step procedure for development is as follows:

  1. Identify the relevant classes, their attributes and operations. These can come from several sources, including the high-level problem statement, lower-level requirements and expert knowledge on the problem space.

  2. Sift through the classes and eliminate uncessary items. Look for classes that are redundant, irrelevant, vague, or fall outside the scope of the model.

  3. Where appropriate, organize classes into hierarchies. This requires decisions about generalization ("kind of" or "is a" relationships among classes).

  4. Determine associations -- that static relationships between pairs of classes -- among classes. These relationships should serve as a foundation of your static class model for the problem space.

Packages and Interfaces

Examples

Simplified Models of System Behavior

Elements of System Behavior

By definition, behavior is the way in which a organism, organ, or substance acts, especially in response to a stimulus (Merriam Webster, 1981). When we describe the behavior of the system itself, we consider scenarios of its use under various conditions (i.e., external events) and the systems response to the scenarios. The step-by-step process of creating a system can also be viewed as behavior.

[OO Behavior]

The basic abstractions used with behavior are function, the ordering of functions, and function inputs and outputs. Behavior models coordinate a set of what we will call steps. These are called states, actions, or subactivities in UML [2]. Such a specification requires that at least two questions be answered for each step: When should each step be taken? and When are the inputs to each step determined?

Use Case Instance Diagrams

While a use case provides a generalized representation of behaviors that will occur when a specific event happens, a use case instance examines how a specific instance of the use case will execute. Both types of use case have their benefits. Generalized use cases facilitate efficiency of description -- there is no need to document every single instance of a use case type. Instance use cases, on the other hand, can be used to draw out and add more detail to a use case flow of events.

To summarize, a use case instance complements use cases in a number of ways (see Amour, pg's 217-230):

  1. The provide a prototype for how a use case will execute in a given situation.
  2. They provide a means for drawing out and validating requirements from stakeholders.
  3. They provide a means for exploring the details, alternatives, and exceptions for use cases.
  4. They act as a transition to system test cases.

UML provides the <<instanceOf>> stereotype to show the relationship between a use case and a use case instance.

[Usecase Instance]

Here we see that use case instances need not stand alone -- rather, they are a specialized instance of the use case.

Sequence Diagrams [Sequence diagram]

For the simplfied modeling of engineering systems, sequence diagrams enable designers to perform the following key tasks (Bennet et al., 2001; Rosenberg):

  1. Allocate behavior among boundary objects, entity objects and controllers that will become full objects in the system model.

  2. Show the detailed high-level interactions that occur over time among the objects associated with each use case scenario (i.e., they show how messages pass between objects to satisfy a use case). One sequence diagram can encompasse the basic and alternative courses of action within each use case.

  3. To model generic interactions (showing all possible paths through the interaction) or specific instances of interaction (showing only one path through the system).

  4. Finalize the distribution of operations among classes.

A complete system description is likely to contain a hierarchy of sequence diagrams. At the root, the initial sequence diagram should have only a single system instance, plus the (minimal) necessary actors needed to focus attention on the top-level interfaces with the outside world. Each sequence diagram will contain text for the use cases (shown down the left-hand side of the diagram), objects, messages and methods.

How to Create a Sequence Diagram

The step-by-step development procedure is (roughly) as follows:

  1. Define Context of Sequence Diagram.

    Like collaboration diagrams (see details below), sequence diagrams can model interactions at the system, subsystem and module levels.

  2. Identify Objects

    During the requirements analysis, you can develop a first-cut estimate of the objects that can accomplish the desired behavior with the use cases. Objects should be partitioned into boundary, entity and control objects, thereby determining what objects are responsible for each bit of behavior.

  3. Draw Instance Diagrams.

    Instance sequence diagrams are created as follows: 

     -- Lay out the objects from left to right.
 -- Beginning with the message that starts the interaction, lay out
    the messages down the page from top to bottom. The messages
    necessary to explain the semantics can also be shown.
 -- If it is required, add a focus of control to visualize nesting
    or a point in time where an activation takes place.
 -- If required, add timing constraints.
 -- If required, annotate the diagram with pre- and post-conditions.

    Repeat for each scenario.

  4. Consider Alternative Scenarios.

    The purpose of this step is to consider alternative paths through the system in response to abnormal inputs.

  5. Finalize the Distrubution of Operations among Classes

    Experience indicates that when the robustness analysis is complete, the static model should contain at least 75-80% of the attributes appearing in the logical design.

  6. Draw Generic Sequence Diagrams.

    In this optional step, and space permitting, alternative scenarios can be combined into a single, generic, sequence diagram.

Refining Sequence Diagrams to Match Object Models

Robustness analysis provides a sanity check by helping you make sure that the use-case text is correct and that you haven't specified system behavior that is unreasonable (or impossible) given the domain objects.

This process is facilitated with the classification of objects into boundary, entity and control objects. Actors use boundary objects to communicate with the system. Entity objects are usually derived from domain models, and control objects serve as the glue between boundary and entity objedcts. To perform robustness analysis for a use case, you walk through the use case text one sentence at a time, and drawing the actors, the appropriate boundary, entity objects and controllers, and the connections among the various elements of the diagram. The basic course and all of the alternate courses should fit on one diagram. Four basic rules apply (see adjacent diagram):

  1. Actors can only talk to boundary objects;
  2. Boundary objects can only talk to controllers and actors;
  3. Entity objects can only talk to controllers;
  4. Controllers can talk to boundary objects and entity objects, and other controllers, but not to actors.

Keep in mind that both boundary objects and entity objects are nouns. Controllers are verbs. Nouns cannot talk to other nouns, but verbs can talk to other verbs and nouns. A reviewer should be able to read a course of action in the use case text, and trace the associations along the diagram, making a clear match between text and pictures. The use case text may need to be reworded several times before this match can be established.

Collaboration Diagrams [Collaboration diagram]

A collaboration diagram represents interactions among objects. The diagram shows one instance of an interaction, in which objects take on roles necessary to perform the computation. These interactions can specify the implementation of a method, all methods in a class or, perhaps, in a use case.

Collaboration diagrams are a useful means of communication and project documentation at several stages of the development lifecycle. Key uses of collaboration diagrams include (Bennet et al., 2001):

  1. Early in the development lifecycle, collaboration diagrams can be developed concurrently with class diagrams. In this case, the objects participating in each use case can be modeled in a collaboration diagram. Objects may then be assigned to classes, which later on, can be organized into class hierarchies.

  2. After the classes are known, collaboration diagrams can document the interactions that will take place during the realization of use cases.

How to Create a Collaboration Diagram

For each of these situations, the step-by-step development procedure is (roughly) as follows (Bennett et al. pg. 163):

  1. Define Context of Collaboration Diagram.

    Collaboration diagrams can model interactions at the system, subsystem and module levels.

  2. Identify Structural Elements.

    The first real step is to determine the structural elements that will participate in the collaboration. Possibilities include interface elements, control elements, classes and objects.

  3. Create Models of Structural Elements.

    In this step, associations between classes (and other structural elements) are added to the collaboration diagram. When a class participates in more than one association, clarity of the collaboration diagram can be improved by stereotyping the message interactions.

  4. Consider Alternative Scenarios.

    In many engineering systems, the evolution of an interaction will depend on the system state and details of the system input. Alternative scenarios should consider the different ways in which an interaction might develop.

  5. Draw Instance-level Collaboration Diagrams.

    An instance-level collaboration diagram shows the object instances participating in the collaboration. At this point, the class to which the objects will belong may not be completely defined.

  6. Draw Specification-level Collaboration Diagrams.

    Instance-level collaborations are combined into a single specifcation-level diagram, which shows the alternative paths on a single diagram. Object instances (in the instance-level diagram) are replaced by class roles.

Sequence Diagrams versus Collaboration Diagrams.

Sequence and collaboration diagrams serve almost the same purpose (i.e., they both show how objects collaborate together and the messages exchanged among them to achieve a purpose). But they accomplish their purpose is slightly different ways:

  1. Collaboration diagrams. Show the structural relationships between the class roles in terms of association nodes or links and they show the order of the interaction textually (using sequence numbering in the messaging). Collaboration diagrams do not show information about timing constraints.
  2. Sequence diagrams. Represent some of the same information, but not all. They show object instances that play the roles in the collaboration. However, they do not show the structural relationships among the objects. They show the order of the interaction by using a vertical axis of the diagram to represent time.

Hence, when some computer software programs try to automatically convert sequence diagrams to collaboration diagrams (and vice versa), invariabley, some information is lost.

Activity Diagrams [Activity Diagram]

An activity diagram represents sequences in which activities may occur, just like the well known flowchart diagram, However, strangely, an activity diagram includes no activities -- the entire diagram is considered to represent a single activity. Instead, it is composed of "action states" each of which is a collection of happenings that achieve the result of interest. When an action state finishes, one or more successor action states begins. Several action states may run concurrently.

How to Create an Activity Diagram

Activity diagrams describe workflows. In the development of an engineering system, activity diagrams can describe the underlying processes comprehensively. To recap, the step-by-step procedure for creating an activity diagrams is (roughly) as follows (Bennett et al. pg. 221-);

  1. Find actors and system use cases.

  2. Identify key scenarios for system use cases.

  3. Combine scenarios to produce comprehensive workflows.

  4. Assign object flows to model key system entity behavior.

  5. Where appropriate, map activities in system areas to swimlanes.

Use Case/Component Interaction Diagram Matrix

A single system component may support the operation of multiple use cases. Conversely, a single use case may be supported by multiple system components. A convenient way of visualizing the role of components in the execution of use cases is through a use-case/component matrix. See the adjacent figure.

[UML Usecase Matrix]

A use case/component interaction matrix provides:

Examples

Modeling State-Dependent System Behavior

Elements of State-Dependent Behavior

The adjacent figure shows the overall, iterative, development process for state-dependent system behavior.

[OO Behavior]

Each iteration begins with a description of desired behavior, possibly expressed as a series of messages between objects in a sequence diagram, and ends with an equivalent description of the "as modeled" system. At the end of each iteraction, the "desired" and "as modeled" behaviors are compared.

A central component of this development process is state diagrams, which need to be developed for all object classes that have behavior. In this context, "desired" behavior is expressed in terms of sequence diagrams.

The use of executable models allows the architect to shift the focus of discourse with the customer from the architectural views to the behavior and performance that the architecture enables. (i.e., what the system will do and how will the system accomplish its purpose). Unfortunately, at this time there is no agreed-on computer-executable description of the work to be done in systems engineering, and the information that is captured and transformed along the way.

Capturing State-Dependent Behavior with State Machines

State machines provide a compact and predictable model of system behavior characterised by variables, methods, interactions, dependencies and constraints on sequences of message responses that a collection of objects can make.

What is a State Machine?

A state machine is a system whose output is determined by both current and past input. The effect of past input is represented by a system state (Binder, Chapter 7). State machines emphasize response to external stimuli by requiring that each step start only when certain events happen in the environment of the system. They de-emphasize the sequencing of steps by allowing this to be controlled by external events. Similarly, they de-emphasize the calculation of inputs to each step by doing it as part of the steps themselves. This makes state machines more suitable for applications that operate in response to their environment, as in real-time or embedded applications.

From a theoretical perspective, a state machine is an abstraction composed of events (inputs), states, and actions (outputs). A system is said to exhibit state-based behavior when identical inputs are not always accepted and, when accepted, may produce different actions (outputs). State machines are also called sequential systems -- and are said to have sequential behavior.

In software applications, statecharts (or state diagrams) are defined for individual instances of classes. Each object will get a copy of the state diagram (as a state machine) and implement the state machine independently from other instances of the class.

Building Blocks

A state machine has four building blocks:

A transition takes a system from one state to another. State machine mechanisms have several steps:

  1. The machine begins at an initial state;
  2. The machine waits for an event for an indefinite interval;
  3. The event presents itself to the machine;
  4. If the event is not accepted in the current state, it is ignored;
  5. If the event is accepted in the current state, the designated transition is said to fire. The associated action (if any) is produced and the state designated as the resultant state becomes the current state. The current and resultant states may be identical.
  6. The cycle is repeated from step 2, unless the resultant state is the final sate.

The challenge for the designer is to devise a model that correctly represents the behavior of the system under study.

Guard Transitions

A guard is a predicate expression associated with an event. A guarded transition cannot fire unless: (1) the system is in the accepting position for the transition; (2) the guard event occurs; (3) the guard predicate evaluates to true.

In UML, the guard expression is given in brackets following the event name. That is: 

    event-name argument-list '[' guard condition ']' / action-expression

State-Chart Diagrams

A state transition diagram is a graphic representation of a state machine. Nodes represent states. Arrows (directed edges) represent transitions. Annotations along the edges represent events and actions.

Statecharts were developed to model the control requirements of complex reactive systems (Harel 87, Harel 88). They can represent hierarchies of single-thread or concurrent state machines. An aggregation of states is a superstate, and the model within an aggregation is a process.

How to Create a Statechart Diagram

Statechart diagrams are not essential for all entities in a system -- just those that have reasonably complex behavior that can be modeled by a discrete set of states. The development procedure is as follows (see Bennett et al., pg's 242-244):

Note. While activity diagrams are good for describing processes, statechart diagrams are better suited to describing the time history of discrete states that an object (or system) can pass through.

Statechart Execution

Statechart execution is concerned with the sequencing of state-dependent aspects for a use case. Of course, changes in system state are likely to be accompanied by the passing of messages between objects, and so statechart execution should be considered together with execution of collaboration diagrams (see Gomaa, pg's 229-230).

Gomaa indicates that keeping both the statechart and collaboration diagrams simple and consistent can be a challenge, and so it pays to start out with simplified system representations and then add detail to a simplified representation that works.

State Model Validation

State models should be complete, consistent, and correct before they are used. Here is a checklist for the development of state models and state machines (due to Binder, 2001, pg's 238-241):

For a detailed discussion on the test procedures that can accompany these checklists, see Binder, 2000.

EXAMPLES

Extensions to Standard UML

Need for Extensions to UML

See paper by Ogren, 2000.....

Stereotypes

Adding Properties with Tagged Values

Extending Semantics with Constraints

Object Constraint Language (OCL)

Elements of Real-Time Systems

Foundation for Executable Use Cases

Show how scenarios can be manually executed using tools like Statemate.

Databases and Visual Modeling Tools

Relationship between UML and XML

There is a one-to-one correspondence between the visual format for UML and an extended markup language (XML) schema denoted XMI. This means that UML diagrams can be converted to their equivalent XML representations, and stored in either file or (XML) database format. The latter means that UML descriptions of engineering products/components and processes can be stored in company-wide databases and queried and reused on an as-needed basis.

[XML Business Model]

Figure 9. Reuse-Centric Development Method for Systems Engineering

The adjacent figure shows the role of reuse-centric components in an ongoing business. Business strategy identifies "what to do." Business process engineering identifies "how to accomplish" the business strategy goals using available technologies. The fusing of these two concerns is accomplished through carefully designed system architectures, which account for and balance organization, processes and technology (Fingar, 2000).

As functional requirements are passed through to the process engineering phase, a repository of previously developed models can be searched for processes that match the requirements. A shared repository of artifacts produced by the busines and systems modeling serves as a reference architecture (see the adjacent figure). The repository will contain standard representations of use cases. Use cases not only provide a compact way of capturing (and organizing) requirements, they also trigger later development steps in analysis, design, implementation and testing.

Commercial Visual Modeling Tools

Public Domain Visual Modeling Tools

Enabling Technologies

Questions and Exercises
  1. Details coming soon .....
  2. ...
  3. ...
  4. ....

References and Web Resources

  1. Alexander C. et al., A Pattern Language , Oxford University Press, New York, 1977.
  2. Armour F., Miller G., Advanced Use Case Modeling, Addison-Wesley, 2001.
  3. Broy M., "Toward a Mathematical Foundation of Software Engineering Methods," IEEE Transactions on Software Engineering, Vol. 27, No. 1, January 2001, pp. 42-57.
  4. Communications of the ACM., Issue on Software Patterns, October 1996, Vol. 39, No. 10, New York, 1996.
  5. D'Souza D.F., Wills A.C., Objects, Components, and Frameworks with UML : The Catalysis Approach , Object Technology Series, Addison-Wesley, 1999.
  6. Fingar P., "Component-Based Frameworks for E-Commerce," Communications of the ACM., Vol. 43, No. 10, October 2000, pp. 61-66.
  7. Gamma E. et al., Design Patterns: Elements of Reusabel Object-Oriented Software , Addison-Wesley, Reading, Mass., 1995.
  8. Gomaa H., Designing Concurrent, Distributed, and Real-Time Applications with UML, Addison-Wesley, 2000.
  9. Graham I., Object-Oriented Methods : Principles and Practice , Third Edition, Addison-Wesley, 2001.
  10. Harel D., Statecharts : A visual formalism for Complex Systems, Science of Computer Programming , Vol. 8., pp. 231-274, 1987.
  11. Herlea Damian D.E., Jonker C.M., Treur J., Wijngaards N.J.E., A Formal Knowledge Process Model of Requirements Engineering , Published in KAW-99, 1999.
  12. Harel D., On Visual Formalisms, Communications of the ACM , Vol. 35, No. 5., pp. 514-529, May, 1988.
  13. Heineman G.T., Councill W.T., "Component-Based Software Engineering," Addison-Wesley, May, 2001.
  14. Larman C., Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design , Prentice-Hall, 1998.
  15. Martin G. and Salefski B., "System Level Design for SOC's : A Progress Report, Two Years On," In System-on-Chip Methodologies and Design Languages, Edited by: Ashenden P.J., Mermet J.P. and Seepold R., Kluwer Academic Publications, 2001.
  16. Meilich A., Friedenthal S., Lykins H., "Object-Oriented Systems Engineering," Notes from Tutorial Program F6, INCOSE 2001, Melbourne, Australia, July 2001.
  17. Ogren I., "Possible Tailoring of the UML for Systems Engineering Purposes," Systems Engineering , Vol. 3, No. 4, pp. 212-224, 2000.
  18. Rawson J., and Sangiovanni-Vincentelli A., "Interface Based Design," Proceedings of the Design Automation Conference, June 1997.
  19. Rowlett T., The Object-Oriented Development Proces , Prentice-Hall, Upper Saddle River, NJ 07458, 2001.
  20. Satzinger J.W. et al., Systems Analysis and Design in a Changing World , 2000 Course Technology, a division of Thomson Learning, 2000,
  21. The Patterns Handbook : Techniques, Strategies and Applications , Collected and Introducted by Linda Rising, SIGS Reference Library. Cambridge Press, 1998.

WEB RESOURCES

  1. Use Cases Organization
  2. The Use Case Zone
  3. Visio Professional/Enterprise 2000
  4. Download a demo copy of the Rational Software
  5. Here's a UML freeware tool : Rhapsody Modeler
  6. UML Design Center at Software Development Magazine ....
  7. The Road to UML 2.0 : Fast Track or Detour
  8. Sequence Diagrams: One Step at a Time
  9. Snapshot of a UML Tool GDPro 5.0 : GDPro 5.0 surges ahead with new Java features and support for innovative modeling approaches.

Developed in February 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin, Institute for Systems Research, University of Maryland