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!
Related
Consider the following case:
I have a webservice that provides information about orders in an online shop. On another machine there is a windows service that retrieves orders from the webservice once an hour and writes the data to a database. Instead of a scheduled task a windows service is used, because it provides a tcp endpoint, so a client can manually (using a simple desktop application) command the service to retrieve data of a specific order.
I am unsure where I have to place the windows service. It is a primary actor calling the webservice in a given interval, but it is a secondary actor as it reacts to the command of a client.
How should I proceed creating a Use-Case-Diagram for this scenario?
The answer depends on what you consider as your system.
One system
If your system contains both the webservice and windows service as parts of your (multi-tiered) system, then neither is an actor. The functionality offered by the windows service will be one (or more, depending on the complexity of the service) use case. If you assume that webservice it might become a second use case, that is included by the windows service (a rare case but works here).
The mere fact that those parts are on separate machined doesn't change a thing. It's common approach that database has it's separate machines but no-one reasonable consider it to be separate from the system itself.
Two systems
If you treat windows service as a separate system then you will actually have two use case diagrams, one for each of the systems.
In this case the use case diagram of windows service will have the client as a primary actor and system containing the webservice as a secondary actor.
In the use case diagram of the system with webservice your primary actor would be the windows service system (again as a whole , not a service itself). In this diagram the client is not depicted at all as it does not interact with the system.
Component as a system
Even if you consider both windows service and webservice as a single system, you may still depict use cases of components rather than the system as a whole. In such case the aproach will be similar to the situation with two systems.
In addition to what #Ister said: Draw a boundary that represents your system under consideration. Now think about what is inside (the use case bubbles) and what is outside (the actors). For the latter there's the convention to place the primary actors to the left and the secondary ones to the right. Primary actors are usually considered the ones that start a workflow while the secondary ones are being triggered/informed in the course of any such workflow.
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.
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.
If I am developing an application using DDD, where do the infrastrucure and behavior components go? For example, user management, user specific configuration, permissions, application menuing, etc.
These components really have nothing to do with the business requirements being fullfilled by my domain, but they are still required elements of my application. Many of them also require persistance.
It's pretty normal to have non-domain components along with the domain in your project - after all not everything is business domain oriented. Where they belong actually depends on how you structure your solution. In most cases I tend to follow Onion Architecture, so all of my logic is provided by Application Services, regardless if it's domain or non-domain oriented.
Well if you find that your usecases rarely demands information from your core domain joined with application specific, you can probably split that into a separate database. Access this information through Application Service layer, since this layer is suppose to serve your application needs. If that includes user profile persistence etc, that's fine.
But you remember that if you got infrastructural failure and you want to do a rollback with some transaction logs or database backups, you'd probably want all persisted data be roll-backed. So then it's easier to have these domains share a database. Pros and cons - always compromise...
If I know that this application would have minor interaction with it's environment, I would put this in one database and let the application service layer interact with clients.
If I know that there will be several applications/clients I may consider to split database so that Webb application user specifics are stored in separate database. Very hard to say, since I have no overview of all the requirements.
/Magnus
I have to develop an integration concept to integrate my software as a subsystem into an enterprise information system which communicates with other information systems in other institutions.
I want to show a diagram which explains how the several subsystems are connected and which data is communicated between the subsystems. My problem is that I'm not sure if there is in the UML language a diagram-type that supports modeling of complete information systems.
I thought about the deployment diagram, but I am not sure if it is the right. I don't want to start an then recognize that it is the wrong way.
Is there any advice which diagram should be used, or if there is an alternative modeling language for complex information systems?
A component diagram is what you want - see chapter 25 of "The Unified Modeling Language User Guide".
I want to show a diagram which explains how the several subsystems work together and which data is communicated between the subsystems.
I'd probably start with a conceptual sequence diagram.
So, for example, you could have your lifelines represent the various components that you're integrating with, and your interactions could be any of the messages that need to transfer to and from those components.