copyright 2013, eddie burris software modeling with uml

Copyright 2013, Eddie Burris

Software Modeling with UML


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


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


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.

Perspective

• Complex artifacts may be viewed from multiple perspectives. For example, Google Maps offers map view and satellite view of most cities.


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.


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.



Dimensions of a Model

Perspective

Amount of detail or level of

abstraction

Structural Electrical Heating and Ventilation

Less Detail

More Detail


Software Models

Perspective

Structural BehavioralBusiness Process

Amount of detail or level of

abstraction

Less Detail

More Detail


In general, models are used to:• Manage complexity• Visualize constructs that are otherwise

intangible• Communicate with others

• Better understand the problem domain and product requirements

• Experiment with potential solutions before committing to an implementation

• Document existing systems

Specifically, during software development models are used to:


Software Modeling During the Software Life Cycle

• Several phases in the software life cycle can benefit from modeling:


Domain and Analysis Models

• During the requirements phase, domain and analysis models are used to better understand business processes and product requirements.


Architecture and Design Models

• During the design phase, design models are used to explore and communicate design options/alternatives.


Deployment Models

• During development, physical deployment models are used to plan for deployment.


Implementation Models

• Implementation models are used to document existing systems. This information is useful to those who will be maintaining the software.


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.

Object Management Group (OMG)

• 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).



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.


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).


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

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.



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.


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.


Static vs. Dynamic Modeling

Static Structural Modeling

Dynamic Behavioral Modeling


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

Syntax and Semantics for UML Actor Symbol

Class Diagrams


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.


Making the concept of class tangible


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.


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.

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 (#).


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.



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

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”.


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.



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.

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.


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.)



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


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.


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


Relationships

• Class diagrams show class elements and their relationships

• There are 4 types of relationships between class elements


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.


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.”


Multiplicity

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.

1Exactly one (default

for attributes)

* 0 or more

1..* 1 or more

4, 6, 8,12 exactly 4, 6, 8 or 12

10..30 10 to 30

Discontinuous

multiplicities no

longer valid in

UML 2.x.


Navigability


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.

Ambiguity on both sides

Ambiguity on one side

No ambiguity


Association Details

Example



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?

Guideline: Model value objects as attributes and reference objects as associations.

AssociationText Attribute

OR


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


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


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:


Aggregation

• Aggregation is a special type of association that adds some additional semantics to the association relationship.


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.


Association, Aggregation, Composition


Active Class

• An active class has its own thread of control or execution. Methods of an active class may be asynchronous

Object Diagrams



Object Diagram

• Objects are a runtime concept

• An object diagram shows a snapshot of objects as they exist at one point in time

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.

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:


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:



• An object diagram can help clarify a class diagram.



• 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.



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:

Sequence Diagrams



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

Sequence Diagram for Simple Code Fragment



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


Class Diagram (sans relationships)

Sequence Diagram


Misc

Object creation and destruction

Asynchronous Messages

Self-Call and overlapping execution occurrence

Object lifeline

Q: What, if anything, is wrong with the following sequence diagram?


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 interpretation is to assume the second message is correct but the modeler intended the first message to be an asynchronous one.


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.

• 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.

Component Diagrams


Component Diagrams [Cont.]

• A UML component diagram shows components and connections between components in terms of provided and required interfaces.


Component Diagrams [Cont.]

• The Tomcat application server runs in an environment that includes browsers and a relational database.


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 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.


Deployment Diagram [Cont.]



Deployment Diagram

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.


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:



• 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.


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.


Use Case Diagram [Cont.]


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.


Package Diagram

• Alternate notation for showing the containment relationship between packages


Package Diagram

• Visibility and dependency



Interaction Diagrams

• Interaction Diagrams– Sequence Diagrams– Communication Diagrams (called

Collaboration diagrams in UML 1.x)– Timing Diagrams– Interaction Overview Diagrams (Not described

here)


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


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.


Another Example

• The following example uses a combined fragment to clearly show the conditional logic implied in an earlier example


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


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


Example


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:

Activity Diagrams in

UML 2.0=

Flow Charts(with support for modeling parallel

behavior)

Data Flow Diagrams(where data are

objects)+


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.


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.


Visual Model for a Use Case


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


Partitions Example


Object Flow Edges


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


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.


Transformations and Final Nodes


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


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


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:


General Form of a State Symbol


Example


Component Diagram

• The following Dictionary component offers spell checking and thesaurus services and relies on a transaction accounting service (to record payments, for example).


Component Diagram

• Alternate notations

References

• http://www.netanya.ac.il/Eitan/DownloadFiles/uml_sp/UML.pdf

• Object-Oriented Analysis and Design with Applications, 3rd edition. [Booch 2007]


http://www.netanya.ac.il/Eitan/DownloadFiles/uml_sp/UML.pdf

http://www.netanya.ac.il/Eitan/DownloadFiles/uml_sp/UML.pdf

copyright 2013, eddie burris software modeling with uml

Documents

eddie burriscopyright

eddie burrisdomain

eddie burrisdimensions

eddie burrismodels

eddie burrissoftware

eddie burrisin general

useful model

level of detaila model