Deployment Diagram.

Slides:



Advertisements
Similar presentations
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Advertisements

® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 04. Other.
COMPONENT DIAGRAM in UML 2.0 Veronica Carrega
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Modeling Notations.
Technical Architectures
C OMPONENT & D EPLOYMENT D IAGRAMS Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
Chapter 13 Physical Architecture Layer Design
Component and Deployment Diagrams
CS 432 Object-Oriented Analysis and Design
1 A Student Guide to Object- Orientated Development Chapter 9 Design.
Client/Server Architecture
Tiered architectures 1 to N tiers. 2 An architectural history of computing 1 tier architecture – monolithic Information Systems – Presentation / frontend,
The Design Discipline.
Advanced Web Forms with Databases Programming Right from the Start with Visual Basic.NET 1/e 13.
Session 26 Modeling the Static View: The Deployment Diagram Written by Thomas A. Pender Published by Wiley Publishing, Inc. October 27, 2011 Presented.
Modelling Class T16: Conceptual Modelling – Architecture Image from
1 Welcome to CSC 301 Web Programming Charles Frank.
Database Architectures Database System Architectures Considerations – Data storage: Where do the data and DBMS reside? – Processing: Where.
Programming Logic and Design Fourth Edition, Comprehensive Chapter 15 System Modeling with the UML.
UML diagrams What is UML UML diagrams –Static modeoing –Dynamic modeling 1.
Technology Layer. Technology Layer Metamodel Technology Layer Concepts.
Component, Deployment and Package Diagrams CSIS3600.
COMPONENT DIAGRAM in UML 2.0 Veronica Carrega. PLAN OF TALK  Introduction about components  Components and component diagrams in uml 2.0  Case study.
Data Communications and Networks Chapter 9 – Distributed Systems ICT-BVF8.1- Data Communications and Network Trainer: Dr. Abbes Sebihi.
Identifying classes, Packages and drawing class Diagrams, Object Diagrams and composite structure diagrams Week 07 1.
CLIENT SERVER COMPUTING. We have 2 types of n/w architectures – client server and peer to peer. In P2P, each system has equal capabilities and responsibilities.
OOS SQUARE SQUARE Lab Deployment Diagram *UML 2 and the Unified Process Second Edition 을 인용하여 작성됨.
Distributed Systems Architectures. Topics covered l Client-server architectures l Distributed object architectures l Inter-organisational computing.
Deployment Diagram.
Method – Notation 8 Hours.
Chapter 12: Architecture
Introduction to UML.
Database Development (8 May 2017).
TIM 58 Chapter 11: Physical Architecture Layer Design
UML Diagrams By Daniel Damaris Novarianto S..
Deployment Diagram.
System Architecture & Hardware Configurations
N-Tier Architecture.
Chapter 2 Database System Concepts and Architecture
COMPONENT & DEPLOYMENT DIAGRAMS
Object-Oriented Analysis and Design
G. Pullaiah College of Engineering and Technology
Component and Deployment Diagrams
MVC and other n-tier Architectures
OO Methodology OO Architecture.
Software Design and Architecture
The Client/Server Database Environment
CSC 480 Software Engineering
System Architecture & Hardware Configurations
CHAPTER 3 Architectures for Distributed Systems
UML Diagrams Jung Woo.
Physical Architecture Layer Design
Session III Architecture of PLC
#01 Client/Server Computing
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Database System Concepts and Architecture.
Programmable Logic Controllers (PLCs) An Overview.
Chapter 2 Database Environment Pearson Education © 2009.
Systems Analysis and Design in a Changing World, 6th Edition
More Model Elements.
Chapter 12: Physical Architecture Layer Design
IMPORTANT NOTICE TO STUDENTS:
Analysis models and design models
An Introduction to Software Architecture
MORE ON ARCHITECTURES The main reasons for using an architecture are maintainability and performance. We want to structure the software into reasonably.
Sylnovie Merchant, Ph.D. MIS 161 Spring 2005
Design Yaodong Bi.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Software Development Process Using UML Recap
#01 Client/Server Computing
Presentation transcript:

Deployment Diagram

Deployment diagrams indicate how the software is to be installed across systems—for example, what will be installed on the server and what will be installed on the admin PCs. A deployment diagram shows how the finished system will be deployed on one or more machines. A deployment diagram can include all sorts of features such as machines, processes, files and dependencies. A deployment diagram is used to show the allocation of artifacts to nodes in the physical design of a system. A single deployment diagram represents a view into the artifact structure of a system. During development, we use deployment diagrams to indicate the physical collection of nodes that serve as the platform for execution of our system.

Layered architecture is an approach to splitting up software into packages. The term refers to breaking up a software application into distinct layers or tiers. These levels are arranged above one another, each serving distinct and separate tasks. Software in one tier may only access software in another tier, according to strict rules. In an OO system, systems analysts create class packages for each tier and populate these with classes that implement the architecture. For example, they might add a class to handle the saving and retrieving of objects from the database. There are a number of approaches to layered architecture : Monolithic (One-tier), Two-tier , Three-tier, N-tier

In monolithic architecture, these three areas are all bundled together in a single application. Monolithic architecture is often employed on mainframe systems. The common approach for new systems is to separate the application into various layers, or tiers. In two-tier architecture, there are two layers: a server (a central computer system) and a client (one system at each desk). In the “thin client, fat server” variation on this theme, the presentation logic and minimal business logic reside on the client system; the rest is on the server. In “fat client, thin server,” the presentation logic and much of the business logic reside on the client. In three-tier architecture, there are three layers, or subsystems: a client system, loaded with presentation logic; an application server with business logic; and a data server with data logic. Finally, in N-tier architecture any number (N) of levels is arranged, each serving distinct and separate tasks.

Any software application can be seen as consisting of three broad areas: Data logic: The software to manage the data Business (processing) logic: The software that enacts the business rules Presentation (interface) logic: The software that manages the presentation of the output (such as screens)

Essentials: The Artifact Notation An artifact is a physical item that implements a portion of the software design. It is typically software code (executable) but could also be a source file, a document, or another item related to the software code. Artifacts may have relationships with other artifacts, such as a dependency or a composition. The notation for an artifact consists of a class rectangle containing the name of the artifact.

Essentials: The Node Notation A node is a computational resource, typically containing memory and processing,on which artifacts are deployed for execution. Nodes may contain other nodes to represent complex execution capability; this is shown by nesting or using a composition relationship. There are two types of nodes: devices and execution environments A device is a piece of hardware that provides computational capabilities, such as a computer, a modem, or a sensor. An execution environment is software that provides for the deployment of specific types of executing artifacts; examples include «database» and «J2EE server». Execution environments are typically hosted by a device. Nodes communicate with one another, via messages and signals, through a communication path indicated by a solid line. Communication paths are usually considered to be bidirectional, although if a particular connection is unidirectional, an arrow may be added to show the direction. Each communication path may include an optional keyword label, such as «http» or «TCP/IP», that provides information about the connection. We may also specify multiplicity for each of the nodes connected via a communication path.

Essentials: The Deployment Diagram