CHAPTER 5 CO:-Sketch component diagram using basic notations 5.1 Component Diagram (4M) Sample Component Diagram 5.2 Deployment Diagram (8M) Sample Deployment diagram Component diagrams are different in terms of nature and behavior. Component diagrams are used to model physical aspects of a system. Physical aspects are the elements like executables, libraries, files, documents etc. which resides in a node. So component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems. It describes the components used to make system functionalities. Component diagrams can also be described as a static implementation view of a system. Static implementation represents the organization of the components at a particular moment. A single component diagram cannot represent the entire system but a collection of diagrams are used to represent the whole. Component diagrams are used during the implementation phase of an application. But it is prepared well in advance to visualize the implementation details. Initially the system is designed using different UML diagrams and then when the artifacts are ready component diagrams are used to get an idea of the implementation. This diagram is very important because without it the application cannot be implemented efficiently. So before drawing a component diagram the following artifacts are to be identified clearly: Files used in the system. Libraries and other artifacts relevant to the application. Relationships among the artifacts. Now the usage of component diagrams can be described as: Model the components of a system. Model database schema. Model executables of an application. Model system's source code. Model relationships among artifacts Notations for component Diagram component and interfaces, ports, connectors Notations for Deployment diagram nodes, artifacts, node instances, communication between nodes
The following is a component diagram for order management system. Here the artifacts are files. So the diagram shows the files in the application and their relationships. In actual the component diagram also contains dlls, libraries, folders etc. In the following diagram four files are identified and their relationships are produced. Component diagram cannot be matched directly with other UML diagrams discussed so far. Component diagram for order management Component instances In UML modeling, component instances are model elements that represent actual entities in a system. Packages Packages group related model elements of all types, including other packages. Artifacts In UML models, artifacts are model elements that represent the physical entities in a software system. Artifacts represent physical implementation units, such as Executable files, Libraries, Software components, Documents, Text document Source file Script Binary executable file Archive file Database table.
Relationships in component diagrams In UML, a relationship is a connection between model elements. A UML relationship is a type of model element that adds semantics to a model by defining the structure and behavior between model elements. Component A component is a logical unit block of the system, a slightly higher abstraction than classes. It is represented as a rectangle with a smaller rectangle in the upper right corner with tabs or the word <component> written above the name of the component to help distinguish it from a class. A component is shown as a classifier rectangle with the keyword «component». Components in UML could represent logical components (e.g., business components, process components) Physical components (e.g., CORBA components, EJB components, COM+ and.net components, WSDL components, etc.), In UML modeling, components are model elements that represent independent, interchangeable parts of a system. They conform to and realize one or more provided and required interfaces, which determine the behavior of components. Is component replaceable? A component is replaceable. It is a substitutable. It is possible to replace a component with another component that confirms to same interface. A mechanism of inserting or replacing a component to form runtime system is transparent to component user. Interface An interface (small circle or semi-circle on a stick) describes a group of operations used (required) or created (provided) by components. A full circle represents an interface created or provided by the component. A semi-circle represents a required interface, like a person's input.
In UML modeling, interfaces are model elements that define sets of operations that other model elements, such as classes, or components must implement. An implementing model element realizes an interface by overriding each of the operations that the interface declares. Importance:- An interface therefore describes the externally visible behavior of that element. An interface represent the complete behavior of a class or component or only a part of that Behavior. An interface defines a set of operation specifications. Provided Interface A provided interface is the one that is either realized directly by the component itself, or realized by one of the classifiers realizing component, or is provided by a public port of the component. Required Interface A required interface is either designated by usage dependency from the component itself, or designated by usage dependency from one of the classifiers realizing component, or is required by a public port of the component. Dependencies A dependency exists between two elements if changes to the definition of one element may cause changes to the other.. Draw dependencies among components using dashed arrows.
Port Ports are represented using a square along the edge of the system or a component. A port is often used to help expose required and provided interfaces of a component. Component diagram for ATM
Deployment diagrams These are used to visualize the topology of the physical components of a system where the software components are deployed. So deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their relationships. The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for describing the hardware components where software components are deployed. Component diagrams and deployment diagrams are closely related. Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware. UML is mainly designed to focus on software artifacts of a system. But these two diagrams are special diagrams used to focus on software components and hardware components. Deployment diagram represents the deployment view of a system. It is related to the component diagram. Because the components are deployed using the deployment diagrams. A deployment diagram consists of nodes. Nodes are nothing but physical hardware used to deploy the application. An efficient deployment diagram is very important because it controls the following parameters Performance Scalability Maintainability Portability So before drawing a deployment diagram the following artifacts should be identified: Nodes Relationships among nodes
So the usage of deployment diagrams can be described as follows: To model the hardware topology of a system. To model embedded system. To model hardware details for a client/server system. To model hardware details of a distributed application. Forward and reverse engineering. Notation Description Artifact An artifact is a classifier that represents some physical entity, a piece of information that is used or is produced by a software development process, or by deployment and operation of a system. A particular instance (or "copy") of an artifact is deployed to a node instance. Artifact is presented using an ordinary class rectangle with the keyword «artifact». Examples in UML specification also show document icon in upper right corner.
An artifact is a classifier that represents some physical entity, a piece of information that is used or is produced by a software development process, or by deployment and operation of a system. Artifact is a source of a deployment to a node Some real life examples of UML artifacts are: text document source file script binary executable file archive file database table An artifact is presented using an ordinary class rectangle with the keyword «artifact». Examples in UML specification also show document icon in upper right corner. Dependency between Artifacts The book-club.war artifact depends on web-tools-lib.jar artifact Dependency between artifacts is notated in the same way as general dependency, i.e. as a general dashed line with an open arrow head directed from client artifact to supplier artifact. Manifestation EJB component UserService and skeleton of web services are manifested by EJB module user-service.jar artifact. Manifestation is an abstraction relationship which represents the concrete physical rendering of one or more model elements by an artifact or utilization of the model elements in the construction or generation of the artifact. Since UML 2.0 artifacts can manifest any package able elements, not just components. Manifestation between artifact and package able element is notated in the same way as an abstraction dependency, i.e. as a general dashed line with an open arrow head directed from artifact to package able element(e.g. component or package) and labeled with the keyword «manifest». In UML 1.x, the concept of manifestation was C# Artifact web-app.war source file artifact UserServices.cs Library commons.dll
referred to as implementation and was annotated as «implement». Node Application Server Node. Node is a deployment target which represents computational resource upon which artifacts may be deployed for execution. Node is shown as a perspective, 3- dimensional view of a cube. Hierarchical Node Application server box runs several web servers and J2EE servers. Nodes may have an internal structure defined in terms of parts and connectors associated with them for advanced modeling applications. Parts of node could be only of type node. Hierarchical nodes (i.e., nodes within nodes) can be modeled using composite associations, or by defining an internal structure for advanced modeling applications. Several execution environments nested into server device Execution environment is usually part of a general node or «device» which represents the physical hardware environment on which this execution environment resides. Execution environments can be nested (e.g., a database execution environment may be nested in an operating system execution environment). Device
A device is a subclass of node which represents a physical computational resource with processing capability upon which artifacts may be deployed for execution. Device is rendered as a node (perspective, 3- dimensional view of a cube) annotated with Application Server device. keyword «device». Application Server device depicted using custom icon. UML provides no standard stereotypes for devices. Examples of non-normative stereotypes for devices are: «application server» «client workstation» «mobile device» «embedded device» Computer stereotype with tags applied to Device class. Profiles, stereotypes, and tagged values could be used to provide custom icons and properties for the devices. Database Server device depicted using custom icon. Mobile smartphone device depicted using custom icon.
Execution Environment Execution environment - J2EE Container An execution environment is a (software) node that offers an execution environment for specific types ofcomponents that are deployed on it in the form of executable artifacts. Execution environment is notated as a node (perspective, 3-dimensional view of a cube) annotated with the standard stereotype «executionenvironment». Linux Operating System Execution Environment UML provides no other standard stereotypes for execution environments. Examples of reasonable non-normative stereotypes are: «OS» «workflow engine» «database system» «J2EE container» «web server» «web browser» Oracle 10g DBMS Execution Environment Association The ejb-jar.xml deployment specification attached to deployment. Deployment specification could be associated with the deployment of a component artifact on a node. In this case deployment specification could be shown as a classifier rectangle attached to the deployment. Note, UML 2.4 specification shows this association as a dashed line (while association is normally displayed as solid l Several execution environments nested into server device