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:
The tutorial does not cover:
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.
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 |
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:
Models of engineering systems need to support a common OO notational format.
In the past, requirements have been rather informal, leading to ambiguities and an inability to enforce and test critical requirements.
Lack of flexibility means that systems cannot always readily adapt to changing requiremnts.
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 ....
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:
These are the fundamental modeling concepts and semantics.
For the visual rendering of model elements.
These are idioms for usage provides by the systems development community.
In the OO development process with UML, architectures are created by systematically considering both the system behavior and structure.
and a series of diagrams to capture required system functionality, system behavior, and system structure.
The building blocks are as follows:
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):
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:
These are events that occur outside the system boundary. For most systems, external events trigger a set of actions the system must response to.
These are events that occur as the result of reaching some point in time.
A state event occurs when something happens inside the system that triggers the need for processing.
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.
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? |
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.
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.
Diagrams are simply a graphical representation of some aspect of a system.
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 |
UML provides coverage for nearly all aspects of engineering system development, including, representation of system requirements, system structure, and system behavior.
The key elements of object-oriented development are as follows:
In object-oriented development of engineering software and systems, the basic units of construction are objects, organised into classes with common features. Put another way, objects derive their features from classes, which in turn derive their features from more abstract ones up through a hierarchy (and network) of classes.
The features can be of three kinds:
Well designed objects employ the principle of information hiding -- that is, the details of implementation is a model should be hidden, when it is viewed from for a particular purpose (e.g., from a user's perspective). Information hiding is a special case of abstraction.
A class is a collection of objects that share common attributes and methods,
which together define the common behavior of the family of objects. In object-oriented programming, a class can create and instance of itself (i.e., this ia an object), which inherits exactly all of the features of the class.
Classes and objects by themselves are not enough to characterize requirements or design the system. We also need relationships among classes.
Figure 1. Association and Link Relationships
Links and associations establish relationships among entities within the problem world or the solution world.
Typically, only two classes participate in an association. A class can be associated with itelf.
Note. An engineering system composed of hardware and software elements should be thought of as an assembly of objects -- objects may be instances of a class. A class, on the other hand, is a specification an object's behavior and structure. To facilitate resuse of concepts and ideas, classes may be organized into hierarchies. The most general concepts are pushed to the top of the hierarchy. Concepts specific to a particular problem domain are represented in classes appearing lower in the class hierarchy.
Encapsulation involves the packaging of representations for a subject in a world. The goal is self-contained representations that package datalike and processlike elements together into modules, which will facilitate complex systems development.
Encapsulation and abstraction techniques can be made to work together, by hiding the internal details of the module's operation (e.g., its data structures and methods of implementation), and providing clear specifications for what an entity is and does, and how it should be used. As a result, the only way to access an object's state is to send it a message that causes one of the object's methods to execute.
An object's interface can best be regarded as a public declaration of an object's resposibilities.
Note. Modern approaches to object oriented analysis are composed of state models for individual objects. By grouping logically related constructs together, encapsulation also promotes increased cohesion of system modules, and allows for decreased coupling in the synthesis of system assemblies. At the system level, communication among objects occurs through message passing among objects, which in turn, cause changes to the internal state of an object. This approach to problem solving requires developers to adapt a control flow model that is influenced from moment to moment by events (Graham, 2001).
A generalization association is a class attribute whose value is the list of classes (or types) that the class inherits features from (see Graham, pg 255). Diagrams of these associations are called inheritance structures.
Inheritance structures allow you to capture common characteristics in one model artifact and permit other artifacts to inherit and possibly specialize them. This approach to development forces us to identify and separate the common elements of a system from those aspects that are different/distinct. The commonalities are captured in a super-class and inherited and specialized by the sub-classes.
Inheritance structures are the reflection of a fundamental approach to system development. To keep the development of complex systems managable, it is highly desirable to design system structures that localize behavior, thereby also localizing the need (and simplifying) for system maintenance.
To get this benefit, we insist that the system interfaces never change, and that modifications be made by introducing subclasses that extend and possibly override the features of existing objects. Any deviation from this approach constitutes a major architectural rewrite of the system.
This rule also implies that classes must be explicitly designed for extension. Instances of a class (called objects) inherit all of the features of the classes they belong to. What's really cool is that inherited features may be overridden with extra features designed to deal with exceptions.
Example. The adjacent figure (Meilich, 2001) shows a hierarchy of temperature sensors. The generic temperature sensor, shown in the super-class, contains attributes for the temperature, the sensor weight, and mean time before failure (MTBF) of the sensor itself. Methods are provided to monitor, reset and test the sensor status.
Application specific "air temperature" and "water temperature" sensors are developed through extension of the general temperature sensor. For the water temp sensor, an additional field stores the depth at which a temperature is recorded.
Single and Multiple Inheritance Structures
Object-oriented development supports both single and multiple inheritance structures. In single inheritance, each class has at most one generalization (superclass). Multiple inheritance occurs where an object has more than one parent class. That is, the object inherits properties from multiple parents. For this most part, the definition of new entities through multiple inheritance will work just fine -- however, a potential downside of multiple inheritance is the potential for operations/attributes from parents that are fully/partially contradictory.
In the adjacent figure, the class People is a generalization of Customers and Children. Since Customers and Children are both extensions of People, the upper part of the diagram demonstrates the mechanism of single inheritance. The lower half of the figure shows how the class Young Customers inherits properties from both Children and Customers. This is an example of multiple inheritance.
Not all structural relationship involve inheritances, and practical object-oriented development methodologies need to deal with composition and aggregation associations, where there is a whole-part relationship between instances of a type. Aggregation is a special type of association, indicating how classes are included in, or used, to build other classes.
However, care is needed to distinguish the two cases. As pointed out by Binder (Binder, 2001, pg. 257), good test for whether a relationship is a composition relationship is to ask the question:
If the part moves, can one deduce that the whole moves with it in normal circumstances?
For example, among other things, a car is composition of wheels and an engine. If you drive the car to work, hopefully the wheels go to!
In UML, composition and aggregation are represented by filled and empty diamonds, as shown in the adjacent figure.
In UML, the empty diamond of aggregation designates that the whole maintains a reference to its part, so that the whole may not have created the part.
Multiplicity
Multiplicity indicates the number of objects participating in a particular instance of an association. The multiplicity can be one (1), optional (0..1), zero or more (*), one or more (1..*), or numerically specified (m..n), where m and n have numeric values.
Multiplicity is not used in generalization associations.
Polymorphism means the "quality or state of being able to assume different forms" [Webster]. In object-oriented systems development, polymorphism means that an object (entity, property, or service) may assume different forms while relating the same essential properties.
In software engineering circles, a common manifestation of polymorphism is through operator overloading. That is, the same symbol is used for a variety of purposes when the context is clear.
Object-Based Development of Engineering Systems
Tasks in the systems engineering development lifecycle pass through the phases of requirements engineering, systems architecting and design, evaluation and ranking of design alternatives, optimization and trade-off and, finally, validation and verification.
Here's how the UML diagrams fit together ....
Task | Appropriate UML Diagrams |
Gathering and Representing Requirements | Use Case Diagram |
Simplified Modeling of System Behavior |
Sequence and Collaboration Diagrams |
Modeling System Structure | Class Diagrams |
Modeling State-Dependent System Behavior |
Statechart Diagrams |
Validating System Performance |
Object Constraint Language (OCL) |
Diagram Type | Diagram Elements |
Use Case Diagram | Actors, use cases, associations, system-level functions. |
Class Diagram | Classes, instances of classes (objects), class relationships (aggregation, specialization, association), packages, interfaces. Class operations. |
Sequence and Collaboration Diagrams | Instance (objects), events and messages. Object operations can be specified as a function of event/message receipt. |
Statechart Diagram | State transitions, Rules embeded in individual transitions and also state-transition topology. |
Component Diagram | Components, packages ... etc. |
Deployment Diagram | Processors, devices, connections (communication links). |
Usually, an iterative and incremental development cycle is needed to develop a system description. Each iteration of developoment will advance our understanding of the system's scope and desired behavior (represented by a collection of use cases). The system architecture will be incrementally refined to accomodate these needs, as shown in the figure below:
Generally speaking, each iteration will require consideration of system behavior, system structure, and possibly, detailed state-based consideration of a system module. The development procedure is roughly as follows:
In the first iteration of this process, the actors and system may be viewed as a monolithic entity. Subsequent iterations will decompose one or more objects on the sequence and class/object diagrams, defining more elaborate detail behavior for sequence diagrams describing detailed behavior for an object contained within the system.
After these steps have been worked through, it can be useful to validate the work accomplished to date. The challenge here is management of complexity -- manually evaluating the correctness and consistency of anything but the smallest architectural model can be exceedingly labor-intensive. Validation procedures can be streamlined with executable models of the system architecture and/or procedures for automated execution of system behavior.
How to design executable models of high-level system archtectures that accurately reflect the proposed system structure and desired system behavior. To avoid undesirable risk of executable model configuration, the translation process from "simplified model of behavior and structure" to "executable model of the system architecture" needs to be automated. The generation of an "executable model" should be efficient enough to allow for an iterative cycle.
To complicate matters, traceability links between the simplified and executable models need to be maintained. These links provide a pathway for tying decisions based on performance of the executable model back to the simplified behavior/structure system.
Insert schematic showing tradeoff in "semantics" versus "opportunity for reuse".....
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:
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.
In a top-down approach to use case modeling, the activities are roughly as flows:
Each stakeholder in a project has his/her needs and perspectives. The different attributes of a system (e.g., requirements, schedule, budget, technical performance) are of concern to different categories of stakeholders.
Stakeholder | Benefits of Use Case Model |
Customer |
|
User |
|
Project Manager |
|
System Architect |
|
System Developer |
|
The adjacent table is adapted from Table 6-1, pg. 75 of Amour. For a system design to be successful and cover all the required functionality, it is critical that each stakeholder be involved in the use case modeling. And beyond that, a drop-or-two of imagination doesn't hurt either.
Domain modeling task of discovering real-world things and concepts (i.e., classes, objects) related to the problem that a system is being designed for. It is, therefore, closely aligned to use case modeling.
The domain model serves as a glossary that writers of use cases can use in the early stages of that effort. Domain objects also allow us to connect use cases to static and dynamic models of the system. For ease of handling, domain objects can be classified as follows:
A process framework provides common definition, data and products that will result from elicitation and modeling of the requirements. Downstream, models of user requirements will be traced to models of the system architecture.
Perform Initial Use Case Modeling
Activities include:
Finding Actors. An actor is anything that interfaces with the system externally (e.g., a person, organization, software, or another system), and in some way participates in the use case story. Typically, an actor will either stimulate the system with some kind of input, or, receive output from the system. And each entity outside the system may be represented by multiple actors (because the entity may play more than one role with respect to the system interaction).
Actors can potentially come from a wide array of sources, including:
Use Cases. A use case describes a single goal and all the things that can happen (i.e., scenarios) as the user attempts to reach that goal.
-- Use Case 1 -- Working scenarios .... -- Working scenarios .... -- Use Case 2 -- Working scenarios .... -- Working scenarios .... -- Use Case 3 -- Working scenarios .... -- Working scenarios ....
Although use cases are neither requirements nor functional specifications, they imply requirements, objects, and object interactions and interfaces in the stories they tell.
As we will soon see, individual working scenarios can be textual, or defined graphically in UML as activity or sequence diagrams. Note -- activity diagrams can capture the conditional and iterative nature of a scenario. Sequence diagrams cannot.
The family of working scenarios should be complete enough to exercise all of the external systems (actors), and to cover normal and exceptional working behavior.
A use case specification should answer the following questions:
And it may also contain:
By focusing on actors and use cases early in the development life cycle, we are directing our attention to "what the system will do" instead of "how will the system be built."
Use cases are textual descriptions of the interaction between external actors and a system. Use case diagrams are graphical depictions of the relationships between actors, the use cases, and between a use case and other use case. Use cases drive not only requirements development, but the whole systems engineering process.
The adjacent figure shows the essential components of a use case diagram.
Each actor is represented by a stick figure (see the adjacent figure). (an actor can also be a special type of class, distinguished by the << actor >> stereotype.) Use cases are contained within ovals, and the system is drawn as a rectangular box. Packages, another form of container, can also hold use cases and/or actors. Arrows indicate which actor is involved with which use cases. The direction of an arrow (an optional feature in UML) can also indicate the direction of information flow. It is important to note that an individual use case may have more than one actor. Conversely, a single actor may participate in multiple use cases. A collection of use cases is known as a use case model (Ambler, 1998).
System Boundary
By definition, a use case describes the interaction of actors with a system. Because the actors are always external to the system (by definition), an important task is identification of an implementation interface that accepts and transports external imputs and system outputs.
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:
Click here for guidelines on creating domain models.
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:
A use case template defines the structure of the use case body for all of the use case developers on a given project. While this may be difficult to standardise, it is expected to cover:
An expanded template would include:
Use Case Name | Provides a unique identification |
Iteration | ...... |
Primary Actors | Names of the primary actor or actors who interact with the system. |
Basic Flow of Events | Activities and interactions performed when the use case is performed (or executed). |
Alternative Paths | Alternative (or exceptions) that may occur within the flow of events. |
Exception Paths | Exception paths, like alternative paths, show uncommon processing. They show the interactions that take place when an actor provides invalid input. |
Extension Points | Extension points describe relationships among use cases. The <<extend>> relationship exists between two use cases when one use case provides an operational sequence of events that is included in the other use case. The extension points show the steps in a use case from which the extending use cases extend. |
Triggers | Triggers describe the entry criteria for the use case. They are a list of conditions you expect to be true when the use case is activated. |
Assumptions | In this section, a project manager documents things you assume to be true, but in fact, might not be true. |
Preconditions | Preconditions represent the state of the system when the use case is triggered. |
Postconditions | Postconditions represent the state in which the use case leaves the system. |
Related rules | ...... |
Author | ...... |
Date | ...... |
Relationships are used to link two elements (e.g., use cases, actors, or packages) in a use case diagram. For example, a use case may incorporate one or more other use cases, or perhaps, may be a kind-of some other use case. These relationships are denoted:
To avoid an excessive number of use cases, extended use cases should be reserved for significant optional behaviors (not just exceptions to normal behavior).
Include relationships provide a means for capturing and separating out commonality among use cases, and improving readability of the use case model.
and graphically drawn:
Figure 3. Use case <<extend>> and <<include>> relationships
The extend and include relationships may be applied to use cases. In the adjacent figure, use cases B and C provide extended behavior to the base use case A. Similarly, use cases E and F include the flow of event captured by use case D.
An actor may inherit behavior from another actor using the generalization relationship.
Example 1. In a three-way telephone call, the originator calls the first person using a basic call procedure, puts that person on hold, and then uses the same basic call procedure to call the second person, thereby establishing the three-way telephone call.
Figure 4. Use case relationship for three-way and regular call procedure
Hence, the use case "three-way telephone call" is considered to be an extension of "basic telephone call." Whether or not "three-way telephone call" will be executed depends on the details of the call being established.
This example is also interesting in that "three-way telephone call" requires an additional actor -- the third participate in the three-way telephone call.
Example 2. An include relationship allows a use case to access access as set of behaviors defined in another use case.
Figure 5. Include Use case relationship
Here, the use case "perform credit check" is included in both the "submit load request" and "offer line of credit" use cases.
In this section we map use cases to object models. The former are a representation of system behavior, providing project participants with ability to view the relationships and interactions of the components from different external viewpoints.
Object models, on the other hand, consider the "things" that need to be captured, arranged and connected for the system to work (see Amour, pg's 195-216). Two key enablers in the development of object models are "partitioning" and "abstraction."
For stakeholders to have a clear understanding of what the system will do, and how it will accomplish its purpose, they need both use cases and object models.
Domain Object Modeling. A domain object model provides a high-level conceptual picture of the "domain" or environment in which the system will operate. Domain object can be classified as follows:
Domain objects also allow us to connect use cases to static and dynamic models of the system.
Analysis Object Modeling. Analysis object modeling adds more detail to the objects, and is driven by detailed system requirements. The result is an integrated view of the system development encompasing:
The use case and object modeling activities need to proceed in a concurrent and iterative manner, with adequate time being allowed to ensure the implementation is truely object oriented (not just a functional implementation with objects). At each step in the development, a checklist to keep in mind is (Amour, pg. 200):
An inevitable byproduct system development is the discovery of new use cases, not originally identified in the conceptual states of design. Perhaps these use cases will correspond to behavior uncovered by a detailed engineering analysis?
The use case model will need to be adjusted to account for the discovery of new use cases. And there are two common cases (Amour, pg 130):
A single use case should be divided into multiple use cases if major parallel or alternative processes are discovered in the use case's flow of events.
Sometimes a single use case represents a long sequence of behaviors involving many actors. At closer inspectionk, it may be possible that two use cases are occurring sequentially in the one flow. Key indicators of this possibility include:
If the answer to any of these questions is yes, perhaps the use case should be divided!!
Activities include:
In most complex systems, some use cases will depend on other use cases. Understanding the relationship between use cases is an important prerequisite to connecting them together to perform higher-level (or bigger) system process. These relationships are called dependency streams.
Thinking about individual use cases in this way can lead to the creation of use case graphs, where the post conditions in a use case are matched with the preconditions of the use case successor. As an aid to establishing dependency streams, consider the following issues:
Of course a variety of mismatches can occur. For example, the post condition in a use case might look like it matches the pre condition of a second use case, but not quite. Perhaps the mismatch can be resolved by reworking the use case definitions? Another cause of possible mismatch may be use cases defined at different levels of abstraction -- again, reworking the use case might resolve the mismatch.
Example 1. The adjacent figure shows
Figure 6. A simple use case dependency diagram.
a simple use case dependency relationship where "Use case B" depends on the successful completion of "Use case A." For the dependency to make sense, at least part of A's post condition should match B's precondition. When use cases are mapped to object models later in the development, these pre- and post-conditions will highlight the need for a clean interface design between object modules.
Note. The directed line points to the use case that has the dependency on the other use case (the reverse of usual UML notation).
Example 2. The adjacent figure shows
Figure 7. Dependency diagram to obtain research funding.
the flow of activites needed to develop, electronically submit, and win funds for research activities. To illustrate how hierarchies of use case can be developed, the research proposal submission process is expanded to account for lower level tasks (e.g., submitting the body of the reseach proposal itself, and the supporting documents).
Note. Schematics of Use case dependency can also be drawn as activity diagrams.
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).
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
This high-level use case describes the process of a customer purchasing gas/petrol at a gas station. We assume that he customer pays a cashier for the gas/petrol before pumping it.
=============================================================================== Use Case : Buy Gas/Petrol Actors : Customer, Owner Description : A driver pulls into a gas station, pays the owner for gas/petrol, fills his/her vehicle, and then drives away. ===============================================================================
Expanded use cases could include:
Use Case : Paying the owner/cashier with cash. Use Case : Paying the owner/cashier with credit card. Use Case : Customer pulls into a self-serve pumpl. Use Case : Customer pulls into a full-service pump.
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:
Packages and Interfaces
Add material later .....
Add material later .....
Add material later .....
Add material later .....
Examples
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.
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):
UML provides the <<instanceOf>> stereotype to show the relationship between a use case and a use case instance.
Here we see that use case instances need not stand alone -- rather, they are a specialized instance of the use case.
Sequence Diagrams
For the simplfied modeling of engineering systems, sequence diagrams enable designers to perform the following key tasks (Bennet et al., 2001; Rosenberg):
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:
Like collaboration diagrams (see details below), sequence diagrams can model interactions at the system, subsystem and module levels.
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.
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.
The purpose of this step is to consider alternative paths through the system in response to abnormal inputs.
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.
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):
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
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):
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):
Collaboration diagrams can model interactions at the system, subsystem and module levels.
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.
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.
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.
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.
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:
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
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-);
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.
A use case/component interaction matrix provides:
Examples
Elements of State-Dependent Behavior
The adjacent figure shows the overall, iterative, development process for state-dependent system 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:
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.
After a flat statechart has been developed, it is often useful to look for ways to simplify the statechart by developing a hierarchical statechart (see Gomaa, pg's 210-211). The key is to look for states that can be aggregated because they constitute a natural superstate.
Statecharts can also represent concurrent substates, as shown by the examples in the UML diagram notation and semantics tutorial.
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):
The discovery of entities for state-based modeling can be partitioned into two phases. From an analysis perspective, modeling entities include the actors that the engineering system interacts with, and the surrounding systems that may have changing state. At the design level, system interfaces and boundaries may need to manage transactions. These too are also suitable candidates for state-based modeling.
The first issue to consider is "how is the entity created?" (i.e., what is the system's initial state?) Then, how is the entity destroyed? (i.e., the system reaches a final state where it no longer needs to be processed by the system).
The primary source of events for objects is the use cases.
Beginning with the inital state, we need to ask what events will affect the initial state. These events will move the system to one or more intermediate states, which may operate in parallel. This process is repeated until the system state returns to an end (or final) state.
An entry action corresponds to the task that will initiate system processing. An exit action is a signal indicating that the system has reached its final state, and no further processing is required.
To further elaborate up the state behavior, system states can be decomposed into substates having their own (detailed) state-dependent behavior.
This phase of development links the state-based actions to the operations that can be performed by the system structure. We need to ensure that the latter supports the former.
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):
This list gives criteria for correct construction. Check that:
Weak, ambiguous or inappropriate state names are often symptoms of misunderstood behavior or requirements. Check that:
The guard checklist gives criteria for checking the logic and structure of guarded transitions. Check that:
State machines organized into a hierarchy need to be free of level-to-level conflicts. Many problems can be avoided by checking that:
To ensure safe and correct behavior under failure conditions and degraded operations, check that:
For a detailed discussion on the test procedures that can accompany these checklists, see Binder, 2000.
EXAMPLES
Need for Extensions to UML
See paper by Ogren, 2000.....
Stereotypes
<<interface >> <<type>> <<capsule>>
Stereotypes can be added to classes, associations and operations, use cases, packages and so forth. Actors are just objects tagged with an
<<actor>>
stereotype. Stereotypes make the UML language extensible, adding extra meaning to the basic pieces of the syntax, while preseving communication between elements of the model (see Gomaa, pg's 24-25).
Adding Properties with Tagged Values
[ description = descriptive text ] [ object_classification = classification keyword e.g., compiler ] [ stereotype = additional stereotype e.g., defered role ]Commas separate tagged values. For example,
[ author = "mark austin", version = 1.1 ].
Extending Semantics with Constraints
Object Constraint Language (OCL)
Elements of Real-Time Systems
Insert material soon .....
Insert material soon .....
Foundation for Executable Use Cases
Show how scenarios can be manually executed using tools like Statemate.
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.
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
WEB RESOURCES
Developed in February 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin,
Institute for Systems Research, University of Maryland