Suppose that I am designing a distributed application:
It is composed by one host, that is the frontend web service of the company (CompanyWS), and one or more hosts, say three, that are the distributed warehouses of the company. Each warehouse is a web service (WarehouseWS) and provides one interface, for instance IWarehouse.
Well, because a UML component
[...]represents a modular part of a system, that encapsulates its content and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces
the web services can be seen as components.
In a UML Component Diagram how can I express the semantic that the CompanyWS can be plugged to one or more WarehouseWS? Is an association between the components the right way?
In the UML 2.4.1 Specification it is possible to use ports with multiplicity between components. See page 188, OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1
So you could define the Warehouse Port (wp) with cardinality [0..1] and the provided interface IWarehouse on component WareHouseWS. On the Component CompanyWS you define the Company Port (cp) with cardinality [0..*] and the required interface IWareHouse.
wp : IWarehouse [0..1]
cp : IWareHouse [0..*]
Related
I found an example UML diagram which puzzles me:
I am not sure if this corresponds to UML 2.4.1 as no modeling tool I tried lets me create the connection. I looked up the specification and I think that the connection is not valid UML 2.4.1 because an activity parameter node is not a ConnectableElement, but I am not sure. However, the example is taken from the specification of the UML MARTE 1.1 profile by the OMG, which says
Note that this usage of connectors is
compatible with the abstract syntax of UML, as both Property and Parameter are ConnectableElements
In the above figure, input is of type Activity Parameter Node which is special type of ObjectNode, similar but different to Pin. It is associate with parameters owned by the activity:
The connection in the figure is a delegation connector. As can be seen in the above hierarchy, ActivityParameterNode is not a ConnectableElement, so I think the statement in the UML MARTE specification is wrong.
Is this connection is valid UML 2.4.1 and should be supported by UML modelling tools?
This is no valid UML (neither 2.4.1 nor 2.5 or any prior one). It mixes behavior with static design. A port on a class is a static construct which allows to attach interfaces. An ActivityParameterNode in contrast is used to model "data flow" (it can send or receive objects via an ObjectFlow to/from Pins of Actions inside).
This is (probably; my knowledge is not sufficient here) valid in MARTE. You can make it valid in your domain by introducing a profile which defines this language construct. Most likely you could use a MARTE profile for UML or an extension of it or (as said) you make your own.
P.S.: I tried that in Enterprise Architect and it lets create me a Dependency or an InformationFlow between both.
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.
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/