UML-in-an-hour

What is the UML?Unified Modeling LanguageIt is a modeling language, not a processRumbaugh joined Booch at Rational in 1994; in 1995, Rational added Jacobsen to their team. In 1996, work on the UML was begun.In January of 1997, Rational released UML 1.0 to the OMG as their proposal for a methods standard.

There is a process, called the Rational Unified Process, which is associated with the UML. The RUP is similar to ProVision -- there is a page on the UML website that shows the relationship. The Rational Unified Process is a derivative of Ivar Jacobsens Objectory.The amigos are working on a series of books that will explain the UML in greater detail. Because these books will be written by those who developed the language, they are considered by many to be the authoritative works on the subject.Booch will lead the Users Guide, a tutorial on OOA/D with UMLRumbaugh will lead the Reference Guide, a description of the notationJacobsen will lead the Process Guide, a description of the Rational Unified Process

The UML is currently at release 1.3. Release 1.1 made some changes to the language, releases 1.2 and 1.3 are best described as maintenance releases. They corrected errors in the previous releases, and provided clarifications.Where to Find Out More

ObjectivesUpon successful completion of this presentation, you will be able to:

Visually identify UML diagrams.Understand the differences between the UML diagrams.Identify key symbols found in each diagram.Identify the diagrams used in each ProVision phase.

UML Diagrams to be CoveredClass DiagramsUse Case DiagramsCollaboration DiagramsSequence DiagramsPackage DiagramsComponent Diagrams Deployment DiagramsActivity Diagrams State Diagrams

These are the diagrams covered during this course. This information will be provided for each diagram: Brief explanations Where the diagram is used in ProVision Diagram symbols Each diagram with the symbols Specific elements used for each diagram, such as supporting text

Types of UML Diagrams

Class DiagramsAre the most fundamental UML Diagram.Describe the classes in the system, and the static relationships between classes.Class diagrams are used during Analysis, Design and Development.

Class diagrams that appear during the Analysis phase generally describe user interface and related classes. Dont make the mistake of attempting to generate the class diagrams during this phase; that is a design phase and development phase activity. Class diagrams that appear during Analysis are often (and correctly) high level.Those with a copy of UML Distilled should read the description of class diagram perspectives located on page 55. Analysis phase class diagrams should not go beyond what Fowler describes as the Conceptual view.Most of the class diagrams will be generated during Design. Some may be generated during early Development, and classes will often be modified during Development.Static relationships are relationships between classes (which can be thought of as object templates). If it is possible to associate rented movies with people, there is a static relationship between the Person class, and the Movie class. Compare them to dynamic relationships (defined on the next slide).Class Diagrams

UML Class DiagramDVD MovieVHS MovieVideo GameRental Item{abstract}Rental Invoice1..*1CustomerCheckout Screen10..11

This class diagram shows examples of associations, aggregations, and generalizations. All of these topics are discussed in greater detail on later slides.In general, associations describe the relationships between classes or objects. They start as simple connectors, to show that some relationship exists. As design progress (and often during development), the natures of the relationships become clearer, and the associations are modified to reflect the new knowledge. For example, direction (not shown above, but discussed later) and cardinality are usually added later in design. The diagram above shows that each Rental Contract is associated with exactly one Checkout Screen, whereas a Checkout Screen may be associated with zero or one Rental Contracts. Likewise, a business rule states that a customer may rent no more than six items per visit, so that cardinality is shown.The diagram above shows a generalization relationship between several kinds of objects. Generalization means essentially the same thing in a class diagram that it does in a use case diagram. Here, the specializations (DVD Movie, VHS Movie, and N64 Game) of Rentable Item are fully consistent with Rentable Item and may be used wherever Rentable Item is allowed. Notice also that Rentable Item is {abstract}. This means that objects cannot be created from it, because one or more of its methods is not implemented. Abstract objects must be specialized. It is not necessary for a general object to be abstract; this is done (most commonly) when the general object serves to define an interface, and the specializations provide the meaningful implementation. Here, Rentable Item may not know how to calculate the rental fee -- each specialization is required to do that.What is a Class Diagram?

UML Class DiagramDVD MovieVHS MovieVideo GameRental Item{abstract}Rental Invoice1..*1CustomerCheckout Screen0..11Simple AssociationClassAbstractClassSimple AggregationGeneralizationComposition(Dependency)Multiplicity

This class diagram shows examples of associations, aggregations, and generalizations. All of these topics are discussed in greater detail on later slides.In general, associations describe the relationships between classes or objects. They start as simple connectors, to show that some relationship exists. As design progress (and often during development), the natures of the relationships become clearer, and the associations are modified to reflect the new knowledge. For example, direction (not shown above, but discussed later) and cardinality are usually added later in design. The diagram above shows that each Rental Contract is associated with exactly one Checkout Screen, whereas a Checkout Screen may be associated with zero or one Rental Contracts. Likewise, a business rule states that a customer may rent no more than six items per visit, so that cardinality is shown.The diagram above shows a generalization relationship between several kinds of objects. Generalization means essentially the same thing in a class diagram that it does in a use case diagram. Here, the specializations (DVD Movie, VHS Movie, and N64 Game) of Rentable Item are fully consistent with Rentable Item and may be used wherever Rentable Item is allowed. Notice also that Rentable Item is {abstract}. This means that objects cannot be created from it, because one or more of its methods is not implemented. Abstract objects must be specialized. It is not necessary for a general object to be abstract; this is done (most commonly) when the general object serves to define an interface, and the specializations provide the meaningful implementation. Here, Rentable Item may not know how to calculate the rental fee -- each specialization is required to do that.What is a Class Diagram?

IDEF1X97 Class DiagramRental InvoiceCustomerCheckout ScreenClassRelationshipMultiplicity/CardinalityDVD MovieVHS MovieVideo GameRental ItemDependent classBase class is abstractGeneralization(cluster)

This slide show an IDEF1X97 representation for the same class diagram as the previous slide. Note some of the differences: Connecting lines are relationships, not just associations. Cardinality is shown by adorning the connecting line. A dependent class is shown by curved corners. Specialization's are shown below a circle with two bars. Abstractness of a class is shown by double lines below the circle. Attributes, methods and responsibilities are not separated but are adorned when shown.

An IDEF1X97 Example

Parts of a ClassClasses can have four parts

NameAttributesOperationsResponsibilitiesClasses can show visibility and types.All parts but the Name are optional.

An individual class is shown on the diagram as a box with up to four sections.The first section shows the name of the class. Names should be nouns. Typically the first letter of every word in a name is capitalized. Attributes represent the state of the object or what the object knows.Operators represent the behavior of an object or what the object does.Responsibilities are optional. A Responsibility is a contract or an obligation of the class. They are normally only used in analysis and early in the design phase to describe what a class should do without describing how it should do it.The + sign indicates that an attribute or operation is public or visible to all other objects or operations in the system.The - sign indicates that an attribute or operation is private or hidden from any objects or operations other than those objects also of the current class.The # sign indicates that an attribute or operation is protected or visible only to members of the same class or members that are specialization's of (or derived from) that class.The Parts of a Class

Object DiagramsAn Object is an instance of a class.Object names are underlined.Object diagrams are similar to class diagrams. Many of the same notations are used.Object diagrams capture instances of classes, and allow the dynamic relationships to be shown.

Object diagrams have a very similar appearance to class diagrams (see next slide), but are more specific. It is very important to make sure the syntax rules for writing the names of classes and objects are followed. Otherwise, confusion is sure to result.Object diagrams are useful when information about the dynamic relationships between classes must be captured.Dynamic relations are between instances (of classes). If a particular person (Bob) rents a particular movie (Casablanca), there is a dynamic relationship between Bob:Person, and Casablanca: Movie. Compare to static relationships (defined on the previous slide).Object Diagrams Described

Class and Object Diagrams0..10..nCustomerRental ItemRents+name:string+id:integer+released:date+id:integerJoe: CustomerCasablanca: Movie+name:Joe Smith+id:1667+released:1942+id:22340Class DiagramObject DiagramClass NameObject NameAttributesAssociation Name

Note that the object diagram is much more specific. Values are provided for data. The relationship is less abstract, because it refers to the relationship between two instances (here, Joe and Casablanca), and not the theoretical relationship between classes.The UML specification requires that object names be underlined. Objects do not need to be named, but if an object does not have a name, the name of its class must be preceded with a colon. This makes clear that the name represents a class and not an object. In the diagram above, :Customer could also be used. Class names are also not required; if the class name is not provided, there should not be a colon. In the diagram above, Joe could also be used. Obviously, each object should have either a name or a class name.Be careful when simplifying diagrams by removing names -- ensure that you have not removed vital information. If Joe could be an instance of any of a number of related classes, it may be important to show which class it is. The idea is to strike the right balance between a diagram that captures the needed information, and one thats not so cluttered the eye cannot follow the concepts.Class Diagrams and Object Diagrams

Stereotypes, Tagged Values and ConstraintsStereotypes, Tagged Values and Constraints extend the UML

Stereotypes are shown using Tagged Values and Constraints are shown using { }RentalContract

{version=1.1}ListOfRentedItemsCustomer{ordered by title}ConstraintTagged ValueStereotype

UML provide three mechanisms to extend the language. These are:StereotypesTagged Values andConstraints.

A Stereotype is shown using the (guillemets). In the slide the stereotype indicates that the object state is maintained between instantiations. Stereotypes can also be used with different icons. For example a page icon is typically used to represent a document stereotype within UML.Tagged values are a means of adding information that is associated with the class or other model element. A tagged value might indicate version number or author. A constraint allows constraints to be shown on the model.Constraints and Tagged values are text between curly braces.Extending the UML

Use CasesDescribe interactions between users and computer systems (both called actors) .Capture user-visible functions. Achieve discrete measurable goals.May be

small (Make selected text bold)large (Generate a table of contents)Are typically used during Analysis and Design.

A use case model is important for visually representing a system, but equally important is the text that supports the use case model, called the Use Case Report. The elements of the Use Case Report will be discussed in later slides.A use case is initiated by an actor to perform a required task.Most of the time, an actor is a person, but that doesnt have to be the case. Sometimes, an actor can be another computer system -- for example, when an external system requires a roll-up report for processing, one might view that system as an actor, and the generation of that roll-up report as a use case.What is a Use Case?

Use Case Diagram

Diagram Notes:The use cases here are: Identify Movie, Open Account, Return Movie, and Review Account Status. The actors are: Customer and Clerk. The Customer is the parent actor and the In-Store and Telephone Customer are child actors. The child actors inherit some of their characteristics from the parent actor. The Customer can initiate the Identify Movie, Open Account, and Return Movie use cases; the Clerk (or any of its specializations) can initiate any of the use cases.Identify Movie names the movie the customer is looking to rent. The clerk will also need to identify the movie in the movie database or on the shelves in the store.Open Account allows the customer and clerk to establish an account.Return Movie explains that the customer brings the movie back to the store and the clerk puts the movie back in the database as available and places the movie on the shelf.Review Account Status is only initiated by the clerk. It allows the clerk to review information not generally available to (or needed by) the customer.An actor is someone or something that initiates use cases. It is stereotyped from a class.A use case is a sequence of actions performed at the request of an actor. A use case contains all the actions that can occur between an actor-use case pair. In a given scenario, some actions may not occur. A use case contains a set of scenarios that explain various sequences of interactions within it.An association represents a semantic connection between an actor and a use case. Associations are uni-directional; they are the most general of all relationships and the most semantically weak. A stereotype can refine the association.A generalization relationship can show actors that share behavior (perhaps several actors can function in role; that role can also be an actor which defines the common behavior).

Use Case Diagram for the Movie Store

Use Case ReportThe Use Case Report provides documentation for the Use Case.A Use Case is not complete without the report.The elements of the Use Case Report are shown on the right.

Brief descriptionPreconditionFlow of events

Main flowSubflowsAlternate flowsPostconditionSpecial RequirementsEnclosures

DiagramsPictures of the UI

The purpose of a Use Case Report is to describe the flow of events specifically in a way the customer understands.1. Brief description-should describe the purpose of the use case in a few sentences. The actor that initiates the use case can be documented here.2. Precondition-a precondition is a constraint on the system or indicates another task or use case that must be completed before beginning the use case being documented.3. Flow of events-should describe when the use case begins, when it ends, where different actors take part in the flow of events, and the information exchanged. The main flow does not describe how problems are solved or the details of the UI. Each use case should start with, This use case begins when.Main flow-is the normal sequence of events for the use case, what normally happens if nothing goes wrong.Subflow-these are optional or parallel sequences, or large segments of a given flow of events that divides the flow of events into different sections. Provide a title for the subflow in your documentation and describe the order of subflows.Alternate flow-an exceptional flow, the what happens if part of the main flow. Alternate flows specify variants to the main flow, optional flows, or error cases. Define a condition and the behavior for the alternate flow.

4. Postcondition-defines a constraint on the system when the use case has terminated.5. Special requirements-non-functional requirements that may influence design.6. Enclosures-the actual use case diagram, and possibly screen captures of the UI.What is a Use Case Report?

Extends and Includes RelationshipsExtendsIncludesFind Item by TitleFind Items by ActorSearch MovieDatabaseincludesincludesCustomerDependencyextendsStereotypeCheck In MovieAssessLate Fees

Relationships Between Use CasesExtends:The top diagram illustrates the extends relationship between use cases.A use case that extends another use cases uses some of the behavior of the extended use case. It does not have to use all of the behavior (this is an important point). The relationship is a dependency, shown by a dashed line and open headed arrow, along with the sterotype Extends. An Extends use case can show that it is an optional part of the base use case, that it is a subflow and only initiated under exceptional circumstances. The top diagram demonstrates how a video store clerk might search for a movie in two different ways. The customer might know the name, or might know only that a particular performer was in the film.Includes:The bottom diagram illustrates the Includes relationship. When a use case includes another, the entire use case must be used (this differs from the extends relationship). The notation is similar, except that the stereotype here is Includes.Both clerk and customer interact with the Check Out Movies and Pay Fines cases. Each of these cases must determine the account status; they both do it in the same way, and so the Update Account Status activities have been moved into a separate use case.An includes use case depends on the base use case and where the Includes relationship will be inserted. An Includes use case can factor out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case, or to factor out behavior that is common for two or more use cases.

Collaboration DiagramsCollaboration diagrams describe object interactions organized around the objects and their links to each otherFocus on exchange of messages between objects through their associations.Appears during Analysis phaseEnhanced during Design phase

Class roles represent roles that object may play within the interaction. Association roles represent roles that links may play within the interaction. Message flows represent messages sent between objects via links. Links transport or implement the delivery of the messages.Another view of the sequence diagram.Collaboration diagram tend to provide the big picture for a scenario, organized around the object links to one another. What is a Collaboration Diagram?

Collaboration Diagram - Rent Movie :Check-out Manager:Customer:Inventory1: enter_customer()3: enter_movies()5: add(customer, movies)7: print invoice()2: IsValidCust(CustId)4:GetMovieByBarcode():ClerkObjectMessage:Rented Items8: generateRentalTotal()

The objects in rectangles represent class roles. The links (lines or paths) represent association roles. The arrows between class roles indicate message flows exchanged between objects. The message flows are labeled with both the sequence number of the message and the message that is sent between the class roles. A message triggers an operation in the receiving object. The sequence numbers indicate the sequence of messages within the next higher level of nesting.A Collaboration Diagram for the Movie Store

Sequence DiagramsCan be morphed from Collaboration Diagrams.Describe interactions between objects arranged in time sequenceFocus on objects and classes involved in the scenario and the sequence of messages exchangedAssociated with use casesUsed heavily during Analysis phase and are enhanced and refined during Design phase

Interactions are modeled as exchange of messages. Class roles represent roles that objects may play within the interactions. Lifelines represent the existence of an object over a period of time. Activations represent the time during which an object is performing an operation. Messages represent communication between objects.An object in a sequence diagram is drawn as a rectangle containing the name of the object, underlined.It is easy to read and understand sequence diagram as it looks at a scenario based on time order. This diagram is very useful in the early analysis phase.What is a Sequence Diagram?

Sequence Diagram - Rent Movie

1: find customer()2: search (string)4: search (string)6: add(Cust, item)3: enter movie()5: rent (movie)7: printInvoice()8: generateRentalTotal()ObjectLifelineActivationMessage:CheckoutMgr:InventoryCust:Customer:RentedItems:Employee

Depicts how the classes within the system work together. The objects at the top represent class roles. The dashed lines that extend from each object represent lifelines. The thin rectangles on the lifelines represent activations. The horizontal arrows between lifelines indicate the messages exchanged between objects. The horizontal arrows are labeled with the message that is sent between the class roles. The message triggers an operation in the receiving object.The objects defined inside the rectangle can be defined in one of the three ways:The object name, the object name and its class, or just the class name (anonymous object)A Sequence Diagram Example

Package DiagramClassPackage

Packages are a grouping mechanism. A package can contain any other UML construction, including other packages. Packages are useful when producing diagrams that show a larger picture of the system.A package owns its elements; no element can be owned by more than one package, but packages can refer to elements from other packages. Often, packages do not translate to executable elements. Some languages (Java, for example) support the concept of packages, but the UML does not require that the package correspond to an executable element.Packages can have visibility: public, protected, private, and implementation visibilities are defined by the UML. Public means anyone can model elements within the package. Protected means only the package, or specializations of it, can see its model elements. Private means the package itself can use its elements, AND that another package that specifically imports an element can use that element. Implementation is similar to private, but disallows importing.This package diagram is a fragment of the Clerks User Interface. The package contains a Customer Data class and a Business System faade package. It also contains a Rental Screen class, and shows that the Rental Screen class depends on the Customer Data class and the Business System faade.

What is a Package Diagram?

Component DiagramComponentInterfaceDependencyNote

A component diagram shows software components, and their dependencies. It is a way of describing the structure of the code. Components are physical entities; they represent the implementation of the logical architecture described by class diagrams, object diagrams, and interaction diagrams.Components can be:Source: some source code; a compilation unit. Meaningful at compile time. Stereotypes such as file, page, and document can provide additional information about the components nature.Binary: object code, or a library file (static or dynamic). Meaningful at link or runtime (this will depend on the specific nature of the component). The stereotype library appears here.Executable: executable code; an image. Meaningful at execution time. These at the only variety of component that can have instances (while they are running). The stereotypes application and table (a database table viewed as a runtime component) are common on this sort of component.Components are types. To show instances of components, one draws a deployment diagram and allocates instances of executable components to the nodes where they run.What is a Component Diagram?

Deployment DiagramNodeCommunicationAssociation

A deployment diagram shows the runtime architecture of the system and the topology (physical architecture) of the system. Each node represents a piece of hardware. A node is a special kind of class; the detailed capabilities of the node can be represented as attributes and/or properties of that class.Nodes are connected by communication associations. These are typically directionless associations that are stereotyped (as in the diagram above) to show what kind of traffic they carry.Components may be placed inside of nodes. This shows that the component runs on the node. A diagram which shows how nodes are connected may not have this level of detail, but a diagram that fully describes a node should. Packages containing components can also be used to simplify the diagram. Objects (instances of classes) can also be drawn in nodes, if appropriate. They can be drawn inside the component that implements them if desired, or they can be drawn standalone (the relationship between an object and the component that implements need not appear in a deployment diagram).A component can be shown to depend on a node, with the stereotype supports. This indicates that the node supports instances of the component (this is not shown in the diagram above).Because nodes are classes, more complex relationships (including cardinality) are certainly possible. They can be associated in any way that is legal for classes (but some associations may not be useful).

What is a Deployment Diagram?

Activity DiagramIdentify CallerCreate AccountObtain Name& AddressOpen Account?CurrentCustomer?[no][no][yes][yes]Action StateStart StateDecisionEnd State

Diagram Notes:1. The activity begins when the clerk identifies a caller either over the phone or at the counter.2. The clerk will ask for identification by name and address.3. The clerk looks in the database to determine if the customer is a current customer.4. This is where the decision icon factors into the diagram. If the customer is a current customer, conclude the activity. If the customer is not a current customer, ask the customer if they would like to create an account.5. The create account is another decision icon. If the customer wishes to create an account, continue with the flow and create an account. If the customer says no, conclude transaction (assuming the Movie Store rents only to account holders).Activity Diagrams: Are used in the Analysis and Design phases of ProVision. Can show sequence in use cases and are similar to workflow diagrams. Can show concurrency through parallel flows. Allow multiple start points and conditional branching. Multiple start points can show relationships between different Use Cases. Focus on flows driven by internal processing. Apply to situations where all or most of the events represent the completion of internally-generated actions (the flow of control from activity to activity). Can show how an object changes state at different points in the flow of control.

Swimlanes and Fork/Join PointsIdentify MoviePlaceOrderPlace Order

FillOrderPayDeliverMoviePickupMovieCustomerManagerWalking ClerkFork PointJoin PointCollectMoney

Diagram Notes:1. The first action is a Customer checking to see if a movie is available.2. The Customer orders the movie. 3. The Manager places the order using the movie database. (fork point)4. The Walking Clerk obtains the order from the back while the customer is paying. (join point)5. The Walking Clerk delivers the order back to the Manager.6. The Manager hands the movies to the customer.7. The Customer picks up the order.8. The activity terminates.Swimlanes:Swimlanes organize actions by class. Each swimlane is divided by classes or actors. Each swimlane represents the responsibility of the overall class, the ordering has no significance. Transitions may cross swimlanes. Fork/Join Point:Fork point-this shows where the thread or path divides into two parallel paths. There is no limit to the amount of threads coming out of a fork point. These threads will need to synchronize, which happens at the Join Point. Threads join back together at the join point. The activities below the fork point and above the join point occur in parallel.

State DiagramStateTransitionActivityGuardActionEvent

This is a simple example of a state diagram that describes the video check-out process. UML State Diagrams are very similar to state diagrams seen in other design notations.The diagram contains states and transitions.Each state contains a name, and may also have associated actions. Actions are tasks (typically of a longer duration, and that can be interrupted by events). Actions start when the state is entered. A transition does not occur when an action completes; only an Event (see below) can cause a transition (however, an Event might occur as a result of tasks performed by the Action).Each transition is labeled; the label consists of three parts, all optional: Event [Guard] / Action. The event is what triggers the transition; a transition cannot occur until its controlling event does. The guard is a Boolean expression that describes a condition -- the transition does not occur unless the condition is true (there can, in fact, be several transitions on the same event, with different guard conditions, as long as the guard conditions are mutually exclusive). Finally, the activity is a short, uninterruptible task.Two special events exist. These are entry and exit. If they are defined, and association with Activities, those Activities occur immediately on entry (before any actions) and immediately on exit, respectively. This is true for all transitions into and out of the state. Exit occurs before any activity associated with the transition, and entry (on the new state) occurs after. Entry activities occur before state actions.What is a State Diagram?

UML Diagram Usage

Development Phase

UML Diagrams

Analysis

Use Cases, Class Diagrams, Activity Diagrams, Collaboration Diagrams, Sequence Diagrams

Design

Class Diagrams, Collaboration Diagrams, Sequence Diagrams, State Diagrams, Component Diagrams Deployment Diagrams

Development

Collaboration Diagrams, Sequence Diagrams, Class Diagrams, State Diagrams, Component Diagrams, Deployment Diagrams

Implementation

Package Diagrams, Deployment Diagrams

The goal of each phase of ProVision is to produce a specific kind of knowledge -- a list of requirements, a description of how requirements can be met, a working and deployed system. Each of those goals is supported by some of the UML diagrams, as shown above. This does not mean there is no place for other diagrams. Keep in mind that the goal of the UML is to facilitate communication between those producing a specific kind of work product, and between those taking one kind of work product, and using it to develop other work products.How does ProVision use the UML?

ConclusionUML is a robust notation that can express information gathered throughout a projects lifecycle.Adopting standard use of UML can improve communication between clients and Information Systems Service Providers.UML can be used as an effective data modeling tool as well as an object modeling tool.

Hopefully, you can now identify the types of UML diagrams and where they fit into ProVision. There are notations and concepts in the UML that have been summarized heavily, or omitted, from this presentation. Those interesting in learning more should surf to the UML Adoption Committees website, which is accessed through the SETG Communications page (click on Topic Sites to see a list of the sites). There, you will find information about the UML, a reference list, and a page that details how the UML relates to ProVision.

Questions

If I dont know the answer, maybe I can make one up!

For more informationContact:John T. BellRWD Technologies Inc.10480 Little Patuxent ParkwayColumbia, MD 21044

Phone: 410-884-2453email: [email protected]

http://www.rwd.com

There is a process, called the Rational Unified Process, which is associated with the UML. The RUP is similar to ProVision -- there is a page on the UML website that shows the relationship. The Rational Unified Process is a derivative of Ivar Jacobsens Objectory.The amigos are working on a series of books that will explain the UML in greater detail. Because these books will be written by those who developed the language, they are considered by many to be the authoritative works on the subject.Booch will lead the Users Guide, a tutorial on OOA/D with UMLRumbaugh will lead the Reference Guide, a description of the notationJacobsen will lead the Process Guide, a description of the Rational Unified Process

The UML is currently at release 1.3. Release 1.1 made some changes to the language, releases 1.2 and 1.3 are best described as maintenance releases. They corrected errors in the previous releases, and provided clarifications.Where to Find Out More

These are the diagrams covered during this course. This information will be provided for each diagram: Brief explanations Where the diagram is used in ProVision Diagram symbols Each diagram with the symbols Specific elements used for each diagram, such as supporting text

Types of UML DiagramsClass diagrams that appear during the Analysis phase generally describe user interface and related classes. Dont make the mistake of attempting to generate the class diagrams during this phase; that is a design phase and development phase activity. Class diagrams that appear during Analysis are often (and correctly) high level.Those with a copy of UML Distilled should read the description of class diagram perspectives located on page 55. Analysis phase class diagrams should not go beyond what Fowler describes as the Conceptual view.Most of the class diagrams will be generated during Design. Some may be generated during early Development, and classes will often be modified during Development.Static relationships are relationships between classes (which can be thought of as object templates). If it is possible to associate rented movies with people, there is a static relationship between the Person class, and the Movie class. Compare them to dynamic relationships (defined on the next slide).Class DiagramsThis class diagram shows examples of associations, aggregations, and generalizations. All of these topics are discussed in greater detail on later slides.In general, associations describe the relationships between classes or objects. They start as simple connectors, to show that some relationship exists. As design progress (and often during development), the natures of the relationships become clearer, and the associations are modified to reflect the new knowledge. For example, direction (not shown above, but discussed later) and cardinality are usually added later in design. The diagram above shows that each Rental Contract is associated with exactly one Checkout Screen, whereas a Checkout Screen may be associated with zero or one Rental Contracts. Likewise, a business rule states that a customer may rent no more than six items per visit, so that cardinality is shown.The diagram above shows a generalization relationship between several kinds of objects. Generalization means essentially the same thing in a class diagram that it does in a use case diagram. Here, the specializations (DVD Movie, VHS Movie, and N64 Game) of Rentable Item are fully consistent with Rentable Item and may be used wherever Rentable Item is allowed. Notice also that Rentable Item is {abstract}. This means that objects cannot be created from it, because one or more of its methods is not implemented. Abstract objects must be specialized. It is not necessary for a general object to be abstract; this is done (most commonly) when the general object serves to define an interface, and the specializations provide the meaningful implementation. Here, Rentable Item may not know how to calculate the rental fee -- each specialization is required to do that.What is a Class Diagram?This class diagram shows examples of associations, aggregations, and generalizations. All of these topics are discussed in greater detail on later slides.In general, associations describe the relationships between classes or objects. They start as simple connectors, to show that some relationship exists. As design progress (and often during development), the natures of the relationships become clearer, and the associations are modified to reflect the new knowledge. For example, direction (not shown above, but discussed later) and cardinality are usually added later in design. The diagram above shows that each Rental Contract is associated with exactly one Checkout Screen, whereas a Checkout Screen may be associated with zero or one Rental Contracts. Likewise, a business rule states that a customer may rent no more than six items per visit, so that cardinality is shown.The diagram above shows a generalization relationship between several kinds of objects. Generalization means essentially the same thing in a class diagram that it does in a use case diagram. Here, the specializations (DVD Movie, VHS Movie, and N64 Game) of Rentable Item are fully consistent with Rentable Item and may be used wherever Rentable Item is allowed. Notice also that Rentable Item is {abstract}. This means that objects cannot be created from it, because one or more of its methods is not implemented. Abstract objects must be specialized. It is not necessary for a general object to be abstract; this is done (most commonly) when the general object serves to define an interface, and the specializations provide the meaningful implementation. Here, Rentable Item may not know how to calculate the rental fee -- each specialization is required to do that.What is a Class Diagram?This slide show an IDEF1X97 representation for the same class diagram as the previous slide. Note some of the differences: Connecting lines are relationships, not just associations. Cardinality is shown by adorning the connecting line. A dependent class is shown by curved corners. Specialization's are shown below a circle with two bars. Abstractness of a class is shown by double lines below the circle. Attributes, methods and responsibilities are not separated but are adorned when shown.

An IDEF1X97 ExampleAn individual class is shown on the diagram as a box with up to four sections.The first section shows the name of the class. Names should be nouns. Typically the first letter of every word in a name is capitalized. Attributes represent the state of the object or what the object knows.Operators represent the behavior of an object or what the object does.Responsibilities are optional. A Responsibility is a contract or an obligation of the class. They are normally only used in analysis and early in the design phase to describe what a class should do without describing how it should do it.The + sign indicates that an attribute or operation is public or visible to all other objects or operations in the system.The - sign indicates that an attribute or operation is private or hidden from any objects or operations other than those objects also of the current class.The # sign indicates that an attribute or operation is protected or visible only to members of the same class or members that are specialization's of (or derived from) that class.The Parts of a ClassObject diagrams have a very similar appearance to class diagrams (see next slide), but are more specific. It is very important to make sure the syntax rules for writing the names of classes and objects are followed. Otherwise, confusion is sure to result.Object diagrams are useful when information about the dynamic relationships between classes must be captured.Dynamic relations are between instances (of classes). If a particular person (Bob) rents a particular movie (Casablanca), there is a dynamic relationship between Bob:Person, and Casablanca: Movie. Compare to static relationships (defined on the previous slide).Object Diagrams DescribedNote that the object diagram is much more specific. Values are provided for data. The relationship is less abstract, because it refers to the relationship between two instances (here, Joe and Casablanca), and not the theoretical relationship between classes.The UML specification requires that object names be underlined. Objects do not need to be named, but if an object does not have a name, the name of its class must be preceded with a colon. This makes clear that the name represents a class and not an object. In the diagram above, :Customer could also be used. Class names are also not required; if the class name is not provided, there should not be a colon. In the diagram above, Joe could also be used. Obviously, each object should have either a name or a class name.Be careful when simplifying diagrams by removing names -- ensure that you have not removed vital information. If Joe could be an instance of any of a number of related classes, it may be important to show which class it is. The idea is to strike the right balance between a diagram that captures the needed information, and one thats not so cluttered the eye cannot follow the concepts.Class Diagrams and Object DiagramsUML provide three mechanisms to extend the language. These are:StereotypesTagged Values andConstraints.

A Stereotype is shown using the (guillemets). In the slide the stereotype indicates that the object state is maintained between instantiations. Stereotypes can also be used with different icons. For example a page icon is typically used to represent a document stereotype within UML.Tagged values are a means of adding information that is associated with the class or other model element. A tagged value might indicate version number or author. A constraint allows constraints to be shown on the model.Constraints and Tagged values are text between curly braces.Extending the UMLA use case model is important for visually representing a system, but equally important is the text that supports the use case model, called the Use Case Report. The elements of the Use Case Report will be discussed in later slides.A use case is initiated by an actor to perform a required task.Most of the time, an actor is a person, but that doesnt have to be the case. Sometimes, an actor can be another computer system -- for example, when an external system requires a roll-up report for processing, one might view that system as an actor, and the generation of that roll-up report as a use case.What is a Use Case?Diagram Notes:The use cases here are: Identify Movie, Open Account, Return Movie, and Review Account Status. The actors are: Customer and Clerk. The Customer is the parent actor and the In-Store and Telephone Customer are child actors. The child actors inherit some of their characteristics from the parent actor. The Customer can initiate the Identify Movie, Open Account, and Return Movie use cases; the Clerk (or any of its specializations) can initiate any of the use cases.Identify Movie names the movie the customer is looking to rent. The clerk will also need to identify the movie in the movie database or on the shelves in the store.Open Account allows the customer and clerk to establish an account.Return Movie explains that the customer brings the movie back to the store and the clerk puts the movie back in the database as available and places the movie on the shelf.Review Account Status is only initiated by the clerk. It allows the clerk to review information not generally available to (or needed by) the customer.An actor is someone or something that initiates use cases. It is stereotyped from a class.A use case is a sequence of actions performed at the request of an actor. A use case contains all the actions that can occur between an actor-use case pair. In a given scenario, some actions may not occur. A use case contains a set of scenarios that explain various sequences of interactions within it.An association represents a semantic connection between an actor and a use case. Associations are uni-directional; they are the most general of all relationships and the most semantically weak. A stereotype can refine the association.A generalization relationship can show actors that share behavior (perhaps several actors can function in role; that role can also be an actor which defines the common behavior).

Use Case Diagram for the Movie StoreThe purpose of a Use Case Report is to describe the flow of events specifically in a way the customer understands.1. Brief description-should describe the purpose of the use case in a few sentences. The actor that initiates the use case can be documented here.2. Precondition-a precondition is a constraint on the system or indicates another task or use case that must be completed before beginning the use case being documented.3. Flow of events-should describe when the use case begins, when it ends, where different actors take part in the flow of events, and the information exchanged. The main flow does not describe how problems are solved or the details of the UI. Each use case should start with, This use case begins when.Main flow-is the normal sequence of events for the use case, what normally happens if nothing goes wrong.Subflow-these are optional or parallel sequences, or large segments of a given flow of events that divides the flow of events into different sections. Provide a title for the subflow in your documentation and describe the order of subflows.Alternate flow-an exceptional flow, the what happens if part of the main flow. Alternate flows specify variants to the main flow, optional flows, or error cases. Define a condition and the behavior for the alternate flow.

4. Postcondition-defines a constraint on the system when the use case has terminated.5. Special requirements-non-functional requirements that may influence design.6. Enclosures-the actual use case diagram, and possibly screen captures of the UI.What is a Use Case Report?Relationships Between Use CasesExtends:The top diagram illustrates the extends relationship between use cases.A use case that extends another use cases uses some of the behavior of the extended use case. It does not have to use all of the behavior (this is an important point). The relationship is a dependency, shown by a dashed line and open headed arrow, along with the sterotype Extends. An Extends use case can show that it is an optional part of the base use case, that it is a subflow and only initiated under exceptional circumstances. The top diagram demonstrates how a video store clerk might search for a movie in two different ways. The customer might know the name, or might know only that a particular performer was in the film.Includes:The bottom diagram illustrates the Includes relationship. When a use case includes another, the entire use case must be used (this differs from the extends relationship). The notation is similar, except that the stereotype here is Includes.Both clerk and customer interact with the Check Out Movies and Pay Fines cases. Each of these cases must determine the account status; they both do it in the same way, and so the Update Account Status activities have been moved into a separate use case.An includes use case depends on the base use case and where the Includes relationship will be inserted. An Includes use case can factor out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case, or to factor out behavior that is common for two or more use cases.Class roles represent roles that object may play within the interaction. Association roles represent roles that links may play within the interaction. Message flows represent messages sent between objects via links. Links transport or implement the delivery of the messages.Another view of the sequence diagram.Collaboration diagram tend to provide the big picture for a scenario, organized around the object links to one another. What is a Collaboration Diagram?The objects in rectangles represent class roles. The links (lines or paths) represent association roles. The arrows between class roles indicate message flows exchanged between objects. The message flows are labeled with both the sequence number of the message and the message that is sent between the class roles. A message triggers an operation in the receiving object. The sequence numbers indicate the sequence of messages within the next higher level of nesting.A Collaboration Diagram for the Movie StoreInteractions are modeled as exchange of messages. Class roles represent roles that objects may play within the interactions. Lifelines represent the existence of an object over a period of time. Activations represent the time during which an object is performing an operation. Messages represent communication between objects.An object in a sequence diagram is drawn as a rectangle containing the name of the object, underlined.It is easy to read and understand sequence diagram as it looks at a scenario based on time order. This diagram is very useful in the early analysis phase.What is a Sequence Diagram?Depicts how the classes within the system work together. The objects at the top represent class roles. The dashed lines that extend from each object represent lifelines. The thin rectangles on the lifelines represent activations. The horizontal arrows between lifelines indicate the messages exchanged between objects. The horizontal arrows are labeled with the message that is sent between the class roles. The message triggers an operation in the receiving object.The objects defined inside the rectangle can be defined in one of the three ways:The object name, the object name and its class, or just the class name (anonymous object)A Sequence Diagram ExamplePackages are a grouping mechanism. A package can contain any other UML construction, including other packages. Packages are useful when producing diagrams that show a larger picture of the system.A package owns its elements; no element can be owned by more than one package, but packages can refer to elements from other packages. Often, packages do not translate to executable elements. Some languages (Java, for example) support the concept of packages, but the UML does not require that the package correspond to an executable element.Packages can have visibility: public, protected, private, and implementation visibilities are defined by the UML. Public means anyone can model elements within the package. Protected means only the package, or specializations of it, can see its model elements. Private means the package itself can use its elements, AND that another package that specifically imports an element can use that element. Implementation is similar to private, but disallows importing.This package diagram is a fragment of the Clerks User Interface. The package contains a Customer Data class and a Business System faade package. It also contains a Rental Screen class, and shows that the Rental Screen class depends on the Customer Data class and the Business System faade.

What is a Package Diagram?A component diagram shows software components, and their dependencies. It is a way of describing the structure of the code. Components are physical entities; they represent the implementation of the logical architecture described by class diagrams, object diagrams, and interaction diagrams.Components can be:Source: some source code; a compilation unit. Meaningful at compile time. Stereotypes such as file, page, and document can provide additional information about the components nature.Binary: object code, or a library file (static or dynamic). Meaningful at link or runtime (this will depend on the specific nature of the component). The stereotype library appears here.Executable: executable code; an image. Meaningful at execution time. These at the only variety of component that can have instances (while they are running). The stereotypes application and table (a database table viewed as a runtime component) are common on this sort of component.Components are types. To show instances of components, one draws a deployment diagram and allocates instances of executable components to the nodes where they run.What is a Component Diagram?A deployment diagram shows the runtime architecture of the system and the topology (physical architecture) of the system. Each node represents a piece of hardware. A node is a special kind of class; the detailed capabilities of the node can be represented as attributes and/or properties of that class.Nodes are connected by communication associations. These are typically directionless associations that are stereotyped (as in the diagram above) to show what kind of traffic they carry.Components may be placed inside of nodes. This shows that the component runs on the node. A diagram which shows how nodes are connected may not have this level of detail, but a diagram that fully describes a node should. Packages containing components can also be used to simplify the diagram. Objects (instances of classes) can also be drawn in nodes, if appropriate. They can be drawn inside the component that implements them if desired, or they can be drawn standalone (the relationship between an object and the component that implements need not appear in a deployment diagram).A component can be shown to depend on a node, with the stereotype supports. This indicates that the node supports instances of the component (this is not shown in the diagram above).Because nodes are classes, more complex relationships (including cardinality) are certainly possible. They can be associated in any way that is legal for classes (but some associations may not be useful).

What is a Deployment Diagram?Diagram Notes:1. The activity begins when the clerk identifies a caller either over the phone or at the counter.2. The clerk will ask for identification by name and address.3. The clerk looks in the database to determine if the customer is a current customer.4. This is where the decision icon factors into the diagram. If the customer is a current customer, conclude the activity. If the customer is not a current customer, ask the customer if they would like to create an account.5. The create account is another decision icon. If the customer wishes to create an account, continue with the flow and create an account. If the customer says no, conclude transaction (assuming the Movie Store rents only to account holders).Activity Diagrams: Are used in the Analysis and Design phases of ProVision. Can show sequence in use cases and are similar to workflow diagrams. Can show concurrency through parallel flows. Allow multiple start points and conditional branching. Multiple start points can show relationships between different Use Cases. Focus on flows driven by internal processing. Apply to situations where all or most of the events represent the completion of internally-generated actions (the flow of control from activity to activity). Can show how an object changes state at different points in the flow of control.

Diagram Notes:1. The first action is a Customer checking to see if a movie is available.2. The Customer orders the movie. 3. The Manager places the order using the movie database. (fork point)4. The Walking Clerk obtains the order from the back while the customer is paying. (join point)5. The Walking Clerk delivers the order back to the Manager.6. The Manager hands the movies to the customer.7. The Customer picks up the order.8. The activity terminates.Swimlanes:Swimlanes organize actions by class. Each swimlane is divided by classes or actors. Each swimlane represents the responsibility of the overall class, the ordering has no significance. Transitions may cross swimlanes. Fork/Join Point:Fork point-this shows where the thread or path divides into two parallel paths. There is no limit to the amount of threads coming out of a fork point. These threads will need to synchronize, which happens at the Join Point. Threads join back together at the join point. The activities below the fork point and above the join point occur in parallel.This is a simple example of a state diagram that describes the video check-out process. UML State Diagrams are very similar to state diagrams seen in other design notations.The diagram contains states and transitions.Each state contains a name, and may also have associated actions. Actions are tasks (typically of a longer duration, and that can be interrupted by events). Actions start when the state is entered. A transition does not occur when an action completes; only an Event (see below) can cause a transition (however, an Event might occur as a result of tasks performed by the Action).Each transition is labeled; the label consists of three parts, all optional: Event [Guard] / Action. The event is what triggers the transition; a transition cannot occur until its controlling event does. The guard is a Boolean expression that describes a condition -- the transition does not occur unless the condition is true (there can, in fact, be several transitions on the same event, with different guard conditions, as long as the guard conditions are mutually exclusive). Finally, the activity is a short, uninterruptible task.Two special events exist. These are entry and exit. If they are defined, and association with Activities, those Activities occur immediately on entry (before any actions) and immediately on exit, respectively. This is true for all transitions into and out of the state. Exit occurs before any activity associated with the transition, and entry (on the new state) occurs after. Entry activities occur before state actions.What is a State Diagram?The goal of each phase of ProVision is to produce a specific kind of knowledge -- a list of requirements, a description of how requirements can be met, a working and deployed system. Each of those goals is supported by some of the UML diagrams, as shown above. This does not mean there is no place for other diagrams. Keep in mind that the goal of the UML is to facilitate communication between those producing a specific kind of work product, and between those taking one kind of work product, and using it to develop other work products.How does ProVision use the UML?Hopefully, you can now identify the types of UML diagrams and where they fit into ProVision. There are notations and concepts in the UML that have been summarized heavily, or omitted, from this presentation. Those interesting in learning more should surf to the UML Adoption Committees website, which is accessed through the SETG Communications page (click on Topic Sites to see a list of the sites). There, you will find information about the UML, a reference list, and a page that details how the UML relates to ProVision.

Documents

UML-in-an-hour