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.
Related
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'm trying to develop a web-app and some desktop apps, all of these apps communicates via database or socket tcp. These desktop apps are running in background so, there is no use cases and the web-app is only used by remote users.
And, these desktop apps communicates with the web-app via the DB and vis versa.
Which UML diagrams may help me to conceptualize the work of the desktop apps, please?
I've tried to conceptualize this thing using the deploiement diagram, but, I think that it's unsufficient to explain the whole work in a report. Isn't it ?
Thanks a lot!
If you read up on the theory of use case diagrams and actors, you will see that an actor (something that interacts with a use case) can be a person or another system.
In this case, since your app is running in the background, is must be triggered by something: by a person or by a job scheduler (=a system). That means that the triggering is done by an actor, since an actor can be a person or another software system.
So that means you have a use-case (your app) and an actor (scheduler or person). In that way your background app can be described as a use case in a use-case diagram, together with the rest of your system.
As Rolf Schorpion told, you can still use use case diagrams with systemic actors. Just make sure that actor is something external to the system (or part of the system). A typical actor can be Timer (if it is time-controlled).
Besides there is a plenty of UML-diagrams you can use. From the short desctiption you posted, I'd recommend the following set of diagrams (at least these are the diagrams I'd asked you to prepare in order to better understand the system you briefly described):
Mandatory:
Component diagram - showing structural organization of your system and their dependencies (desktop app, WEB app, DB are components)
Deployment diagram - showing the network organization, servers and how the previously defined components are actually deployed on server nodes
Sequence diagram(s) - showing the important communication scenarios between the components. You mentiones TCP, so this can be further refined and displayed using one or more sequence diagrams. It there is a standard communication pattern, a single sequence can be enough. Otherwise, several sequences can be used to cover all significant communucation scenaria
Optional:
Class diagrams - to specify internal components structure - design (blue print of the source code). I recommend this one only if there is a complex design in each compoennt, worth this effort. If not, it could be costly to keep the model in sync with the actual code.
State disgrams - if a class of componen show a behavior that could be modelled as a set of discrete states (e.g. ON, OFF, IN REPAIR, OUT OF ORDER), this diagram is very powerfull and highly recommendedn
Activity diagram - if you have some interesting non-trivial algorithms or simply want to show an overall system logic in terms of sequenced tasks, use activita diagrams.
These are the most common UML diagrams. Besides you have a couple of them more that couls be used in some special conditions (timing for example), but I'm sure you can model almost everything using only these. Use case is far from the first choice for UML modelling.
If you have some further questions or doubts, just ask.
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..*]
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!
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/