AIM: Prepare a representative paper design of a hypothetical system using components, interfaces and its deployment issue with

UML 2.0 OBJECTIVE: To study the details of component and deployment diagram. THEORY: COMPONENT DIAGRAM: 1. A component diagram shows the physical structure of the code in terms of code components. A component can be a source code component, a binary component or an executable component. A component contains information about the logical class or classes it implements, thus creating a mapping from the logical view to the component view. 2. In specific, the component diagram shows the organizations and dependencies among components and artifacts. An artifact represents the physical manifestation of a component( or any packageable element, such as a simple class). An artifact can be: A source artifact: A source artifact is meaningful at compile time. It is commonly a source code file implementing one or more classes. An executable artifact: An executable artifact is a executable program file that is the result of linking all binary components(either static at link time or dynamic at run time). An executable component represents the executable unit that is run by a processor(computer).

Component Diagram's Purpose: The component diagrams main purpose is to show the structural relationships between the components of a system. In UML 1.1, a component represented implementation items, such as files and executables. Unfortunately, this conflicted with the more common use of the term component," which refers to things such as COM components. Over time and across successive releases of UML, the original UML meaning of components was mostly lost. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Although the UML 2 specification does not strictly state it, components are larger design units that represent things that will typically be implemented using replaceable" modules. But, unlike UML 1.x, components are now strictly logical, design-time constructs. The idea is that you can easily reuse and/or substitute a different component implementation in your designs because a component encapsulates behaviour and implements specified interfaces. In component-based development (CBD), component diagrams offer architects a natural format to begin modelling a solution. Component diagrams allow an architect to verify that a systems required functionality is being implemented by components, thus ensuring that the eventual system will be acceptable.

In addition, component diagrams are useful communication tools for various groups. The diagrams can be presented to key project stakeholders and implementation staff. While component diagrams are generally geared towards a systems implementation staff, component diagrams can generally put stakeholders at ease because the diagram presents an early understanding of the overall system that is being built. Developers find the component diagram useful because it provides them with a high-level, architectural view of the system that they will be building, which helps developers begin formalizing a roadmap for the implementation, and make decisions about task assignments and/or needed skill enhancements. System administrators find component diagrams useful because they get an early view of the logical software components that will be running on their systems. Although system administrators will not be able to identify the physical machines or the physical executables from the diagram, a component diagram will nevertheless be welcomed because it provides early information about the components and their relationships (which allows sys-admins to loosely plan ahead). Notations: Representing Components: Components are represented as a rectangular classifier with the keyword component. Optionally the component may be displayed as a rectangle with a component icon in the right-hand upper corner.

Assembly Connector: The assembly connector bridges a components required interface (Component1) with the provided interface of another component (Component2). This allows one component to provide the services that another component requires. A provided interface of a component is an interface that the component realises. A required interface of a component is an interface that the component needs to function.

Components with Ports: Using Ports with component diagrams allows for a service or behaviour to be specified to its environment as well as a service or behaviour that a component requires. Ports may specify inputs

and outputs as they can operate bi-directionally. The following diagram details a component with a port for online services along with two provided interfaces order entry and tracking as well as a required interface payment.

Example: The diagram above demonstrates some components and their inter-relationships. Assembly connectors "link" the provided interfaces supplied by "Product" and "Customer" to the required interfaces specified by "Order". A dependency relationship maps a customer's associated account details to the required interface; "Payment", indicated by "Order".

DEPLOYMENT DIAGRAM: 1. The deployment diagram depicts the runtime architecture of devices, execution environments and artifacts that resides in the architecture. It is the ultimate physical description of the system topology , describing the structure of the hardware units and the software that executes on each unit. 2. 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. 3. Deployment diagrams are useful for system engineers. An efficient deployment diagram is very important because it controls the following parameters

Performance Scalability Maintainability Portability

Deployment Diagram's Purpose: 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. So most of the UML diagrams are used to handle logical components but deployment diagrams are made to focus on hardware topology of a system. Deployment diagrams are used by the system engineers. The purpose of deployment diagrams can be described as:

Visualize hardware topology of a system. Describe the hardware components used to deploy software components. Describe runtime processing nodes.

Notations: Node: A Node is either a hardware or software element. It is shown as a three-dimensional box shape, as shown below.

Node Instance: A node instance can be shown on a diagram. An instance can be distinguished from a node by the fact that its name is underlined and has a colon before its base node type. An instance may or may not have a name before the colon. The following diagram shows a named instance of a computer.

Node Stereotypes: A number of standard stereotypes are provided for nodes, namely cdrom, cd-rom, computer, disk array, pc, pc client, pc server, secure, server, storage, unix server, user pc. These will display an appropriate icon in the top right corner of the node symbol.

Artifact: An artifact is a product of the software development process. That may include process models (e.g. use case models, design models etc), source files, executables, design documents, test reports, prototypes, user manuals, etc. An artifact is denoted by a rectangle showing the artifact name, the artifact keyword and a document icon, as shown below.

Association: In the context of a deployment diagram, an association represents a communication path between nodes. The following diagram shows a deployment diagram for a network, depicting network protocols as stereotypes, and multiplicities at the association ends.

Node as Container: A node can contain other elements, such as components or artifacts. The following diagram shows a deployment diagram for part of an embedded system, depicting an executable artifact as being contained by the motherboard node.

Example: The following deployment diagram is a sample to give an idea of the deployment view of order management system. Here we have shown nodes as:

Monitor Modem Caching server Server

The application is assumed to be a web based application which is deployed in a clustered environment using server 1, server 2 and server 3. The user is connecting to the application using internet. The control is flowing from the caching server to the clustered environment.

So the following deployment diagram has been drawn considering all the points mentioned above:

CONCLUSION: Thus the fundamentals of Component and Deployment diagram have been studied.