UML Concepts(Continuation...)

                                                        -Satya Swati

6) Activity Diagram:

The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The flowchart is used to depict the business logic flow and the events that cause decisions and actions in the code to take place.

Activity diagrams represent the business and operational work flows of a system. An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state.

So, what is the importance of an Activity diagram, as opposed to a State diagram? A State diagram shows the different states an object is in during the life cycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows.

An Activity diagram talks more about these transitions and activities causing the changes in the object states.

Elements of an Activity diagram

An Activity diagram consists of the following behavioral elements:

Significance:

• Addresses a dynamic view of the system.
• Important for modeling system functions.
• Emphasizes the flow of objects and synchronization of the flow in support of parallel processing.
• An extension of the old "flow chart" diagram combined with Petri nets.

 

 

7) Package diagram:

A package diagram in the UMLdepicts the dependencies between the packages that make up a model.In addition to the standard UML Dependency relationship, there are two special types of dependencies defined between packages:

package import

package merge

A package import is "a relationship between an importing namespace and a package, indicating that the importing namespace adds the names of the members of the package to its own namespace." [1] By default, an unlabeled dependency between two packages is interpreted as a package import relationship.

A package merge is "a directed relationship between two packages, that indicates that the contents of the two packages are to be combined. It is very similar to Generalization in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both"

Package diagrams can use packages containing use cases to illustrate the functionality of a software system.

Package diagrams can use packages that represent the different layers of a software system to illustrate the layered architecture of a software system. The dependencies between these packages can be adorned with labels / stereotypes to indicate the communication mechanism between the layers.

Significance:

• Addresses larger system engineering issues, and package dependence.

8) Component Diagram:

The different high-level reusable parts of a system are represented in a Component diagram. A component is one such constituent part of a system. In addition to representing the high-level parts, the Component diagram also captures the inter-relationships between these parts.

So, how are component diagrams different from the previous UML diagrams that we have seen? The primary difference is that Component diagrams represent the implementation perspective of a system. Hence, components in a Component diagram reflect grouping of the different design elements of a system, for example, classes of the system.

Let us briefly understand what criteria to apply to model a component. First and foremost, a component should be substitutable as is. Secondly, a component must provide an interface to enable other components to interact and use the services provided by the component. So, why would not a design element like an interface suffice? An interface provides only the service but not the implementation. Implementation is normally provided by a class that implements the interface. In complex systems, the physical implementation of a defined service is provided by a group of classes rather than a single class. A component is an easy way to represent the grouping together of such implementation classes.

You can model different types of components based on their use and applicability in a system. Components that you can model in a system can be simple executable components or library components that represent system and application libraries used in a system. You also can have file components that represent the source code files of an application or document files that represent, for example, the user interface files such as HTML or JSP files. Finally, you can use components to represent even the database tables of a system as well!

Now that we understand the concepts of a component in a Component diagram, let us see what notations to use to draw a Component diagram.

Elements of a Component Diagram:

A Component diagram consists of the following elements:

Significance:

• Shows organization and dependencies among a set of components.
• Components are composed of one or more classes or interfaces.
• A static view of the system implementation.

The Deployment Diagram:

After all the UML diagrams that we have seen till now, you might groan—one more UML diagram? Well, until now we have discussed UML diagrams that cover the application side in terms of both static and dynamic behavior. The component diagram that we covered in the previous article still focused on the representation of the physical implementation of the application components that perform and provide required functionality. The deployment diagram provides a different perspective of the application. The deployment diagram captures the configuration of the runtime elements of the application.

This diagram is by far more useful when a system is built and ready to be deployed. But, this does not mean that you should start on your deployment diagram after your system is built. On the contrary, your deployment diagram should start from the time your static design is being formalized using, say, class diagrams. This deployment diagram then evolves and is revised until the system is built. It is always a best practice to have visibility of what your deployment environment is going to be before the system is built so that any deployment-related issues are identified to be resolved and not crop up at the last minute. The general rule of thumb is that correction costs due to changes increase as the project nears completion.

So, how are deployment diagrams and component diagrams related? Essentially, the components in a component diagram are contained in the deployment diagram elements. Hence, while components provide the application functionality, the deployment diagram elements provide the necessary environment for the components to execute in.

The basic deployment diagram element is the node. The node represents the environment in which a component or a set of components execute. This means that a node in a deployment diagram can represent a multitude of things—physical hardware such as a server machine, a system software like an operating system, or even application infrastructure software like a Web server, application server, database server, and so forth. The different nodes in the deployment diagram can be interconnected to represent interdependencies, thus providing a deployment diagram that is easy to comprehend and provides the complete deployment environment of a system.

Elements of a Deployment Diagram:

A deployment diagram consists of the following elements:

Significance:

• Shows the configuration of run-time processing nodes in the system.
• Nodes contain one or more components.
• Address a static deployment view of the system.