Deployment Diagram

A UML deployment diagram depicts a static view of the runtime configuration of hardware nodes and the software components that run on those nodes. UML deployment diagrams show the hardware for our system, the software that is being installed on that hardware, and the middleware used to connect the disparate machines to one another. We create a UML deployment model to

·         explore the issues involved in installing your system into production,

·         explore the dependencies that your system has with other systems that are currently in, or planned for, your production environment,

·         depict a major deployment configuration of a business application,

·         design the hardware and software configuration of an embedded system, or

·         depict the hardware/network infrastructure of an organization.

The are 2 main element in the deployment diagram, these are :

·         Node

·         Communication path

A node is something that can host some software. Nodes come in two forms. A device is hardware, it may be a Computer or a simpler piece of hardware connected to a system. An execution environment is software that itself hosts or contains other software, examples are an operating System or a Container process.

The nodes contain artifacts, which are the physical manifestations of software: usually, files. These files might be executables (such as .exe files, binary files, DLLs, JAR files, assemblies, or scripts), or data files, configuration files, HTML documents, and so on. Listing an artifact within a node shows that the artifact is deployed to that node in the running system.

You can show artifacts either as class boxes or by listing the name within a node. If you show them as class boxes, you can add a document icon or the «artifact» keyword. You can tag nodes or artifacts with tagged values to indicate various interesting information about the node, such as vendor, operating system, location, or anything else.

We may have multiple physical nodes carrying out the same logical task. We can either show this with multiple node boxes or state the number as a tagged value. We used the tag number deployed to indicate four physical Web Servers, but there is no standard tag for this.

Communication paths between nodes indicate how things communicate. We can label these paths with information about the communication protocols that are used.

There are two types of connectors used between nodes and artifacts in a deployment diagram. The association represents a communication path between nodes. The association shows the nodes that communicate, and a label on the association can be used to show the communications protocol between nodes. Additionally, an artifact can be drawn outside a node (some tools does not support nesting artifacts in nodes) and attached to a node with a dependency and a «deploy» stereotype. The deploy dependency between an artifact and a node means the same thing as a nested artifact or a listed text artifact—that that kind of artifact is deployed on that kind of node

Common Stereotypes for Communication paths

 

Stereotype	Implication
asynchronous	An asynchronous connection, perhaps via a message bus or message queue.
HTTP	Hypertext Transport Protocol, an Internet protocol.
JDBC	Java Database Connectivity, a Java API for database access.
ODBC	Open Database Connectivity, a Microsoft API for database access.
RMI	Remote Method Invocation, a Java communication protocol.
RPC	Communication via remote procedure calls.
Synchronous	A synchronous connects where the sender waits for a response from the receiver.
web services	Communication is via Web services protocols such as SOAP and UDDI.

 

Package Diagram

Classes represent the basic form of structuring an object-oriented System. Although they are wonderfully useful, we need something more to structure large Systems, which may have hundreds of classes.

A package is a grouping construct that allows you to take any construct in the UML and group its elements together into higher-level units. Its most common use is to group classes.

In a UML model, each class is a member of a single package. Packages can also be members of other packages, so we are left with a hierarchic structure in which top-level packages get broken down into sub packages with their own sub packages and so an until the hierarchy bottoms out in classes. A package can contain both sub packages and classes.

Each package represents a namespace, which means that every class must have a unique name within its own package.

Suppose, if we want to create a class called Date, and a Date class is already in the System package, we can have Date class as long as we put it in a separate package. To make it clear which is which, we can use a fully qualified name, that is, a name that Shows the owning package structure. We use double colons to Show package names in UML, so the dates might be System::Date and myPackage::Util::Date.

In diagrams, packages are shown with a tabbed folder. We can simply Show the package name or show the contents too. At any point, we can use fully qualified names or simply regular names. Showing the contents with class icons allows us to Show all the details of a class, even to the point of showing a class diagram within the package. Simply listing the names makes sense when all we want to do is indicate which classes are in which packages. UML allows classes in the package can be public or private.

 

The contents of a package can be drawn inside the package or outside the package attached by a line. If we draw the elements inside the package, write the name of the package in the folder tab.

Element Visibility

Elements in a package may have public or private visibility . Elements with public visibility are accessible outside the package. Elements with private visibility are available only to other elements inside the package. We can model public or private visibility in UML by writing a plus or minus symbol in front of the element's name

Package Dependency

Sometimes a class in one package needs to use a class in another package. This causes a dependency between packages : if an element in package A uses an element in package B, then package A depends on package B

Understanding the dependencies among packages is useful for analyzing the stability of software. In fact, the most common use of UML package diagrams is to give an overview of the core packages in our software and the dependencies among them. Packages can assist with organizing classes as deployment modules and in creating the build scripts.

Importing a package

When a package imports another package, elements in the importing package can use elements in the imported package without having to use their fully scoped names. This feature is similar to a Java import, in which a class can import a package and use its contents without having to provide their package names.

In an import relationship, the imported package is referred to as the target package. To show the import relation, draw a dependency arrow from the importing package to the target package with the stereotype import.

The package users imports security, so classes in users may use public classes in security without having to specify the package name

A package can also import a specific element in another package instead of the whole package. When importing a package, only public elements of the target package are available in the importing namespace.

 

The users package imports only the MyClassA element from the myPackage package

 

When to Use Package Diagrams

Package diagrams are extremely useful on larger-scale systems to get a picture of the dependencies between major elements of a system. These diagrams correspond well to common programming structures. Plotting diagrams of packages and dependencies helps to keep an application's dependencies under control.

 

 

 

Component Diagram

UML component diagrams show the dependencies among software components, including the classifiers that specify them, such as implementation classes; and the artifacts that implement them; such as source-code files, binary-code files, executable files, scripts, and tables. Create them to

·         model the low-level design configuration of your system,

·         model the technical infrastructure

·         model the business/domain architecture for your organization

Good candidates for components are items that perform a key functionality and will be used frequently throughout our system. Software, such as loggers, XML parsers, or online shopping carts, are components we may already be using. These happen to be examples of common third-party components, but the same principles apply to components we create our self.

In system, we might create a component that provides services or access to data. For example, in a CMS we could have a conversion management component that converts blogs to different formats, such as RSS feeds.

Since components are major players in software design, it is important that they are loosely coupled so that changes to a component do not affect the rest of the system. To promote loose coupling and encapsulation, components are access through interfaces.

Elements of Component diagram

A component is drawn as a rectangle with the <<component>> stereotype and an optional tabbed rectangle icon in the upper righthand corner.

 

We can show that a component is actually a subsystem of a very large system by replacing <<component>> with <<subsystem>>. A subsystem is a secondary or subordinate system that's part of a larger system.

Provided and Required Interfaces in Component

Components need to be loosely coupled so that they can be changed without forcing changes on other parts of the system this is where interfaces come in. Components interact with each other through provided and required interfaces to control dependencies between components and to make components swappable.

A provided interface of a component is an interface that the component realizes. Other components and classes interact with a component through its provided interfaces . A component's provided interface describes the services provided by the component.

A required interface of a component is an interface that the component needs to function. More precisely, the component needs another class or component that realizes that interface to function. But to stick with the goal of loose coupling, it accesses the class or component through the required interface. A required interface declares the services a component will need.

There are three standard ways to show provided and required interfaces in UML: ball and socket symbols, stereotype notation, and text listings.

We can show a provided interface of a component using the ball symbol. A required interface is shown using the counterpart of the ball, the socket symbol drawn as a semicircle extending from a line. Write the name of the interface near the symbols.

Stereotype notation can be used to show required and provider interfaces. This notation is helpful if you want to show the operations of interfaces. If not, it is best to use the ball and socket notation, since it shows the same information more compactly.

When to use Component Diagram

Use component diagrams when you are dividing your System into components and want to show their interrelationships through Interfaces or the breakdown of components into a lower-level structure.

 

Collaboration Diagram

A collaboration diagram— a.k.a as communication diagram in UML version 2.0— conveys the same information as a sequence diagram. Where time ordering is implicit in the linear layout of a sequence diagram, we explicitly indicate the time ordering by numbering the messages in geometrically organized collaboration diagrams.

Key symbols in collaboration diagrams are the rectangle, called a classifier role, and a line indicating the message, again called a connector. The classifier role represents the objects. Connectors represent connected objects, and a named arrow indicates the message as well as the sender and receiver.

As you can see, the collaboration has the same elements but fewer details. The compact nature and fewer elements make collaborations convenient when doodling designs.

To read the diagram, start with message 1 and follow the messages by number. Collaborations are not meant to use interaction frames and, as a result, don't convey as much information as the sequence diagram.

TIP: Consider using collaboration diagrams when working on a whiteboard or napkins or wherever you doodle your inspired designs. The compact nature and fewer adornments of collaboration diagrams make them more manageable when designing manually.

Comparing Sequence and Collaboration diagrams

Feature	Sequence Diagram	Collaboration Diagram	Remarks
Shows participants effectively	Participants are mostly arranged along the top of page. It is easy to gather the participant involved in a particular interaction	Participants as well as links are the focus, so they are shown clearly as rectangle	Collaboration diagram win. Although both type of diagram can show participants as effectively as each other, it can be argued that collaboration diagrams have edge since participants are one of their focuses.
Showing the links between  participants	Links are implied. If a message is passed from one participant to another, then it is implied that a link must  exist between those participants.	Explicitly shows the links between participants. In fact, this is the primary purpose of these types of diagram.	Collaboration diagrams win because they explicitly and clearly show the links between participants.
Showing message signature	Message signatures can be fully described.	Message signatures can be fully described.	Both are good
Support parallel messages	With the introduction of sequence fragments, sequence diagrams are much better.	Shown using the number-letter notation on the message sequences.	Both are good
Support asynchronous  message	Achieved using the asynchronous arrow.	Collaboration diagrams have no concept of the asynchronous messages, since its focus is not on the message ordering	Sequence diagrams are the clear winner because they explicitly support asynchronous messages
Easy to read message ordering	Sequence diagram clearly show message ordering	Shown using the number notation	Sequence diagrams are a clear winner here since they really show off message ordering clearly and effectively.
Easy to create and maintain the diagram	Creating a sequence diagram is simple. However maintaining sequence diagram can be a difficult unless a UML tool is being used	Collaboration diagrams are simple to create, however maintenance is difficult if we need to change the message numbering.	This is difficult to judge and large based on the personal choice.

Sequence Diagram

There are two comman interaction diagram

·         Sequence Diagram

·         Communication Diagram (a.k.a Collabaration diagram)

These two diagram tell excatly the same meaning in the anaylsis and design of system and any of these two diagram are need not both

Sequence diagram have have an explict time ordering and are linear where as in communication diagram have labelled time ordering and are geometric.

Interaction diagrams provide you with enough information to begin coding. The objects are instances of classes, so you need to define a class for each object. Messages generally equate to methods, and the method is placed in the class of the receiver (not the caller).

Sequence Diagram: Sequence are more comman, easy to create and are naturally organized and we don’t need to indicate the time ordering by annotating the meassages.

Elements of the Sequence Diagrams

Object lifeline: A lifeline is a rectangle with a verical line descending from the rectangle. The lifeline represens an instance of a class and the verticall descending line is a convenient place to attache incoming and outgoing messages. Adding multiple lifeline to a single diagram and attaching these to the time ordered message permits you to show all the classes and messages mecessary to complete a scenario described by use case. By eliminating ambiguous gaps or avoiding the repetition of classed and messages, you can get a whole solution, one scenario at a time.

Object lifelins can represent actors or objects. Both actors and object may or may not be actualized as code.

 

 

Activating lifeline : Objects have a lifetime. In the java implementation langauge, we create a object and we cann’t destroy the object. Destroying the objects is job of the garbage collector. But from the modeller (design) perspective we only care whe we begin using an object and when we are done using an object unless the object represents a finite resource. In both cases, the activation line represent the span of an object’s lifetime or scope for the practical purposes. It is also important to know than an object can be represented as being created and destroyed using a single lifeline.

The activation symbol is a vertical rectangle replacing the lifeline for the duration of that instance’s existence, keeping in mind that an object can be created and destroyed multiple times and that one lifeline is used to represent all instances of that class in a sequence

 

Sending Messages: Messages are directed lines connecting lifelines. The lines begins at one lifeline and the arrow points toward a lineline containing the message invoked. The message can begin and end on the same lifeline, this is a nested call. A filled-in triangle arrow head represents a synchronousmessage. A stick triangle arrow head represent an asynchronous message. A dashed line represents the return messages.

The other type of messages used in sequence diagram are:

Found Messages : A found message is a message with a known receiver but the sender is not known

Lost messages : A lost message is message with a know sender but there is not specified receiver.

Interaction Frame:

Interaction frames (or combined fragments) are new in UML version 2.0. Interaction frames are rectangular regions used to organize interaction diagrams (sequence and timing diagrams). Interaction frames can surround an entire interaction diagram or just part of a diagram. Each interaction frame is tagged with a specific word (or an abbreviated form of that word), and each kind of interaction frame conveys some specific information.

Alt	Alternatives fragments (i.e. conditional logic) only guard conditions evaluating to true will be execute
Loop	The guard indicates how many times this part will execute.
Neg	An invalid interaction
Opt	Equivalent to an alt with one condition (i.e. an if condition with no else statement
Par	Fragments run in parallel (multithreading)
Ref	Reference to an interaction defined on another diagram
Region	Critical region
Sd	Used to surround an entire sequence diagram, if desired.

 

  

Interaction frame diagram showing the loop frame

Complete sequence diagram example

 

Activity Diagram

Activity diagram help to discribe visually the sequence of action that leads through the completion of a task. Activity diagrams are good analysis diagrams for developers, users, testers and managers because they use simple symbols, plain text and a style that is similar to the familiar flowchart. Activity diagrams are good at helping you to capture, visualize and describe an ordered set os actions from a beginning to an end.

Activity diagrams are a technique to describe procedural logic, business process, and work flow. In many ways, they play a role similar to flowcharts, but the principal difference between them and flowchart notation is that they support parallel behavior.

 

Symbols used in Activity Diagrams

Intial Node : Every activity diagram have on initial node symbol. This is a solid circle. We can provide a name and some documentation for the initial node (but generally not provided).

The initial node can have one transition line exiting the node. The transaction line is called a Control Flow and is represented by a directed arrow with the arrow pointing away from the initial node

Control Flow/Edge : A control flow is a directed arrow. A control flow is also referred as just flow or an edge. The control begins at the symbol losing focus and points to and is connected to the thing gaining focus.

Guard Conditions : A guard condition is shown as text between in the round bracket on the control flow. Guard condition can be think of as a gatekeeper to the next node

 Connector Node: The connector node is a good way to simplify overlapping flows or flows that span multiple pages.

 

 

To use a connector node, draw a flow exiting a node and transitioning to a connector. Where the connection is made to the next node, draw a connector with a flow exiting the connector and transitioning to the next node in the diagram.

Connector nodes come in pairs. Make sure that connector pairs have the same name; naming connectors will help you to match connection points when you have multiple connector pairs in a single diagram.

 Pins: Pins in the UML are analogous to parameters in implementation. The name or value of a pin leaving one action should be thought of as an input parameter to the next action. 

Actions: Action nodes are the things that you do or that happen in an activity diagram, and an edge represents the path you follow to leapfrog from action to action

Actions are permitted to have one or more incoming flows and only one outgoing flow. If there is more than one incoming flow, then the action will not transition until all incoming flows have reached that action. Actions can split into alternate paths using the decision node or transition into parallel flows using the fork node but only a single flow actually should be attached as an outgoing flow for an action.

Actions also can use preconditions and post conditions to indicate the necessary conditions before and after an action occurs. Preconditions and post conditions can be added to a model using a note—the stereotype symbols with the word precondition or the word post condition in between and the name of the condition. The note is attached to the action to which the condition or conditions applies.

Note: Insteaded of using the pre and post condition, we can use guard condition or we can make use of decision node to convey the same message.
Decision and Merge Nodes: Decision and merge nodes were called decision diamonds in flowcharts. This diamond shaped symbol is one of the elements that make an activity diagram reminiscent of a flowchart. Decision and merge nodes use the same symbol and convey conditional branching and merging.

When the diamond-shaped symbol is used as a decision node it has one edge entering the node and multiple edges exiting the node. When used as a merge node, there are multiple entering edges and a single exiting edge. A decision node takes only one exit path, and a merge node doesn't exit until all flows have arrived at the merge node. A merge node marks the end of conditional behavior started by a decision node.

Transition Forks and Joins:

A fork exists to depict parallel behavior, and a join is used to converge parallel behavior back into a single flow. Forked behavior does not specify whether the behavior is interleaved or occurs simultaneously; the implication is simply that the forked actions are occurring during a shared, concurrent interval.

When multiple flows enter an action, this is implicitly a join, and the meaning is that the outgoing flow occurs only when all incoming flows have reached the action. 

Partitioning Responsibilty with Swimlanes:

Sometimes we want to show who or what is responsible for part of an activity. We can do this with swimlanes. Modeling tools typically show swimlanes as a box with a name at the top, and place whatever nodes and edges belong to that thing in that swimlanes. We can have as many swimlanes as it makes sense to have, but boxy swimlanes can make it hard to organize our activity diagram. UML version 2.0 supports vertical, horizontal, and grid like partitions, so the swimlanes metaphor is no longer precise. The actual terminology is now activity partition, but the word swimlanes is still employed in general conversation and used in modeling tools.

Signals: A signal indicates that an outside event has fired, and that event initiates the activity. There are three types of signal, these are –

·         Time signal

·         Send signal

·         Receive signal

  

The hourglass shape of the time signal is used to specify an interval of time. The receive signal symbol is a rectangle with a wedge cut into it, and the send signal symbol is a rectangle with a protruding wedge.

Terminating Activity: There are two terminating symbols to end the flow or activity, there are –

·         Activity final node : When we reach the end of an activity, add an activity finanl node

·         Flow final node : When we reach the end of a flow and nothing else happen, add flow final node. This indicates the end  of one particular flow, without terminating the whole activity

We can have more than one activity final node and flow final node in a single activity diagram