1. Software Modeling with UML
TBD: check out the following tool: “It integrates with Google Docs/Drive. The free version seems adequate enough to do basic UML diagramming”
The construction and maintenance of software systems depends on having good visual models. Software is intangible and complex. Visual modeling makes software more tangible which helps reduce complexity.
Visual modules are information rich and easier to verify than natural language descriptions. Most people have heard the proverb that “a picture is worth a 1,000 words” (or as computer people like to say, “1024 words”). Visual models convey important system concepts conveniently and quickly. In most cases explaining the same concepts with words would require more effort and carry a greater risk of being ambiguous and incomplete.
(Visual modeling is a technique for dealing with the complexity of developing and maintaining software systems.)
(Software systems are among the most complex artifacts ever created by humans. Among all systems in the world, software systems are second only to biological systems in their complexity.)
Copyright 2013, Eddie Burris

2. Modeling is an important part of any engineering discipline that deals with complex systems
Building contractors rely on scale models and blueprints
Electrical engineers rely on schematics
Civil engineers rely on structural models
Copyright 2013, Eddie Burris

3. Models are useful for simplifying and visualizing that which is otherwise too complex to comprehend all at once.
Having a dynamic model of the solar system makes it easier to understand the motion of the planets.
Models of the DNA double helix are probably more familiar to most people than the real thing
For example, (first bullet)
What is shown is an orrery, or mechanical model of the solar system.
Models can be dynamic or static. The pictured orrery is a good example of a dynamic model.
Recognize the image in the lower right? Not many people will. On the other hand, many people will instantly recognize the image on the lower left as the DNA double helix. It’s ironic because both depict the DNA double helix, but the model is more recognizable than an image of the actual substance. It’s a good example of using a model to simply something that is otherwise too complex to deal with in its standard form.
[Image of DNA double helix comes from: From Wasserman, Dungan, and Cozzarelli, 1985]
Copyright 2013, Eddie Burris

4. Modeling Concepts
A model is an abstraction or simplification of something too complex to deal with in its entirety. Models hide details that aren’t immediately important for the task at hand.
The most important decision when creating a model is deciding what details to hide.
Considerations of perspective, level of abstraction, and purpose all factor into the decision.
Copyright 2013, Eddie Burris

5. Perspective
Complex artifacts may be viewed from multiple perspectives. For example, Google Maps offers map view and satellite view of most cities.
You can model from different perspectives.
The two different views offer different types of details.
Copyright 2013, Eddie Burris

6. Level of Abstraction
Complex artifacts may also be viewed at different levels of abstraction. For example, Google maps also allows you to zoom in or out on a map.
Copyright 2013, Eddie Burris

7. The model’s purpose drives perspective and level of detail
A model is an abstraction from a certain perspective, at a certain level of detail, that serves a particular purpose.
The purpose for creating the model drives the selected level of detail and perspective.
For example, if you are just starting out on a cross country journey the most useful model is likely to be a high-level map.
On the other hand, if you are more interested in recognizable landmarks at your destination, the most useful model is likely to be a low-level satellite view.
Copyright 2010, Eddie Burris

8. Amount of detail or level of
Dimensions of a Model
More Detail
Amount of detail or level of
abstraction
Here is another example that illustrates the concepts of perspective, level of detail, and purpose in the context of building construction. Buildings are another example of complex artifacts that can benefit from modeling.
As was mentioned earlier, the actual models in any domain vary along two main dimensions: perspective or type of model and level of abstraction. The purpose for creating the model determines the perspective and level of abstraction.
During building construction standard perspectives are: structural, electrical and heating and ventilation. In the image above, these different perspectives are shown along the X-axis. Each perspective may call for models at different levels of detail. For example, during the planning stage a scale model might be created to help stakeholders conceptualize the construction plans. Once approved, more detailed construction plans in the form of blueprints might be drawn up. The image above also shows the electrical perspective from two different levels of detail: a wiring diagram and detailed schematic for certain electronics, say a home alarm system.
Less Detail
Structural
Electrical
Heating and Ventilation
Perspective
Copyright 2010, Eddie Burris

9. Amount of detail or level of
Software Models
More Detail
Amount of detail or level of
abstraction
But, we aren’t interested in building construction, we are interested in software development.
The models used during software development also vary by perspective and level of detail or abstraction. The purpose for creating a model will determine its form.
The image above shows three different perspectives from which to model software: business process (or domain), structural and behavior.
During system specification models of the problem domain and business process are used to better understand system requirements (e.g. Use case diagrams).
Structural and behavioral models are used to explore and communicate planned system architecture and design (e.g. class diagrams and sequence diagrams).
Note, these aren’t the only perspectives from which to model software. Other useful perspectives from which to model software will be discussed later (e.g. deployment view, process view, etc.).
Less Detail
Business Process
Structural
Behavioral
Perspective
Copyright 2010, Eddie Burris

10. In general, models are used to:
Manage complexity
Visualize constructs that are otherwise intangible
Communicate with others
Specifically, during software development models are used to:
Better understand the problem domain and product requirements
Experiment with potential solutions before committing to an implementation
Document existing systems
Copyright 2010, Eddie Burris

11. Software Modeling During the Software Life Cycle
Several phases in the software life cycle can benefit from modeling:
Copyright 2010, Eddie Burris

12. Domain and Analysis Models
During the requirements phase, domain and analysis models are used to better understand business processes and product requirements.
Analysis models (Business process, problem domain modeling)
Copyright 2010, Eddie Burris

13. Architecture and Design Models
During the design phase, design models are used to explore and communicate design options/alternatives.
Design/Architecture models
Copyright 2010, Eddie Burris

14. Deployment Models
During development, physical deployment models are used to plan for deployment.
Copyright 2010, Eddie Burris

15. Implementation Models
Implementation models are used to document existing systems. This information is useful to those who will be maintaining the software.
…including the author that might not remember the details of implementation 6 month later.
Copyright 2010, Eddie Burris

16. UML
The de facto standard for software modeling is the Unified Modeling Language (UML). UML is the lingua franca of software modeling. Having one standard modeling language is refreshing considering the proliferation of programming languages developers must contend with.
The Unified Modeling Language (UML) is
“…a general purpose modeling language used primarily for specifying, visualizing, constructing, and documenting the artifacts of  software-intensive systems [OMG].”
Although the UML is most often used by software engineers to create technical documents, it can also be used by analysts to model business processes and concepts in the problem domain.
That was a quick introduction to software modeling. The rest of this lecture is on the Unified Modeling Language (UML), the standard modeling notation for software modeling. Before looking at specific diagram types, here is a quick introduction to UML.
“The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software based systems as well as for modeling business and similar processes.”
The Unified Modelling Language is a standard graphical language for modelling software based systems as well as business processes.
Copyright 2010, Eddie Burris

17. Object Management Group (OMG)
OMG! U R gr8!
The UML is defined and maintained by the members of the Object Management Group (OMG).
The OMG is a not-for-profit industry consortium that maintains programming standards such as UML, CORBA, and Model Driven Architecture (MDA).
It seems the Object Management Group (OMG) is popular among teens these days judging by the number of references to OMG! in teen text messages.
OMG! U R gr8!
Copyright 2010, Eddie Burris

18. UML Origins
UML started out as the unification of notations from three of the leading object-oriented methodologies of the late 90’s:
Grady Booch's methodology (the Booch method)
James Rumbaugh's Object-Modeling Technique (OMT)
Ivar Jacobson's Object-Oriented Software Engineering (OOSE)
As a consequence of its origins, UML has generous support for the object-oriented style of design and programming.
Copyright 2010, Eddie Burris

19. UML and OOP
UML evolved from object-oriented methods and has many features to support that style of programming.
These features of UML are easier to understand if you are familiar with the principles of object-oriented programming (OOP).
Copyright 2010, Eddie Burris

20. ObjectName : ObjectClass
Object Primer
A class is a template that describes the structure and behavior of the objects it represents
An object is anything with state, behavior and a unique identity
An object is a specific instance of a class
The notation for representing objects is very similar to that used for classes. The format for the name of an object is:
ObjectName : ObjectClass
where ObjectName is optional.
A class is a template that describes a general concept. Objects are instances of classes. Objects are runtime elements.
The UML has separate class and object diagram types.
Copyright 2010, Eddie Burris

21. UML is a notation, not a development methodology
The UML doesn’t prescribe process.
Certain UML modeling tools might favor one methodology over another, but the UML is silent on process.
Notation has a secondary, supporting role, in any methodology.
Copyright 2010, Eddie Burris

22. UML 2.x
UML 2.x defines 13 diagram types, 6 of which are structural types and 7 of which are behavior types. Four of the behavior diagrams describe the interactions between objects.
Copyright 2010, Eddie Burris

23. Static vs. Dynamic Modeling
Structural diagrams are static. They don’t have a time component.
Behavior diagrams are dynamic. They show how the artifacts being modeled change over time.
Admittedly, pyramids have a time component, it’s just on a geologic rather than human time scale.
Copyright 2010, Eddie Burris

24. Static vs. Dynamic Modeling
Static Structural Modeling
Both are abstractions. Most automobiles have an electric starter motor and a gasoline powered engine. When you turn the key to the start position the electric starter motor turns the engine until the gasoline powered engine engages. That an automobile has an electric starter motor and a gasoline powered engine is a static fact that can be modeled with a structural diagram (e.g. class diagram). The different states an automobile goes through as the engine is started and stopped is a dynamic aspect of the automobile that can be modeled with a behavior diagram (e.g. state chart diagram).
Static = structural modeling (no time component)
Dynamic = behavior modeling (time component)
Static software models represent aspects of the software that don’t change during program execution. For example, a deployment diagram is a static model. The location of an executing program doesn’t change while it is running.
Dynamic Behavioral Modeling
Copyright 2010, Eddie Burris

25. Syntax and Semantics
Languages are defined by rules for syntax and semantics
The syntax of a modeling language specifies valid symbols (usually visual) and their arrangement into diagrams
The semantics of a modeling language define the meaning of valid symbols and diagrams
Knowing a language means knowing the syntax and semantics of the symbols in that language.
The remainder of this lecture explores the syntax and semantics of the three most common UML diagram types:
Class diagram
Object diagram
Sequence diagram
Syntax and Semantics for UML Actor Symbol
Copyright 2010, Eddie Burris

26. Class Diagrams
Copyright 2010, Eddie Burris

27. Class Class diagrams are the most common diagram type in the UML.
A class represents an abstraction which captures the commonalities among a group of similar objects.
In programming terms, a class is a “blueprint” for creating objects.
Copyright 2010, Eddie Burris

28. Making the concept of class tangible
Here is a simple example to make the concept of class a little more tangible. Imagine a problem domain where cars are a central concept. There are different types of cars but they all share similar static attributes like color and horsepower along with behaviors like starting and stopping. The concept of a car can be modeled with a UML class diagram. Eventually, the class will be expressed in code using the features of some programming language. At runtime the class definition is used to create objects in memory that represent the original concepts of interest in the problem domain.
Copyright 2010, Eddie Burris

29. Class Diagrams
A class diagram describes the types of objects in a system and their relationships. Types are further described by attributes and operations.
UML class diagrams are used to model concepts in the problem domain as well as class definitions found in code.
For example, the UML diagram on the left documents the principle elements of our solar system. The diagram on the right documents classes in a GUI toolkit.
8 planets not counting pluto
UML class diagrams are used to model concepts in the problem domain as well as (class definitions found in code) classes expressed in implementation.
Class diagrams document the static aspects of a system. Static aspects are those aspects that don't have a time component. For example, the name of a class is static. It doesn't change over time.
Note, the thing you are modeling might have a dynamic component (planets revolve around the sun) but the purpose of the class diagram is to convey the static aspects of the thing you are modeling.
Can model real-world objects or pure software constructs
“A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.”
More specifically, a class defines the structure and behavior of a group of objects. A class is a blueprint or template for creating objects.
Copyright 2010, Eddie Burris

30. UML Class Symbol
The symbol for a class has a compartment for the class name and optional compartments for class attributes and operations. The class name is centered and bold.
The class BankAccount at different levels of abstraction.
Copyright 2010, Eddie Burris

31. Attributes An attribute is a named property of a class. Example:
The full format of an attribute is:
visibility / name : type multiplicity = default {property}
Where
visibility - indicates the visibility of the attribute. Attribute visibility may be public (+), private (-) or protected (#).
“An attribute is a named property of a class that describes a range of values that instances of the property may hold. ... An attribute represents some property of the thing you are modeling that is shared by all objects of that class Graphically, attributes are listed in a compartment just below the class name.”
Copyright 2010, Eddie Burris

32. Attributes [Cont.]
/ - indicates the attribute is derived. The value of a derived attribute may be calculated from the values of other properties. name – noun or short noun phrase naming the attribute. type - the type of the attribute, usually a class, interface or primitive type such as int. multiplicity – the number of objects referenced by this property. Attributes may represent an array of values. default - the default value assigned to the attribute when an instance of the class is created. property - additional properties of the attribute. Common property values include: ordered, unordered, unique, nonunique and readOnly.
classes have properties. A property is a “structural feature of a class” [UML Distilled p 35]. UML has two notational options for expressing properties: attributes and associations.
TBD: show a derived attribute using the / symbol:
- / onLoan : Boolean
TBD: add discussion of constraints
Copyright 2010, Eddie Burris

33. Visibility
Visibility is used to control access to attributes and operations.
Options include:
public (+) – accessible from any class.
private (-) – accessible only from within the class it is defined
protected (#) – accessible from within the class it is defined and from any of its subclasses
Copyright 2010, Eddie Burris

34. Defaults
What can you assume about the visibility of the two class attributes in the following class diagram? Is it reasonable to assume these are the only two attributes of the class?
Short answer: nothing, no.
In general, when reading a UML model, if something is unspecified, you can’t assume a default value. Instead, unspecified should be taken to mean “not important for the purposes of this model”.
Like a lot of features in UML, there is no default for visibility. If visibility isn’t specified you can’t assume any one of the values above (public, private, protected or package). Here, not shown means not important for the purposes of the model
UML has few defaults.
Remember, models are abstractions. Models with too many details are no longer good abstractions.
Designers of a modeling language are faced with no good choices when it comes to using defaults. Defaults are good in that you can express a lot with a little, but only when you want to express a lot. Sometimes you don’t know and would like a model that says “here are the high level concepts I’m sure about; the rest I don’t want to commit to right now.”
In general, UML has few defaults.
Not shown usually implies not there or not important for the purposes of this model.
The meta model behind UML does have defaults. For example, the default multiplicity for an attribute is [1] but if multiplicity isn’t shown you can’t assume it is [1]. What is the purpose of having a default then? It’s rarely ever done, but you can state upfront that the reader should assume all defaults apply. The problem with this is few readers will be fully aware of the defaults specified in UML’s meta model.
Copyright 2010, Eddie Burris

35. Derived Attribute
A derived attribute is one that may be calculated from the values of other properties.
In the following model hasFreeChecking is a derived attribute. It doesn’t have to be stored separately. It may be calculated based on the current value of balance.
If the formula for calculating a derived value isn’t obvious, the constraints between values can be documented with a note.
Copyright 2010, Eddie Burris

36. UML Notes
Notes are a flexible mechanism for adding comments to a diagram. Notes are rendered as a rectangle with a dog-eared corner and optional dashed line linking the note to a UML diagram element.
Notes in UML are like comments in programs. They don't change the executable characteristics of a program or semantics of a model, but they do help the human reader interpret what is written
Convenient way of attaching constraints or comments to model elements
Notes are free form. There are no restrictions on what can be included in a note.
Copyright 2010, Eddie Burris

37. Operations Operations specify class behavior.
Example operations on a class:
The full format of an operation is:
visibility name (parameters) : return-type {property}
Parameter format is:
direction name : type = default value
Direction, if specified, is one of: in, out or inout.
TBD: add discussion of constraints for operations.
The terms operation and method are well-defined in UML. Colloquially these words are used interchangeably. In UML the terms are used to distinguish between interface and implementation. An operation specifies an interface onto behavior. A method is an implementation of an operation.
Copyright 2010, Eddie Burris

38. Operations [Cont.]
property - additional properties of the operation. {query} is the most common property of operations. It means the operation returns a value and has no side- effects (doesn’t change the state of the object). (The other notational elements of operations are similar to the notational elements of attributes.)
Copyright 2010, Eddie Burris

39. Static Attributes and Operations
Attributes and operations may be associated with the class (static) or instances of the class (non-static)
Static attributes and operations are underlined
Attributes and operations may be associated with either a class or the objects of the class. Attributes associated with the class are called static or class attributes and their value is shared among all objects of that class. Attributes associated with the objects of a class are called non-static or instance attributes and their value is unique for each object. Operations may be static or non-static also. Static operations are associated with the class and can access only static attributes. Non-static operations are associated with each object and operate on the object instance for which they are called.
Copyright 2010, Eddie Burris

40. Abstract Classes
An abstract class is a class that can’t be instantiated, usually because it lacks implementation for all of its operations.
Abstract classes are missing some implementation, but they are richer for it! They offer inheritable features to subclasses, and most important, they offer an abstract interface that clients can depend on.
In general, dependency is bad, but depending on an abstract class is a weak form of dependency because clients aren’t dependent on specific implementations.
Copyright 2010, Eddie Burris

41. Abstract Class Syntax
You can write the class name in italics or include the property {abstract} next to the class name.
Methods as well as classes may be marked as abstract.
If any method on a class is marked abstract, the class must be marked abstract as well. OR
Copyright 2010, Eddie Burris

42. Relationships
Class diagrams show class elements and their relationships
There are 4 types of relationships between class elements
The class Harbor has an association relationship with the class Boat because objects of type Harbor are structurally related to objects of type Boat. Whenever you have a Harbor you usually also have instances of Boat that come with it. In terms of implementation, Harbor might contain an array of references to instances of the class Boat.
The class Boat is a generalization of SailBoat. A SailBoat can be used anywhere a Boat is expected. If this were an implementation model, you could assume the class SailBoat inherits from the class Boat.
Boat has a dependency on Trailer because it has a method load() which accepts an instance of Trailer as a parameter. A change to the interface or behavior of class Trailer might cause a change to the class Boat (specifically the method load() in the class Boat).
Boat realizes the interface Washable because Boat implements the contract specified by the interface Washable. Here the contract specified by the interface Washable contains only one method: wash().
The four different types of association are distinguished by the line and arrow style used on each association.
Copyright 2010, Eddie Burris

43. Association
An association models a connection that lasts over time. The lifetimes of the elements don’t have to coincide exactly, but the relationship is more structural.
If a person only has contact with an accountant once a year to have his or her taxes done, that relationship probably isn’t structural. It’s probably better modeled as a dependency. If, on the other hand, that person is a small business owner and is in regular contact with his or her accountant, the relationship could be considered structural. (Better yet: person is-a (inheritance) small-business-owner and the abstract class of small business owner is structurally associated with the class Accountant.)
TBD: can work in an oop concept with this example. Pass an accountant to the person class to do taxes. It’s better to pass the accountant to the person class because that is where all of the data needed to do the taxes are located:
Person
+doTaxes(Accountant)
Copyright 2010, Eddie Burris

44. Multiplicity
Multiplicity is used on attributes and associations. The following diagram says that every airline has zero or more flights and on each flight there is 1 or 2 pilots.
A convenient way of interpreting multiplicities is to read the diagram as, “For any one instance of A it may be associated will "y" instances of B.  For any one instance of B it may be associated with "x" instances of A.”
Copyright 2010, Eddie Burris

45. Multiplicity 1 Exactly one (default for attributes) * 0 or more 1..*
4, 6, 8,12
exactly 4, 6, 8 or 12
10..30
10 to 30
Discontinuous multiplicities no longer valid in UML 2.x.
Why have a default then? It allows simplified diagrams when you state upfront that defaults should be observed.
The default multiplicity for an attribute is [1] but if the model doesn’t show multiplicity for an attribute you can’t assume it is [1]. It’s possible that multiplicity isn’t specified because it isn’t an important detail for the abstraction being shown.
Copyright 2010, Eddie Burris

46. Navigability Copyright 2010, Eddie Burris
Navigability is important for assessing coupling.
Copyright 2010, Eddie Burris

47. Navigability
The arrows on associations show navigability—the ability to go from one class to another.
If there are no arrows you can’t assume bidirectional navigability. It might be that at the current level of abstraction for the model the author hasn’t yet specified navigability
If you want to make it clear that there is not navigability, place an x on the association next to the class that you can’t navigate to.
With no arrows you can’t assume bidirectional.
TBD: show how navigability is implemented in code.
Ambiguity on both sides
Ambiguity on one side
No ambiguity
Copyright 2010, Eddie Burris

48. Association Details Copyright 2010, Eddie Burris
Associations may have a name or label. Class names are normally nouns and association names are normally verbs or verb phrases that describe the association.
Association names are directed. The direction of the association can be made explicit with a solid arrow.
How to read multiplicities: “For each course there are 10 to 30 students. For each student there are 0 or more courses.”
In addition to navigability and multiplicity the ends of an association may also indicate role names.
Copyright 2010, Eddie Burris

49. Example Copyright 2010, Eddie Burris
The class diagram above, among other things, says: a library has 1 or more books and 0 or more patrons. Class methods suggest the system supports borrowing and returning books as well as checking their availability. It also makes clear that a book and a copy of a book are two separate concepts.
Copyright 2010, Eddie Burris

50. Attributes vs. Associations
Q: What’s the difference between an attribute and an association relationship? A: Not much!
For example, if you want to express that a person has a date of birth, is it better to express this idea with a text attribute or as an association? OR
Both are ways of expressing a property or structural relationship.
It’s also convenient to model important classes as associations. (Easier to capture relationships.)
If you want to see the detail of the data type you will of course have to show it as an association.
Association
Text Attribute
Guideline: Model value objects as attributes and reference objects as associations.
Copyright 2010, Eddie Burris

51. Dependency Dependency is the weakest of all relationships.
A depends on B, simply means that a change in the interface of B might require a change to A
Is an association also a dependency?
Copyright 2010, Eddie Burris

52. Generalization
Generalization implies substitutability. If A generalizes B, a B can be used any place an A is expected.
Not convinced yet that UML models have expressive power? List all that you can conclude from the model on the right
In Java there are components and containers. A container is a component so it can be used anywhere a component is expected (i.e. you can nest containers within containers). Each container can contain zero or more components and each component can be in at most one container but doesn’t have to be in any container at all.
Copyright 2010, Eddie Burris

53. Realization
The realization relationship is used to show that a class implements an interface
The realization relationship is represented with a dashed line and hollow arrow:
Copyright 2010, Eddie Burris

54. Aggregation
Aggregation is a special type of association that adds some additional semantics to the association relationship.
Specifically, aggregation specifies a whole-part relationship between two classes. Aggregation is expressed with an open diamond next to the class that represents the "whole" in the whole-part relationship.
Copyright 2010, Eddie Burris

55. Composition
There is a stronger form of aggregation, called composition, that adds some additional semantics to plain aggregation
The component may be part of only one composite at a time
The composite has responsibility for the component. The lifetime of the component generally tracks that of the composite. In most cases, when the composite is created the component is created; when the composite is destroyed the component is destroyed.
A better example: Item <>---- Bid
An instance of an Item is associated with 0 or more Bids. The lifetime of a Bid is strongly associated with the item the bid is associated with. If the item goes away, you would also delete the bid.
Copyright 2010, Eddie Burris

56. Association, Aggregation, Composition
TBD: Add dependency relationship above Association.
Copyright 2010, Eddie Burris

57. Active Class
An active class has its own thread of control or execution. Methods of an active class may be asynchronous
Copyright 2010, Eddie Burris

58. Object Diagrams
Copyright 2010, Eddie Burris

59. Object Diagram Objects are a runtime concept
An object diagram shows a snapshot of objects as they exist at one point in time
Copyright 2010, Eddie Burris

60. Object Diagrams
An object diagram shows a complete or partial view of the objects and their relationships in a system at a particular point in time.
The object diagram above shows a portion of the objects that exist at a particular point in time for the system described by the example class diagram on the previous slide. The object diagram illustrates a moment in time when there is a library which owns two copies of the book Code Complete, one of which is on loan to the patron A. Developer.
Copyright 2010, Eddie Burris

61. Object Diagram Details [cont]
Object notation shows up on sequence and communication diagrams. For instance, the objects involved in the collaboration defined by a sequence diagram are listed across the top of the diagram:
Copyright 2010, Eddie Burris

62. Object Diagram Details
The name of an element in an object diagram is underlined. The format of the name is objectName : ObjectType. ObjectName or ObjectType may be omitted, but not both at the same time. If the name is omitted, a colon is needed in front of the class name to distinguish it from the name of an object. Consequently, the three separate allowable formats are:
Copyright 2010, Eddie Burris

63. Object Diagram Details [cont]
An object diagram can help clarify a class diagram.
In the class diagram in figure x, both ends of the association attach to the same classifier. The object diagram helps clarify the relationship between instances of the class Node. It shows that the single association accounts for two outgoing references.
Copyright 2010, Eddie Burris

64. Object Diagram Details [cont]
Object diagrams are useful when the runtime object structure is not obvious from the class diagram.
For example, figure x helps to explain the functioning of the decorator design pattern as it is used in the hierarchy of Java input stream classes.
Copyright 2010, Eddie Burris

65. Code fragment and corresponding object diagram:
Abbreviated class diagram for the decorator design pattern as it is used in the hierarchy of Java input stream classes.
Code fragment and corresponding object diagram:
Copyright 2010, Eddie Burris

66. Sequence Diagrams
Copyright 2010, Eddie Burris

67. Sequence Diagrams
Sequence diagrams are probably the second most popular UML diagram type after class diagrams
Sequence diagrams are often used in conjunction with class diagrams to describe a design or design pattern
A class diagram conveys static structural elements and a sequence diagram shows object interactions for a typical scenario of use
The class diagram shows structural components and their relationships.
Sequence diagrams may also be used to illustrate the object interactions necessary to realize a use case (i.e. logically execute a use case using analysis classes).
Copyright 2010, Eddie Burris

68. Sequence Diagram for Simple Code Fragment
Copyright 2010, Eddie Burris

69. Sequence Diagram Example
Sequence diagrams are very intuitive. The sequence diagram on the next page shows the object interactions necessary to check out a book in a simple library automation system
Objects involved in the interaction are displayed along the horizontal dimension and the sequence of messages that define the interaction unfold top-to-bottom along the vertical dimension
Copyright 2010, Eddie Burris

70. Class Diagram (sans relationships)
Found message – messages that have an unspecified source. Sequence diagrams are often started with a found message.
Message arguments are usually values but may also be parameter names.
Execution occurrences show the time a method is active. Each execution occurrence represent a stack frame. Execution occurrence bars are optional.
Sequence Diagram
Copyright 2010, Eddie Burris

71. Misc Object lifeline Object creation and destruction
In UML 1.x the dashed line that dropped down from an object symbol was called the lifeline and it represented the period of time the object was in existence. In UML 2.0 the term lifeline refers to the box and dashed line.
Notice that execution occurances are optional.
Most messages represent synchronous method calls. This means the caller blocks or waits while the method executes. Messages may also be asynchronous which means the caller doesn’t wait. The call returns immediately and the method is executed asynchronously on another thread. The UML uses a filled arrow head to represent synchronous messages and a stick arrow to represent asynchronous messages.
There is a subtle notational difference between synchronous and asynchronous messages.
Asynchronous messages are common with remote procedure calls where it is difficult to predict the runtime of the computation.
Asynchronous Messages
Self-Call and overlapping execution occurrence
Copyright 2010, Eddie Burris

72. Q: What, if anything, is wrong with the following sequence diagram?
Copyright 2010, Eddie Burris

73. Answer
It’s not wrong, per se, but what it says is suspicious. It says, :CatalogForm sends a message to :Product, and then :Product sends a message to :CatalogForm.
It’s possible the modeler really wanted to say, :CatalogForm sends a message to :Product and :Product returns the product data.
Another reason to be suspicious of the original sequence diagram is it doesn’t show any data being passed. It’s possible this was a detail the modeler chose to not show.
Another interpretation is to assume the second message is correct but the modeler intended the first message to be an asynchronous one.
Copyright 2010, Eddie Burris

74. Package Diagrams
Abstraction is the standard way of dealing with complexity.
When the number of modeling elements in a design becomes unwieldy, consider organizing related modeling elements into separate packages.
Package diagrams are general-purpose constructs for organizing UML elements into higher-level units.
Each package defines a namespace as well as abstraction for the modeling elements contained within it.
Packages can be used to group nearly any UML modeling element, but the most common use of packages is to group related classes, such as the classes that make up a component of an architectural style. In the example above, packages are used to show the contents of each layer in a 3-layer architecture design.
Copyright 2010, Eddie Burris

75. Component Diagrams
There isn’t universal agreement on exactly what constitutes a component.
In general, a component is a deployable unit of software that provides services and may depend on the services of other components in order to function.
Thus, a component has a provided interface, and if it depends on other components for services, it will have a required interface as well.
Interest in components is driven by the desire to design and assemble software solutions from prefabricated components the same way electrical engineers design and assemble digital devices from catalogs of IC components.
"The functionality provided by a component is specified by a set of provided interfaces that the component realizes. In addition to providing interfaces, a component may require interfaces in order to function. These are called required interfaces."
"Components are about how customers want to relate to software." "want to mix and match pieces from various manufactures"
"Components represent pieces that are independently purchasable and upgradeable“
“Components are units of deployment, i.e. they run within computer systems” “Each component has a published interface that defines its responsibilities as a set of services” “Components are assembled to realize solutions.” “deployable units of software that execute within some well-defined environment”
“facilitate the design and assembly of systems from a mix of newly and previously developed components”
Copyright 2010, Eddie Burris

76. Component Diagrams [Cont.]
A UML component diagram shows components and connections between components in terms of provided and required interfaces.
For example, a Tomcat application server provides services through the http protocol (its provided interface) and depends on the services of a relational database (its required interface).
Copyright 2010, Eddie Burris

77. Component Diagrams [Cont.]
The Tomcat application server runs in an environment that includes browsers and a relational database.
Having these well-defined interfaces allows different combinations of browsers, application servers and relation databases from different vendors to work together as long as, for every component that requires an interface, there is a corresponding component that provides the interface.
Copyright 2010, Eddie Burris

78. Deployment Diagrams Software has to run somewhere.
Deployment diagrams show how logical system components are physically deployed to hardware and software execution environments.
The main elements of a deployment diagram are nodes, artifacts and communication paths.
Deployment diagrams show the physical location of system components.
Deployment diagrams show the physical distribution of the processing.
System components are physically deployed to hardware and software execution environments.
Deployment diagrams are ideally suited for modeling the physical view in Krutchten’s 4+1 view model of software architecture.
“Deployment diagrams show a system’s physical layout, revealing which pieces of software run on what pieces of hardware.”
“describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.”
Copyright 2010, Eddie Burris

79. Deployment Diagram [Cont.]
Nodes are computational resources that host software artifacts. Two types of nodes are used in deployment diagrams. A device node (often stereotyped as <<device>>) represents physical hardware. For example, a PC might be modeled as a device node. An execution environment node is a software container such as an EJB application server which hosts software artifacts. Tying together all three model elements, it’s not uncommon for a device node to host an environment node which in turn hosts a project artifact such as an .ear file.
Artifacts are products of the software development process. An artifact is the manifestation of logical elements such as classes and components. Example artifacts include executable content such as exe’s, dll’s and jsp’s, as well as static content such as html and configuration files.
Communication paths indicate generic communication capabilities between nodes. Labels on communication paths indicate the communication protocol.
Note, whether something is an artifact or a node depends on how it is used. For example, if a solution includes database stored procedures, you may choose to model the database as a node. Alternately, if the database is just another system element it could be modeled as an artifact.
Copyright 2010, Eddie Burris

80. Deployment Diagram [Cont.]
Artifacts may be listed by name within a node or represented using a class rectangle. When using a class rectangle to represent an artifact, it’s customary to add a dog-eared paper icon to the upper right-hand corner of the class rectangle.
Tag values may be included on nodes and artifacts. For example, the tag value {JavaScript = True} is used on the Browser Client node to indicate the client must have support for JavaScript turned on in order to serve as a client of the system.
“UML allows the normal (nonunderlined) representation of an artifact to be interpreted as an instance of that artifact if the context is clear.” Many models will use artifacts as instances but not underline the title.
Copyright 2010, Eddie Burris

81. Deployment Diagram Copyright 2010, Eddie Burris
(A deployment diagram shows nodes, their contents, and communication between nodes.)
Deployment diagrams show the allocation of artifacts to node. An artifact is a software/physical deliverable such as an executable, class, dll, user manual, etc. A node is a hardware or software resource that provides a computational environment. Here are some example nodes: PDA, Linux machine, Tomcat servlet container, J2EE server, iPhone, etc.
Artifacts are deployed on nodes.
Nodes may contain nodes. This is represented using nesting or with a composition relationship.
Nodes represent computational resources.
Abstraction and virtualization aside, eventually software has to run on some physical device in some environment (hardware and software environment).
There isn’t a one-to-one correspondence between nodes and devices. A single node might represent a cluster of servers configured to work together balancing the load for a single application.
Communication paths are usually bidirectional. One-way communication paths can be indicated by adding an arrow to one end of a communication path.
I could update the example to include dependencies between artifacts on a node and multiplicity between artifacts within the same node. See [Booch 2007 p 174] for an example.
Copyright 2010, Eddie Burris

82. Composite Structure Diagrams
Composite Structure Diagrams show the internal structure of a class or component. They can be used to clarify/express which object relationships are valid and which are invalid.
For example, consider the following class diagram.
According to the diagram, a car is comprised of 4 wheels and an engine. A boat is comprised of an engine and a propeller. The relationship between engine and wheel and the relationship between engine and propeller are both optional. Although the class diagram doesn’t enforce it, presumably an engine is connected to two wheels or a propeller but not wheels and a propeller simultaneously.
Example is from: Conrad Bock: "UML 2 Composition Model", in Journal of Object Technology, vol. 3, no. 10, November-December 2004, pp ,
Copyright 2010, Eddie Burris

83. Composite Structure Diagrams [Cont.]
As stated, the class diagram permits object configurations that are valid according to the diagram but unreasonable considering the semantics of the classes. Here is one example:
The object diagram above says there is a car with 4 wheels and an engine but the engine is associated with a propeller rather than two of the car’s wheels (the class diagram specifies a 2-wheel drive car). The diagram is valid from the perspective of the class diagram but describes a state that is invalid considering the semantics of the classes.
In this example, it is relatively easy for you to recognize invalid object states because of your familiarity with the concepts being modeled. If you were depending on a class diagram alone to understand a system of foreign concepts, it wouldn’t be so easy to dismiss invalid object states.
You might be tempted to remedy the problem by drawing a valid object diagram (car, 4 wheels, and an engine connected to two of the wheels). However, this would be only one valid state. It doesn’t say it is the only valid state.
Copyright 2010, Eddie Burris

84. Composite Structure Diagrams [Cont.]
When valid relationships are dependent on context, the design can be made more explicit by supplementing the class diagram with a composite structure diagram. Such a pairing helps to clarify valid and invalid runtime relationships.
Figure x shows two composite structure diagrams, one for a Car and one for a Boat. A boat is composed of 4 wheels and an engine with the engine associated with the two front wheels. A boat is composed of an engine associated with a propeller. The diagrams show how items contained in a class relate to each other.
Composite structure diagrams complement class diagrams. A class diagram shows relationships between types independent of context. A composite structure diagram shows how items contained in a class relate to each other in the context of the class that contains the items.
The format for the name of a part within a composite structure diagram is: <RoleName> : <PartType>. The role name and part type are individually optional. Note, the part name is bold but not underlined. Composite structure parts are not object instances.
----
Was: When valid relationships are dependent on context, something more is needed to communicate the design.
Copyright 2011, Eddie Burris

85. Composite Structure Diagrams [Cont.]
As figure x illustrates, composite structure diagrams may also be used to show the internal structure of a component including the relationship between a component’s parts and the component’s provided and required interfaces.
In summary, composite structure diagrams are useful anytime you need to show the internal structure of compositions.
---- review and delete what’s not needed
“The name of a composite structure part uses the format of role name : Class Name [multiplicity] , where the role name defines the role played by a part within the composite structure.” role name and class name are individually optional
“Parts are specified by the role they play in the containing class, written as <roleName> : <type>.”
“The multiplicity, or number of instances of that part, is written in the upper right-hand corner of the part.”
“shows how this class is decomposed internally into two parts and which parts support and require the different interfaces”
“describes the internal structure of a class and the collaborations that this structure makes possible.”
“Modeling a Class’s Internal Structure”
“It is a diagram that represents the structure of compositions, that is, it shows the relationships of the parts to the whole.”
“A composite structure diagram describes the internal structure of things such as classes and components.”
“shows the internal structure of a class or component”
“There is no rigid line between a composite structure diagram and a general class diagram”
“How can a modeler express which object relationships are valid and which ones are not?”
“… class diagrams are not good at expressing how items contained in a class relate to each other. This is where internal structure comes in: it allows you to specify relationships in the context of the class that contains them”
“Show the parts contained by a class and the relationships between the parts”
“They model how objects work together inside a class, or how objects achieve a goal.”
“Composite structures provide a view of your system’s parts”
“the composite structure diagram is useful during design to decompose classes into their constituent parts and model their runtime collaborations”
“The essential elements of a composite structure are its parts, ports, interfaces, and connectors.”
“A port is a special property of a classifier that specifies a single interaction point between the classifier and its environment or between the classifier and its internal parts.”
“The composite structure and its parts interface with their external environment through ports, denoted by a small square on the boundary of the part or composite structure.”
“To these ports, we connect the interfaces that define the details of the composite structure’s interactions. These interfaces are commonly shown in the ball-and-socket notation.”
“Connectors within composite structure diagrams provide the communication links between the composite and its environment, as well as the means for its parts to communicate internally.”
Copyright 2010, Eddie Burris

86. Use Case Diagrams
There is a big difference between writing use cases and modeling use cases with UML.
It’s like the difference between writing a book and creating the table of contents for the book.
The real value of use cases comes from their textual form. There is no better technique for discovering and documenting functional requirements.
A UML use case diagram provides a visual table of contents for the use cases that have been or will be written out in narrative form.
Specifically, the UML provides notation for specifying actors, use cases and the relationships between them. Together these elements summarize the external system behavior of the system under construction.
The discussion here is limited to UML notation for use case modeling. See lesson x for a more detailed description of use case elements and guidance on creating the narrative form of use cases.)
----- Notes
[What are use cases?]
A use case describes a goal-oriented interaction between an external actor and the system under consideration.
Written form of a use case = “realization”
Copyright 2010, Eddie Burris

87. Use Case Diagram [Cont.]
Figure x shows a use case diagram with 5 use cases and 3 actors. The system boundary box helps clarify the scope of the system. The use cases within the system boundary box represent functionality you intend to implement. The actors outside the system boundary box represent external entities that interact with the system.
TBD: I should probably mention that a use case diagram is a System Context Diagram. It models the system at the highest level of functionality (
Actors are usually represented as stick figures with the name of the actor written below the icon. Alternately, actors may be represented using the classifier notation with the key word <<actor>> at the top. The notations are interchangeable, but some prefer to represent human actors with stick figures and external system actors with rectangles.
Use cases are represented as ovals with the title of the use case in the center. Behavior common to two or more use cases may be factored out and represented in a separate reusable use case. There is no need to repeat the behavior in all the use cases where it is needed. The functionality can be included by name when needed. The include relationship is the most common relationship among use cases. There are others such as extend and generalization but these tend to generate more debate than practical benefit.
Notes
“The best way to think of a use case diagram is that it’s a graphical table of contents for the use case set. It’s also similar to the context diagram used in structured methods, as it shows the system boundary and the interactions with the outside world. The use case diagram shows the actors, the use cases, and the relationships between them:• Which actors carry out which use cases• Which use cases include other use cases”
“The connection between actor and use case is a communication association (or communication for short).”
“Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases.”
System Context Diagram = Level 0 DFD
“A u s e c a s e d i a g r a m is a diagram that shows a set of use cases and actors and their relationships.”
“The UML provides a graphical representation of a use case and an actor, as Figure 17-1 shows. This notation permits you to visualize a use case apart from its realization and in context with other use cases.”
“Graphically, a use case is rendered as an ellipse.”
“As Figure indicates, actors are rendered as stick figures.”
“Actors may be connected to use cases only by association. An association between an actor and a use case indicates that the actor and the use case communicate with one another, each one possibly sending and receiving messages.”
“You use an include relationship to avoid describing the same flow of events several times, by putting the common behavior in a use case of its own (the use case that is included by a base use case).”
“You render an include relationship as a dependency, stereotyped as include.”
Other possible relations between use cases are extends and generalizes.
Copyright 2010, Eddie Burris

88. Package Diagram - Example
Package diagrams are also useful for showing the composition of and relationships between major architectural components in a large-scale system.
The conceptual model below illustrates how the elements of a solution might be split into the elements of a solution being organized according to the layered architecture style with the classes and types a package defined to hold the elements of each layer.
Principles of good design can be used to decide how to group model elements into packages include Common Closure Principle and Common Reuse Principle.
“In the UML, the package is a general-purpose mechanism for organizing modeling elements into groups.”
“Well-designed packages group elements that are semantically close and that tend to change together.”
Package = design-time abstraction. Overview diagrams represent runtime abstractions.
“describes how a system is split up into logical groupings by showing the dependencies among these groupings.”
Package diagrams are used to group other diagramming elements.
“used to group together elements that are semantically related and might change together. It is a general purpose mechanism to organize elements into groups to provide better structure for system model. ”
“Package by itself is packageable element, so any package could be also a member of other packages. ”
“A package is rendered as a tabbed folder - a rectangle with a small tab attached to the left side of the top of the rectangle. If the members of the package are not shown inside the package rectangle, then the name of the package should be placed inside. ”
“A diagram showing a package with content is allowed to show only a subset of the contained elements according to some criterion. ”
Packagable elements include…The most common types of UML elements grouped in packages are: class, interface, use case, component and another package.
“The most common use for package diagrams is to organize use case diagrams and class diagrams”
Each package represents a namespace
Research shows the capacity of short-term memory is on the order of units of information [Miller 1956]. Chunking is a way of overcoming this human limitation.
Packaging diagrams is the chunking mechanism built into the UML.
User Interface
Application features and functionality
Domain-specific software services
Domain-independent utilities and support objects
You can have packages within packages
The notation for a package is a rectangular box with a tab on the top left.
It you want to show the concept of a group of modeling elements, without revealing the actual elements, a package may be drawn that shows no internal elements. In this case the package name goes inside the package. More commonly, the package will contain modeling elements with the name of the package on the tab.
A package is a grouping construct used to organize related diagramming elements.
A package diagram is used to organize related diagramming elements into higher-level constructs.
group related model elements and
As the number of model elements in a design grows, the design becomes harder to understand and manage.
For example, the elements that comprise a major component in the architecture of a large-scale system can be grouped into a package.
Copyright 2010, Eddie Burris

89. Package Diagram
Alternate notation for showing the containment relationship between packages
Copyright 2010, Eddie Burris

90. Package Diagram Visibility and dependency Copyright 2010, Eddie Burris
Elements within the package Façade have public visibility to all elements that have access to FriendlyService. Elements within the package Library are not visible outside the package FriendlyService.
The primary notations in a package diagram are the package symbol and dependency relationship.
A dependency exists from package A to package B is there are any elements of package A dependent on any elements from package B.
Copyright 2010, Eddie Burris

91. Interaction Diagrams Interaction Diagrams Sequence Diagrams
Communication Diagrams (called Collaboration diagrams in UML 1.x)
Timing Diagrams
Interaction Overview Diagrams (Not described here)
Interaction diagrams are a special type of behavioral diagrams that emphasize the interaction/communication between objects.
Recall that the other three behavioral diagrams are: use case, state machine and activity. Interaction diagrams are a special class of behavioral diagrams that emphasize object interaction.
Interaction diagrams complement class diagrams. Class diagrams model the static structure of software, and interaction diagrams model its dynamic behavior. Interaction diagrams show how objects interact at runtime to complete a task.
Copyright 2010, Eddie Burris

92. Combined Fragments The sequence diagram’s forte isn’t control logic
Sometimes it’s desirable to show some control logic in a sequence diagram
Combined fragments can be used with sequence diagrams to show some general control logic along with object interactions
All abstractions offer a limited view of the thing they represent. Sequence diagrams offer a perspective that highlights example object interactions for a typical scenario. The sequence diagram’s forte isn’t control logic. Activity diagrams are much better for showing control logic. Sometimes it’s desirable to show some control logic with a sequence diagram. To satisfy this need, UML 2.0 added combined fragments which can be used to show limited control logic and other special constraints on groups of messages.
Copyright 2010, Eddie Burris

93. Combined Fragments—Example
The following example shows an alternate design for the simulator example given earlier. In this example, the input dataset size is used to decide which algorithm to run. When the input size is > 100 the heuristic algorithm is used, otherwise the conventional algorithm is used.
A combined fragment has one or more interaction fragments which are the operands for the interaction operator. The interaction operator determines how the interaction operands are interpreted. In the example above, the interaction operator alt (“alternative”) implies that only the interaction fragment with the guard condition that evaluates to true will be executed.
Copyright 2010, Eddie Burris

94. Another Example
The following example uses a combined fragment to clearly show the conditional logic implied in an earlier example
Copyright 2010, Eddie Burris

95. Other Interaction Operators
loop – the fragment may execute multiple times. A guard condition controls the number of iterations. It’s common to have a guard condition of the form: [for each …]
par – the fragments execute in parallel
neg – indicates an invalid interaction
TBD: Show a loop example
Copyright 2010, Eddie Burris

96. Communications Diagram
Type of interaction diagram
Similar to sequence diagram because it shows object interaction, but a communication diagram also shows object relationships
Use to be called collaboration diagram in UML 1.x
Comm. Diagram = seq diagram with shades of a class diagram
Links are instances of associations. Links between objects. Associations between classes.
Objects are arranged to convey relationships between objects and solution structure. Numbering is used to show sequence of messages.
TBD: discuss transient links (i.e. for local variables) (still used in UML 2.0? Key words <<local>> etc, aren’t??)
Copyright 2010, Eddie Burris

97. Example
Copyright 2010, Eddie Burris

98. Activity Diagrams
Activity diagrams are useful for describing procedural logic, business processing and workflows
They are just as useful for business modeling as software modeling
Activity diagrams mix control flow and dataflow. If you’re familiar with older modeling techniques, UML 2.0 activity diagrams can be understood as:
[What are they? Role?]
[Not just for s/w systems. Used for business process modeling, workflow modeling, basically any procedural activity.]
[Changed for UML 2.0. In UML 1.x activity diagrams were a special form of state machine diagrams. In UML 2.0 they are their own diagram type.]
[Brief def: UML 2.0 activity diagram = Flow charts (with support for modeling parallel behavior) + Data Flow Diagrams (DFD) (where data is an object)]
Activity diagrams mix control flow and data flow. Potential need. Those new to modeling often instinctively write diagrams of their own invention that mix dataflow and control flow.
Behavioral diagram like a sequence diagram but while a sequence diagram focuses on the interaction between objects (it’s always clear what object is responsible for any particular activity) activity diagrams focus on the logic of the activity itself.
Another point of contrast between activity diagrams and sequence diagrams is that sequence diagrams are typically used to show one flow of activity where as activity diagrams are typically drawn to show all control flow paths for a certain feature.
TBD: Open with simple business process modeling (control cycle) and s/w modeling (reading a file) examples.
Flow Charts
(with support for modeling parallel behavior)
Activity Diagrams in UML 2.0
Data Flow Diagrams
(where data are objects) = +
Copyright 2010, Eddie Burris

99. Example Activity starts at an initial node and ends at final node
Decision node has one input edge and multiple output edges. Outputs should be labeled with guard conditions such that one and only one output can be taken
A fork node splits control flow into concurrent control flows
A join node combines concurrent control flow. Flow leaves a join node only after control flow arrives at all incoming edges
Merge is like a join but it doesn’t block waiting for flow on all inputs. Any input to a merge node is immediately routed to its one output
The diagram as a whole is considered an activity. The individual nodes are considered actions.
There can be more than one initial node and more than one final node. If there is more than one initial node activity starts simultaneously at all initial nodes. The activity ends when control flow reaches a final node at which point any other control flows in the diagram are halted.
Copyright 2010, Eddie Burris

100. Activity Diagrams and Use Cases
Use cases with complex control flow logic can be modeled with an activity diagram.
A visual model can reveal errors and omissions that are otherwise hard to identify
Consider the following use case:
Use Case Title:
Process Request for Dynamic Web Page
Actor:
Customer
Description:
1. This use case begins when a customer requests a dynamic web page. 2. If the web page doesn't require authorization, display the web page and end the use case.
3. If the web page does require authorization, and a session with the customer has been establish, go to step 4. Otherwise, prompt the customer for an ID and password. If the ID and password match, go to step 4, otherwise issue a message that an incorrect ID and/or password have been entered and prompt again for an ID and password.
4. If the user has authority to access the requested web page, display the page and end the use case. Otherwise, inform the user they lack the authority to access the page and end the use case.
Copyright 2010, Eddie Burris

101. Visual Model for a Use Case
Ambiguities that might go unnoticed in the written form of a use case are quickly exposed when translating the use case into a more formal representation. Creating the diagram not only helps insure that the use case is correct and complete, but also makes it easier for end users to read, understand and validate the use case.
Copyright 2010, Eddie Burris

102. Partitions
Simple activity diagrams clearly show actions but not who or what is responsible for the action
Activity partitions or swim lanes are used to show who or what is responsible for activities in an activity diagram
Copyright 2010, Eddie Burris

103. Partitions Example Copyright 2010, Eddie Burris
There is a distinction between authorization and authentication. The activity diagram above clearly shows the responsibilities of each.
Sometimes called swim lanes. Can run vertical or horizontal. In UML 2.0, multidimensional partitions are allowed.
TBD: consider changing the example to show business process for who is responsible for QA, Programming and Testing. QA sets standards, Programmers unit test, and a separate test team does integration and system test. The QA person monitors the results.
Copyright 2010, Eddie Burris

104. Object Flow Edges
Copyright 2010, Eddie Burris

105. Object Flow Edges Copyright 2010, Eddie Burris
Activity diagrams mix control flow and data flow. The same edge syntax is used for both types of flow. Having an edge from node A to node B implies that activity B will begin once activity A finishes. It also implies that data may be passed along the edge from activity A to activity B.
You can explicitly express data/object flow using pins or object nodes. Object nodes are usually named with the data type of the class they represent. Notice that object nodes have square corners.
It’s convenient to imagine control flow as a token passed from one node to another. The token may be an actual data object or instance of some classifier.
[tbd: modify diagram/example to make clear that standard edges in Activity diagram are used to indicate control flow, object flow or both at the same time. If you want to explicitly model object flow between two activities you can add an object node or you can add pins on each side of the edge. A standard edge in an activity diagram (a line with an open arrow) implies control flow and/or object flow.]
Copyright 2010, Eddie Burris
105

106. Semantics of Multiple Input Flows
In UML 2.0 control flow must arrive at all inputs before the action starts (join semantics)
In UML 1.x control flow at any input would allow the action to start (merge semantics)
Because of the potential confusion, it’s best to avoid multiple input flows at an action and show the desired interpretation explicitly
Copyright 2010, Eddie Burris

107. Connectors
When a diagram gets tool large for one page or edges cross in confusing ways, consider using connectors to connect portions of a diagram.
You can use any name you like inside a connector, but for every connector with an outgoing edge there needs to be a corresponding connector with an incoming edge.
Copyright 2010, Eddie Burris

108. Transformations and Final Nodes
Transformations are indicated by a note attached to an object flow. The note is labeled with the key word <<Transformation>>
Activity final nodes terminate the whole activity. Flow final nodes are a sink for control flow. Often used when control flow forks
TBD: Consider adding signals (sending, receiving, timing), <<datastore>>, and expansion regions.
Copyright 2010, Eddie Burris

109. Exception Handling
Exceptions are errors, unexpected or abnormal conditions
Exceptions are “thrown” at the source of the error and “caught” at the point at which the error is handled.
Exceptions are propagated up the call stack until they are handled or until control reaches the top of the call stack
After the exception is handled control returns to the node after the region or node where the exception was thrown
Copyright 2010, Eddie Burris

110. State Machine Diagrams
Popular in and outside of software engineering
Model the behavior of an object (software or otherwise) from the perspective of state and the transition between states
Ideally suited for software objects
Also used to understand problem domain and software requirements
Audio response systems are typically modeled or explained as a state machine diagram. Many phone systems or phone services come with a diagram showing how to navigate the menus of the system. These diagrams show what each button on the key pad will do depending on the current state of the session.
State machine diagrams are good for systems that can be (are best) modeled as a finite-state automata. These systems can be described using three classes of elements: the state of the object, events that cause it to move from one state to another, and actions that should occur in response to events or new states.
The state of a program is defined by the contents or value of its data elements.
There is a distinction between state transition diagrams and statecharts [Budgen page 143]. A statechart supports the concept of a hierarchy of diagrams and states.
State machine diagrams are derived from the statecharts of David Harel [1987; 1988].
Copyright 2010, Eddie Burris

111. Syntax The general form of a state machine diagram is:
Example, the general life cycle of a software object expressed with a state machine diagram:
Copyright 2010, Eddie Burris

112. General Form of a State Symbol
Do activities are interruptible. The activities associated with entry, exit and internal transitions are instantaneous.
Internal transitions do not trigger entry or exit activities.
Copyright 2010, Eddie Burris

113. Example Copyright 2010, Eddie Burris Concurrent states.
A composite state is a state that contains one or more regions. The example above is of a composite state with two regions. (I should add a name to the composite state such as “device on”.) Regions are containers for substates. (I should give a name to each region above also.) A composite state is active if any of the composite’s substates are active. A transition to a composite state causes a transition to the initial pseudostate in each region. Each region executes in parallel.
Copyright 2010, Eddie Burris

114. Component Diagram
The following Dictionary component offers spell checking and thesaurus services and relies on a transaction accounting service (to record payments, for example).
Main elements of a component diagram: components, their interfaces, and their realizations.
Components are distinguished by one or both of: the stereo type <<component>> and/or component stereo type icon shown in the upper right-hand corner of the classifier rectangle.
Note, a UML component is a specialized version of the class element.
The “lollipop” symbol is used to show a provided interface. This symbol represents a realization relationship with an interface classifier.
[Define component]
“A component is a logical, replaceable part of a system that conforms to and provides the realization of a set of
interfaces.”
“A component is a replaceable part of a system that conforms to and provides the realization of a set of
"A component is a replaceable, executable piece of a larger system whose implementation details are hidden."
implemented and required interfaces
"assembly of systems from binary replaceable artifacts"
[Value of components]
“easily replace older components with newer, compatible ones.”
“you can replace one component at a time without trashing the entire system and starting over.”
“Build [s/w systems] from well defined components that can be wired together flexibly and replaced individually
as requirements change.”
[When to use component models?]
Use component diagrams when you are designing your system in terms of independently replaceable components.
[syntax and symantics?]
ball-and-socket notation
[other]
“An interface is a collection of operations that are used to specify a service of a class or a component.”
" interfaces as the glue that binds components together."
"An interface that a component realizes is called a p r o v i d e d i n t e r f a c e, meaning an interface that
thecomponent provides as a service to other components. A component may declare many provided interfaces. The
interface that a component uses is called a r e q u i r e d i n t e r f a c e, meaning an interface that the
component conforms to when requesting services from other components. A componentmay conform to many required
interfaces. Also, a component may both provide and require interfaces."
"As Figure 15-1 indicates, a component is shown as a rectangle with a small two-pronged icon in itsupper right
corner. The name of the component appears in the rectangle. A component can haveattributes and operations, but
these are often elided in diagrams."
" a component can be used in a context if and only if all its required interfacesare realized as provided
interfaces of other components."
" A component conforms to and provides the realization of a set of interfaces and enables substitutability"
"A component is r e p l a c e a b l e. A component is substitutable—it is possible to replace a component with
another that conforms to the same interfaces."
enhance replaceability and flexibility
difference between packages and composite structures: "packages are compile-time grouping, while composite
structures show runtime groupings."
"composite structures are a natural fit for showing components and how they are broken into parts"
Figure 2 shows an example xxx diagram, In this diagram, xxx
Another important attribute of components is that they are substitutable
"As a general rule of thumb for engineers substituting components, component B can immediately replace component
A if component B provides at least what component A provided, and uses no more than what component A used."
"developers should construct software by gluing together prefabricated components"
that conforms to and provides the realization of a set of interfaces.
“describes how a software system is split up into components and shows the dependencies among these components.”
“Structure and connections of components”
Organization and dependencies
Components can represent logical services. There isn’t necessarily a one-to-one correspondence between UML 2.0
components and physical implementation.
Copyright 2010, Eddie Burris

115. Component Diagram
Alternate notations
Copyright 2010, Eddie Burris

116. References http://www.netanya.ac.il/Eitan/DownloadFiles/uml_sp/UML.pdf
Object-Oriented Analysis and Design with Applications, 3rd edition. [Booch 2007]
TBD:
1. Add a slide for P.K. 4+1 view model and the UML diagram types helpful in expressing each view. See page 7 in UML 2.0 in a nutshell.
Copyright 2010, Eddie Burris