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

Various relations in software design - Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency

We will just discuss about some of the terms used in software engineering, regarding relationship among the objects, and how they are represented in class diagram.

Association

Association is a relationship between two objects. In other words, association defines the multiplicity between objects. You may be aware of one-to-one, one-to-many, many-to-one, many-to-many all these words define an association between objects. Aggregation is a special form of association. Composition is a special form of aggregation.

Example: A Student and a Faculty are having an association. The relationship between a car and a driver is representative of this relationship. The car will have a driver who will be associated with the car for a period of time.

Aggregation

Aggregation is a special case of association. A directional association between objects. When an object ‘has-a’ another object, then you have got an aggregation between them. Direction between them specified which object contains the other object. Aggregation is also called a “Has-a” relationship.

 

A FileReader object that has been created using a File object represents a mutual dependency where the two objects combine to create a useful mechanism for reading characters from a file. The UML symbols for expressing this relationship as shown in following figure which involve a line connecting the two classes with a diamond at the object that represents the greater whole.

Composition

Composition is a special case of aggregation. In a more specific manner, a restricted aggregation is called composition. When an object contains the other object, if the contained object cannot exist without the existence of container object, then it is called composition.

Example: A class contains students. A student cannot exist without a class. There exists composition between class and students. Other example of this is a customer object and its related address object; the address object cannot exist without a customer object. This relationship is shown with a darkened diamond at the object, which represents the greater whole, as shown in the following figure:

Difference between aggregation and composition

Composition is more restrictive. When there is a composition between two objects, the composed object cannot exist without the other object. This restriction is not there in aggregation. Though one object can contain the other object, there is no condition that the composed object must exist. The existence of the composed object is entirely optional. In both aggregation and composition, direction is must. The direction specifies, which object contains the other object.
Example: A Library contains students and books. Relationship between library and student is aggregation. Relationship between library and book is composition. A student can exist without a library and therefore it is aggregation. A book cannot exist without a library and therefore its a composition. For easy understanding I am picking this example. Don’t go deeper into example and justify relationships!

Abstraction

Abstraction is specifying the framework and hiding the implementation level information. Concreteness will be built on top of the abstraction. It gives you a blueprint to follow to while implementing the details. Abstraction reduces the complexity by hiding low level details.
Example: A wire frame model of a car.

Generalization

Generalization uses a “is-a” relationship from a specialization to the generalization class. Common structure and behaviour are used from the specializtion to the generalized class. At a very broader level you can understand this as inheritance. Why I take the term inheritance is, you can relate this term very well. Generalization is also called a “Is-a” relationship.

Example: Consider there exists a class named Person. A student is a person. A faculty is a person. Therefore here the relationship between student and person, similarly faculty and person is generalization.

Realization

Realization is a relationship between the blueprint class and the object containing its respective implementation level details. This object is said to realize the blueprint class. In other words, you can understand this as the relationship between the interface and the implementing class.

Example: A particular model of a car ‘GTB Fiorano’ that implements the blueprint of a car realizes the abstraction.

Dependency

Change in structure or behaviour of a class affects the other related class, then there is a dependency between those two classes. It need not be the same vice-versa. When one class contains the other class it this happens.

Example: Relationship between shape and circle is dependency. The same relationship would exist for a stock transfer object that needed to use a stock item object to get the information on the stock item being transferred. The stock transfer object would have a dependency relationship with the stock item object; the stock transfer object would read the transfer information and could then discard the stock item object and continue processing.