UML for Testers

  1. Introduction

    2. If a model is produced at all during object-oriented development it is likely to be a collection of UML diagrams. The Unified Modeling Language (or UML) is a notational system for expressing object-oriented models. UML has become the de facto standard for modeling object-oriented systems. These UML models are an important source of information for test design and should not be ignored.

    Over the next two class periods we will spend some time introducing UML. The first will be a very general introduction to the symbols or vocabulary of these models. On Thursday we will use a specific example to take a quick tour of the models. In the remaining class periods we will examine the implications of UML diagrams on test design.

    1. Why we Model

Models capture the essential relationships between things, but are easier to develop and analyze than the system under consideration (that is the models provide an abstraction or simplification of the system).

In software development, we model:

    1. Modeling Principles
  1. Basic Building Blocks

    2. The UML graphical notation consists of two fundamental building blocks: things and relationships that are combined to form diagrams.

    1. Four Kinds of Things
      1. Structural Things

These are the nouns of UML models. These are mostly the static parts of the model, representing either conceptual or physical elements. The structural things are:

Let’s take a look at each of these "things" in a little more detail.

        1. Class

          2. Definition: A description of a set of objects that share the same attributes, operations, relationships, and semantics. To be of any value a class must implement one or more interfaces.

          Representation: A rectangle with three sections for name, attributes, and operations.

        2. Interface

          3. Definition: A collection of operations that specify a service of a class or component (collection of classes). The Interface describes the external manifestation of some (or all) behaviors of the element. If the Interface includes any detail it is limited to operation signatures (number of variables and types), never any specific implementation information.

          Representation: Two common means of representation. First, may be a modified class element with an <<Interface>> tag (also known as a stereotype) added above the name. The attribute section is empty and the operation section is limited to the publicly available methods of the Interface. An alternate representation is a circle and a unique name. The circle may stand on its own or be connected to a class or component by a solid line (aka, a ball-and-stick).

        3. Collaboration

          4. Definition: Defines an interaction (which is a society of roles and other elements that work together to provide some cooperative behavior bigger than the sum of all the elements). Therefore, collaborations have both structural as well as behavioral meanings. A single class might participate in more than one Collaboration. Collaborations represent the implementation of patterns that make up the system.

          Representation: An ellipse with dashed lines usually labeled with the Collaboration name.

        4. Use Case

          5. Definition: A description of a sequence of actions that the system performs that yields an observable result of value to a particular user of the system (actor). Use Cases are used to structure the behavioral elements of the system. The realization of a Use Case is a Collaboration.

          Representation: An ellipse with solid lines, usually only including the Use Case name as a label.

        5. Subsystem

          6. Definition: A logical collection of one or more interfaces to provide some related set of actions.

          Representation: A tabbed folder usually including the name of the Subsystem which may have one or more interfaces (circle attached via a line).,

          ----------

          The next three things: Active Classes, Components, and Nodes are class-like (they describe sets of objects that share the same attributes, operations, and semantics). However, their uses are unique enough to require special treatment.

        6. Active Class

          7. Definition: Is a class whose objects own one or more processes or threads and therefore can initiate control activity. An active class is just like a class, except that its objects represent elements whose behavior is concurrent with other elements.

          Representation: Rendered just like a class, but with heavy outlines. Active classes may include details such as a name, attributes, and operations.

          ----------

          Components and Nodes represent physical things, whereas the six previous things are used to represent logical or conceptual things.

        7. Component

          8. Definition: Is a physical and replaceable part of the system that conforms to and provides the realization of a set of interfaces. In a system you may encounter many different types of Components, such as COM components or Java beans. A component typically represents the physical packaging of otherwise logical elements, such as classes, interfaces, and collaborations.

          Representation: A rectangle with side tabs, usually including only the name of the component.

        8. Node

Definition: A physical element that exists at run time and is a representation of a computational resource, usually have at least some memory and typically processing capabilities. A set of Components may exist at a Node and also may migrate from one Node to another.

Representation: A cube with an associated name.

 

      1. Behavioral Things

        2. Messages and States are the two behavioral elements. These elements are typically used in association with structural elements, primarily classes, collaborations, and objects.

        1. Message for Interaction

          2. Definition: An Interaction is a set of messages exchanged among objects to accomplish a specific task. Most Interactions involve a number of other elements including messages, action sequences (the behavior invoked by the messages), and links (connections between objects).

          Representation: A message is represented as a directed line, typically with the name of the message close at hand.

        2. State for State Machine

        Definition: A State Machine is a behavior that specifies the sequences of states that

        an object or interaction goes through during a response to events, together with the resulting responses to the events. A State Machine may be used to represent the behavior of an individual class or a collaboration of classes. A State Machine involves many elements: states, transitions (the flow from state to state), events (the things that trigger the transition from one state to another), and activities (the response to a transition).

        Representation: Rendered graphically as a rounded rectangle, usually including its name and the sub-states, if any.

         

      2. Grouping Things
        1. Package

        Definition: A Package is a general-purpose mechanism for organizing elements into groups. Just about anything may be grouped inside packages: structural things, behavioral things, or other packages. Unlike components, which exist at run time, a package is purely conceptual.

        Representation: Usually rendered as a tabbed folder, including its name. Optionally a package may include a list of the contents.

        Note that the subsystem we described earlier is a named package.

         

      3. Annotational Things
        1. Note

Definition: An explanatory comment or constraint associated with an element or group of elements.

Representation: Rendered graphically as a rectangle with a dog-eared corner, together with a textual or graphical comment.

 

    1. Four Kinds of Relationships

      2. What follows are the four fundamental types of graphical symbols used to represent relationships between elements.

      1. Dependency

        2. Definition: A semantic relationship between two things in which the change in one thing (the independent thing) affects the other thing (the dependent thing).

        Representation: Rendered graphically as a dashed line, which may be directed or undirected. Occasionally these lines will include a label.

      2. Association (and Aggregation)

        3. Definition: A structural relationship that describes a set of links (or connections between objects). Aggregation is a special version of an Association representing a structural relationship between a whole and its parts.

        Representation: Graphically an Association is drawn as a solid line, which may be directed. The line may include a label and other adornments such as indicators of multiplicity and the names of roles.

        Aggregation

        Definition: Aggregation is a special version of an Association representing a structural relationship between a whole and its parts.

        Representation: Aggregations commonly include a diamond at the "whole" end of the part-whole association. If the diamond is hollow, it implies that the part may survive beyond the live of the whole. A filled (black) diamond indicates that the part dies when the whole dies as would be the case in a composition.

      3. Generalization

        4. Definition: A Generalization encapsulates a relationship in which objects of the specialized element (the child) may be substituted from objects of the generalized element (the parent). The child shares the structure and behavior of the parent.

        Representation: Represented as a solid line with a hollow arrowhead pointing to the parent.

         

      4. Realization

Definition: A Realization is a semantic relationship between elements, in which one element specifies a contract that the other element guarantees to fulfill. There are too common places were Realizations are encountered: between Interfaces and the Classes or Components that realize them, and between Use Cases and the Collaborations that are the realization of the use case.

Representation: Represented as a dashed line with a hollow arrowhead pointing to the parent.

 

  1. Nine Kinds of Diagrams

    2. Various combinations of these symbols are used in diagrams to represent a set (or sets) of elements. For all but the most trivial systems, the diagram represents an abstraction of the system (some of the complexity is almost always suppressed by omission). These diagrams are drawn to provide information about a system from a number of differing perspectives. Each diagram is a projection into a system. The same elements may appear in one, a few or all diagrams of the system. While there are no strict rules for the combination of these elements into diagrams (in theory any elements may appear on a diagram), there are nine diagrams that occur sufficiently often to warrant detailed discussion.

    1. Class

      2. A Class Diagram shows a set of classes, interfaces, and collaborations and their relationships. Class Diagrams are perhaps the most common diagrams in models of object-oriented systems. A Class Diagram is a static design view of a system.

    2. Object

      3. An Object Diagram shows a set of objects and their relationships. Object Diagrams are static snapshots of instances of things from the Class Diagram. Like the Class Diagram, Object Diagrams address the static design or process view of as system, but from the perspective of real or prototypical cases.

    3. Use Case

      4. A Use Case Diagram shows a set of use cases, actors, and their relationships. These diagrams address the static Use Case view of the system. These diagrams are one of the key methods of modeling the behaviors of the system.

      An Actor is represented as a stick man. Actors may be human or non-human and represent something outside the system that sends or receives information from the system in question.

      ----------

      Interaction Diagrams show an interaction, which consists of objects and their relationships and the messages that are dispatched among these objects. Interaction Diagrams address the dynamic view of the system. Sequence and Collaboration Diagrams are the two commonly used kinds of Interaction Diagrams. Sequence Diagrams and Collaboration diagrams are isomorphic: one can be easily converted into the other.

    4. Sequence

      5. A Sequence Diagram is an interaction diagram that emphasizes the time-order of messages.

    5. Collaboration

      6. A Collaboration Diagram is an interaction diagram that emphasizes the "structural" organization of the objects that send and receive messages.

      ----------

    6. State Chart

      7. A State Chart Diagram shows a state machine, consisting of states, transitions, events, and activities. State Chart Diagrams are used to model the behavior of an interface, class, and collaboration. These diagrams emphasis the event-ordered behavior of the system.

    7. Activity

      8. An Activity Diagram is a special type of state chart diagram that emphasizes the flow from activity to activity. Activity Diagrams address the dynamics view of the system and flow of control among objects.

    8. Component

      9. A Component Diagram is a static representation of the system, showing the organizations and dependencies among components. Component Diagrams are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations.

    9. Deployment

    A Deployment Diagram models the configuration of run-time processing nodes and the components that live within the nodes. Deployment diagrams address the static deployment view of a system. These diagrams are related to component diagrams in that a node usually encloses one or more components.

  2. Architectural Views

    3. Design and construction of a complex software system demands that the system be viewed from several different perspectives. Individuals with an interest in the system have differing needs: end-users, analysts, developers, technical writers, project managers, and testers each look at the system in different ways at different times over lifetime of the project.

    Software architecture is the set of significant decisions about the organization of the software, behavior of the software elements, composition of the structural and behavioral elements into successively larger subsystems, and a number of other performance, functionality, reuse, reliability and technology concerns.

    The authors of the UML (and the Unified Development Process) suggest that the architecture of a system can be described as five interlocking views. Note: these are different views of the same system—each view emphasizes (or hides) different aspects of the system for the sake of clarity.

    1. Use Case View

      2. Encompasses the behavior of the system as seen by end-users, analysts, and testers. This view does not emphasis the organization of the software, but exists to specify the uses that shape the system’s architecture. In UML, the static aspects of the system are encapsulated in use case diagrams; the dynamic aspects in interaction diagrams, state chart diagrams, and activity diagrams.

    2. Design View

      3. Includes the classes, interfaces, and collaborations that are centered on the problem and the problem solution. This view is the primary view supporting the functional requirements (i.e. services) that the system is to provide to the end-users. In UML, the static aspects of this view are captured in class and object diagrams; the dynamic aspects in interaction diagrams, state chart diagrams, and activity diagrams.

    3. Process View

      4. Encompasses threads and processes that are the mainstay of the systems’ concurrency and synchronization mechanisms. Addresses performance, scalability, and throughput of the system. The static aspects of this view are typically presented as class and object diagrams, but with the focus on active classes that represent processes and threads; dynamic aspects in interaction diagrams, state chart diagrams, and activity diagrams.

    4. Implementation View

      5. This view encompasses the physical components and files that are assembled and released as the system. The view is designed to address issues surrounding the configuration management of the system releases. In this view, the static aspects of the system are captures in components diagrams; the dynamic aspects in interaction diagrams, state chart diagrams, and activity diagrams.

    5. Deployment View

The Deployment View is a representation of the nodes that are the hardware landscape on which the system executes. This view is concerned with the distribution, delivery, and installation of the parts that make up the physical system. With UML the static views are captured with deployment diagrams; the dynamics views with interaction diagrams, state chart diagrams, and activity diagrams.

Each of these five views can be used in isolation from any of the other views: each satisfies the needs of a different audience. These views also "interact" with each other as the nodes in a deployment view hold components in the implementation view, which represents the physical realization of classes, interfaces, and collaborations from the design and process views.