Course Overview Background UML and Object Orientation Diagrams

Course Overview Background: UML and Object Orientation Diagrams: • Use Case Diagrams • Collaboration Diagrams • Activity Diagrams • State Diagrams • Class Diagrams • Component Diagrams • Sequence Diagrams • Deployment Diagrams

Deployment Diagrams

Use of • use class diagrams and component diagrams to reason about the structure of your software. • You use sequence diagrams, collaboration diagrams, statechart diagrams, and activity diagrams to specify the behavior of your software. • you use deployment diagrams to reason about the topology of processors and devices on which your software executes.

Deployment Diagrams • to model the static deployment view of a system. • Modeling the Physical aspects of an object oriented system. • Map components to the physical environment in which they operate. • May describe the details of actual clients and servers • Model the architecture of system. System=Software+hardware • Deployment diagram address the distribution, delivery, and installation of the parts that make up the physical system • Shows the configuration of runtime processing nodes and components that live on them. i. e: Model relationship between processors and devices.

Deployment Diagrams • Consists of – Nodes – Dependency and association relationships – may also contain packages or subsystems, (used to group elements)

Nodes Node • Represented as a Cube with name. • Node is a physical element that represent execution time and model computational resource. • Represents processor which has some memory and processing power on which components are deployed. • A node name must be unique within its enclosing package, Named physical machines on which components are deployed.

Basic Deployment Diagram Symbols and Notations Components and Nodes Place components inside the node that deploys them.

Deployment Diagrams • Consists of 1)Association Relationships - Represented as a line. - Represents connections between the physical devices or processors. – In this context, an association represents a physical connection among nodes, such as an Ethernet connection, a serial line, or a shared bus,

Associations Reservation. Server Named or described connections between the physical devices or processors. HTTP Client • Has roles, multiplicity, constraints

Processors and Devices • A processor is a node that has processing capability, meaning that it can execute a component. • A device is a node that has no processing capability and, in general, represents something that interfaces to the real world. device

• Used to model

Deployment Diagrams • 1) 2) 3) Used to model Embedded system. Client/Server system. Fully distributed system.

1. Model the Embedded System. • • To model Embedded system (A software intensive collection of hardware that interfaces with the physical world). Involves software that controls devices such as motors, encoders, serial I/O ports etc.

1. Model the Embedded System.

2. Model the Client/Server System. • no longer resides on a single processor, • How do you best distribute your software components across these nodes? • How do they communicate? • How do you deal with failure and noise?

2. Model the Client/Server System. • you might choose to have a thin client, meaning – that it has a limited amount of computational capacity – Limited user interface and visualization of information. – Thin clients may not even host a lot of components but, rather, may be designed to load components from the server, as needed, as with Enterprise Java Beans. • On the other hand, you might choose to have a thick client, meaning – that it has a good amount of computational capacity and does more than just visualization. – A thick client typically carries out some of the system's logic and business rules. • The choice between thin and thick clients is an architectural decision that's influenced by a number of – technical, economic, political factors.

2. Model the Client/Server System. are marked with explicit multiplicities,

The following deployment diagram shows the relationships among software and hardware components involved in real estate transactions. • http: //bdn. borland. com/article/0, 1410, 31863, 00. html

2. Model the Client/Server System. • For example, most management information systems are essentially three-tier architectures, • which means that the system's GUI, business logic, and database are physically distributed. • Deciding where to place the system's GUI and database are usually fairly obvious, so the hard part lies in deciding where the business logic lives.

3. Model the Fully Distributed System. • many forms, from simple two-processor systems to those that span many geographically dispersed nodes. • typically never static. – Nodes are added and removed as network traffic changes and processors fail; – new and faster communication paths may be established in parallel with older, slower channels that are eventually decommissioned. – topology of these systems change, – distribution of their software components may change, • . For example, database tables may be replicated across servers, only to be moved, as traffic dictates. • You can use the UML's deployment diagrams to reason about the topology of such systems.

3. Model the Fully Distributed System.

Modeling Local Network

• Deployment Diagram Example

• http: //www. smartdraw. com/examples/software-uml/deployment_diagram_student_administration. htm

• UML 2 deployment diagram for the university information system. http: //www. agilemodeling. com/artifacts/deployment. Diagram. htm

Deployment Summary

Figure Three-Tier Pattern Applied to the Component Diagram: Each tier is represented in UML by a package: in this case Data Tier, Application Tier, and Presentation Tier. The tiers are used as holders to help organize the components.

• examples

FOR a COLLEGE LAN……. which topology? ?

College lan

FOR a online voting m/c ……. which topology? ?

Online Voting by the CEC

Course Summary

The UML Diagrams

Model Views

Relationships • The following relationships are used extensively throughout the UML