What are the Differences of Component Diagrams and Deployment Diagrams?
Simply put, a Component diagram shows you how different elements of your system have been grouped together (into assemblies / dlls etc) - and the link between these components. A Deployment diagram takes you one step further and describes on which hardware elements do these components reside.
So for example, if "Utility.dll" is a component and say it is deployed on the Client Machine (hardware). Then, the Component Diagram of this system will show Utility and its link with other components in the system (say.. Customer / SQL Packages). Whereas, the Deployment Diagram will show the hardware configuration - DB Server / Web Server / Client Machine .. and Utility component will be placed into the Client Machine Node.
Component Diagrams are used to diagram the high level components which you will be developing. For example , in my application, i use COM to separate the modules. Each COM object runs in its own executable and is a modeled as a component.
Deployment Diagrams are used to diagram the actual runtime modules which are required to complete the system. This include your modules and any hardware / software which is required to complete your system. In my application, the Deployment diagram will contain the names of all the servers and which modules they will be running.
A component diagram describes the organization of the physical components in a system.
Deployment diagrams depict the physical resources in a system including nodes, components, and connections.See for example here http://vinci.org/uml/
Related
My deployment diagram has a device with a Windows ExecutionEnvironment in it. The application uses several dynamically loaded libraries, some of which are deployed with the application, others into the system itself.
How are dynamically loaded libraries normally represented in deployment diagrams?
My current theory is my application gets its very own execution environment within the Windows where I deploy my application specific dynamically loaded libraries, and have the system libraries deployed outside it:
For above diagram the system has v1 of libraryA and libraryB installed, and v2 of libraryA is deployed with the application, shadowing the system version.
Your approach makes perfectly sense:
ExecutionEnvironments represent standard software systems that application components may require at execution time.
Moreover:
Artifacts elaborate and reify the abstract notion of DeployedArtifact. They represent concrete elements in the physical world, may have Properties representing their features and Operations that can be performed their instances, and may be multiply-instantiated so that different instances may be deployed to various DeploymentTargets, each with separate property values.
This applies perfectly to dynamic libraries, where there is one library loaded by the OS and that may be used by multiple applications, each in its own address space.
Some hints:
You could use the «Library» and «Executable» stereotypes of the UML standard profile to better distinguish different kind of artifacts.
You could add the dependency from the executable to the required libraries
I know that Component Diagram represents the architecture of some information system or the overall system, so it's necessary to mention the components that represent external databases used by the system.
My question is:
What if the application uses an internal database that lays on the same computer where the application is. Should it be represented as a separate component or a component with the system name is enough with its interfaces?
It depends what do you want to show on the diagram.
If you're focusing on detailed application architecture you still might want to show database as a separate component (since that's what it is in reality).
If your goal is to show application decomposition you can probably completely omit the database in the diagram. That's valid especially if your queries are embedded into the application layer other than database itself. If you have a dedicated database code (do database offers some sort of API to the component) you'd usually always represent that as a separate component.
The actual location of a component is irrelevant on a component diagram. It's natural that some components share the same execution environment.
What type of UML diagram should I use to model the parts of a web app?
For instance, lets say my parts are as followed:
Server
Database
Web App
Multiple APIs
The web app interacts with all the other parts in some way. From my research, the best options seem to be either component, deployment, or sequence.
Here's a general idea that I'm going for with my diagram, but I do not know which UML diagram this would best be represented in.
If you know the diagram I should use, I would like to know how each part is represented in the diagram. For example, in a deployment diagram, I know that a server/database would be nodes. And, APIs would possible be artifacts?
For designing a web app (or any other type of software application), following a best practice Model-View-Controller (MVC) codebase architecture, you first need to make an information design model, typically in the form of a UML class diagram, defining the model classes, or the "model", of your app. The "view" (or user interface) of your app is based on the model.
Your diagram attempts to model the deployment architecture of your app. But this question comes after choosing a codebase architecture and an information architecture.
You can find more explanations about the architecting process, and the code of several example web apps, in my book Web Applications with JavaScript or Java, which is also available as an open access online book.
This depends a lot on what you're wanting to model and communicate. All of the diagram types you mention would be useful ways to describe a web app. Each focuses on a different aspect of the web app -- component models are about software component structure (database, web app, apis), deployment models show how instances of these components are deployed into deployment nodes (servers, devices etc). Like Thomas says, this is a very broad question -- in essence you are asking how should you describe your web app's solution architecture which is not a trivial exercise. Is there something more specific I can help with -- can you narrow down what it is you want to show about your app?
Your start with the component diagrams is fine. Generally your question is too broad to be answered here, but a few bread crumbs anyway:
In a next step you can describe the single components which are hosted inside the single nodes. You can make the nodes navigable (means you have a composite diagram showing their guts) so you can place component instances showing their interfaces. The latter can be shown with either lollipops or as stereotyped classes which the single components implement. Following that you can break down components in a similar fashion showing how the components are implemented with various classes and how these realize the single interfaces. It's possible to show the interfaces outside the components and <<delegate>> them inside the specific classes.
The story goes on, but it's too big to be told here.
I am designing an UML diagram for an Apple Watch Extension. How should I represent host app using UML ? UML Node or UML component ? Please note that there can be inter app communication between the extension app and the iPhone app (host app).
UML nodes are apparently used to depict physical resources, so your watch would be a node, whereas a component is usually understood as a software component. Since you want to model software, go with components (which will also nicely visualise the plugging between extension and host).
uml-diagrams.org explains the basic difference as "node is a deployment target" while "component is a structured class representing a modular part of a system"
They're typically used in different kinds of diagrams with different purposes. e.g. in UML Class Diagram both extension app and iPhone app would be represented as UML Class
You can, however, create your custom diagram mixing whatever UML artifacts you need - to make your design message clear to the readers
-Node represent the physical part of the system. for instance , server ,network and printer etc.
-Component represent any part of the system it might be physical aspect such as libraries ,file ,executables,document,packages etc that reside on the node.
-Component - refers to a module of classes that represent independent systems or subsystems with the ability to interface with the rest of the system.so it tells who does the system functionality.
Components are things that participate in the execution of a system; nodes are things that execute components.
Components represent the physical packaging of logical elements; nodes
represent the physical deployment of components.
I'm developing a 3 tier based system , the user passes data to the server which performs server side processing and queries a database etc the usual stuff. I'm wonder should I include the database in the diagram as an actor ?. I have already included the server as well as the end user
Thanks.
If you're developing the full system then no, don't include the DB as an Actor. I wouldn't recommend showing the Server either.
The purpose of a UCD is to show the system context in terms of the features (Use Cases) it supports and for whom those features are provided (Actors). UCDs deliberately don't show internal structure - so you focus on the Users and their Needs without getting sidetracked by implementation concerns.
Since the Server and DB are part of your system they're "design detail" for how you realise the Use Cases. Therefore the don't sit outside your system, therefore they're not Actors. The only time I'd recommend putting other systems on a UCD is when (a) they're external to the system you're building and (b) provide or receive some value to/from it.
UML provides other diagrams for showing the internal components of the system:
Deployment diagrams show physical hardware and allocation of software components to them
Component Diagrams allow you to show the logical structure of the application
Sequence Diagrams or Activity Diagrams allow you to show how a Use Case is realised in terms of its logical components
(Note I'm not suggesting you use all those, just what's useful).
hth.
i think the web servers and the database should labeled as the system, users or external third parties could be actors!