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.
Related
I have Use case like this.
This is an Emergency Monitoring Use Case and actors, which one is the external system actors?
I just learn Use Case Diagram, and I think the answer is Monitoring Operator, But I confused with the another actor, especially Monitoring sensor and Remote System? Is Another actor an external system actor too? But the option just :
a. Remote System
b. Monitoring Operator
c. Monitoring Sensor
d. Generate Alarm
Can you give a link, so I can read it, too prove my answer is true / wrong.
An actor is always external to the system. An external system actor is a non-human actor.
In your diagram, the Monitoring operator seems to be a security agent looking at the screen and reacting to what's happening.
The Remote service seems to be a non-human actor that interact with some use case, probably to automatically feed data into the system:
The diagram has a syntactic error: the arrow from Remote System and Monitoring sensor to Remote service needs to be a generalization arrow (normally a big white triangle. A use case does not allow to associate actors between them). This means that both are special forms of Remote service.
All these three remote actors are therefore candidate for an external system:
However, Remote service seems meant here more as a placeholder for its specializations. You could therefore as well omit it.
If the sensor interacts with a system as an actor, it should be complex enough to be autonomous. This means that it's not a passive sensor but could be conisdered as a small active system. I would name it as well.
And of course, the Remote system is without a doubt an external system actor.
While discovering SF Reliable Services I want to make sure that next basic statements are true.
Reliable Services Default Communication stack (DefaultStack) and Reliable Actors Communication stack (using ServiceProxy/ActorProxy) can only be used for communicating inside SF Cluster. Customers from outside must use WebAPI/WCF stacks.
ServicePartitionResolver, CommunicationClientFactory, ServicePartitionClient are stuff that already implemented inside DefaultStack. I don't have to worry about it if I use only DefaultStack.
Some Stateful service has more then one partition, and I want for example to post an item to process it. It is not SF's responsibility to decide what exactly partition should be used by posting customer. I need manually implement an algorithm resolving partition key or name and use it in ServiceProxy constructor (for DefaultStack).
You're correct on all those points,
If you want to communicate outside Service Fabric you need to use something like an OwinCommunicationListener (see here).
You’d only have to implement those if you wanted to plug in your own communication stack.
Yep, you’d need to define the partition key when you’re creating a ServiceProxy.
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'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!