I've drawn component diagram for the following scenario. User comes to the system and download content. (This is a part of my whole system). I wanna check whether the User has permission to download that content. Therefore I've used Access controller component. Access controller takes information of user from the database and it takes content from the database. After that it provides content to the user. That's how I've modelled this.
Can I leave provided interface without connecting to any required interface (like in Access controller. That is the content provided to the user after checking permission)?
Is there any better way to do this?
Any guidance would be most helpful. Thanks!!!
A component represents a replaceable self-contained part of a system that offers and requires interfaces to interact with the other parts of the system.
Can an unused interface be represented in the component diagram?
In a component diagram, we are free to chose which component we want to represent, and which interfaces may be relevant for the readers. It's perfectly legitimate to show call the interfaces that a component requires or offers, even if some are left unused. There are even good explanations for that:
It could be a reused component with an interface that is provided but not yet needed elsewhere
Your diagram may not show all the components, and for example not the component that requires exactly this interface.
Your diagram may represent the internals of an enclosing component and the interface provided would document which of the internal components provide the interface that the enclosing component offers to the outside world.
But are you sure about the access control interfaces?
Are you sure that the user should provide the interface DownloadRequest? Shouldn't it be the Access controller that offer the interface DownloadRequest, and the User uses this interface to submit its requests?
Also, according to your narrative, the user requires content to be provided:
User comes to the system and download content.
Wouldn't a socket that requires Content be missing on the User side? And would the Access control provided Content be connected to exactly this socket? (i.e. no unused provided interface anymore)
Related
My application have a contact option which will open the email app with the massage page and the message receiver is set to be the application support email.(I have attached a picture of what I mean)
I have written it as a requirement but not sure on how to illustrate it in the system class diagram and Use case diagram.
What i have initially did in the use case diagram is: connect my user(Primary actor) to the use case "Contact Support Team" which is connected to a secondary actor "Mail system".
As for the the class diagram I have attached a picture of the part of the class diagram the shows this connection.
I'm confused by it since after the implementation I’m not sure if what I documented is accurate and if the mail system is considered as an external system here, and from what I understand is that if I'm dealing with an API then it is considered as an external system so is that applicable on the situation here?
The boundaries of a system are a fuzzy topic, because it depends on your definition of the system. In other words: you set the boundaries.
To take an extreme example, Ivar Jacobson, the inventor of the use-cases has written a book (The Object Advantage:business process reengineering with object technology) about applying object oriented modeling to human organisations (i.e. companies). The system under consideration is in this case a business made of components which are departments, people and IT systems. Of course, you can then zoom on the IT system (i.e a subsystem of the organisational system) and see the other elements as external. You could zoom further on one subsystem of the IT system and consider the other subsystems as external, and so on. Up to you to decide at which level you see things.
More generally, and independently of Jacobson‘s pioneering work and even object orientation, very complex systems (satellite systems, telephone networks, …) are often seen as systems of systems. There‘s even a profesional organisation fir people working in these extremely complex environments (INCOSE).
Coming back on your question: the mail system can be seen as an autonomous independent system, since it has an own purpose and can be useful independently of your app. It is therefore a candidate actor and, hence, external to your system.
On the other side, you could add an email function forwarding emails using SMTP directly from your app. So you could see the emailing system as an implementation detail of your system (and you just happen to rely on something existing). So it is a matter of viewpoint. Whatever your choice, the diagrams are not wrong and you can explain the scope that you use in your model to avoid ambiguity. The only thing, is that you should stay consistent with your own viewpoint.
I am currently working on the use cases for a car sharing app.
The simple diagram for the process of registration looks like this:
At the moment I am stuck with the following scenarios.
When a new customer is registered, a process is carried out at the head office (central)in which the following points are checked
Scenario 1 - Head office side:
1. The identity of new customers is carried out externally with
the post. Two possibilities: presenting the identity card at a post office branchor carrying out by video.
2. The verification of the customer's bank details is carried out externally with the bank.
3.The system will verify that the contact details (email address) are correct
4.the consent to the GTC has been obtained
My sketch for the confirmation process looks like this:
How do I show that the system verifies that the contact details (email address) is correct ? How do I show that consent to the GTC has been given ?
Scenario 2 - Customer's side: A customer can view and edit the information of his registration.
1.Edit profile data
2.Edit contact information
3.Edit bank details.
If information is changed during editing, verification must be carried out again by the head office.
What would the two use case diagrams look like ?
One or two apps?
(Posted before diagrams were added to the question)
Nothing in the narrative says that you need two systems. It's too early to decide about system architecture. You could have the following variants, each with pros and cons:
one and the same system (e.g. post office and customer access it via the web);
one and the same system that is accessible using different components on different devices (e.g. a rich client in the post office, a web interface for the customer on her mac/PC and a mobile app for a customer when using a smartphone);
several independent systems (e.g. a back office in the post-office, and an independent app that would connect not only to the back office, but also to other back-end services e.g. from other companies).
But how do you want to decide before first knowing what is needed and how the needs are related?
First, you have to understand the big picture of what's needed. Focus on the users not on the inner details of your solutions, as explained in the UML specifications:
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...)
a UseCase (...) specifies a set of behaviors (...), which yields an observable result that is of value for Actors or other stakeholders (...)
(...) without reference to its internal structure
Look into your narrative to find actors (people, organisation, responsibilities), their goals (what do they need to do?) and how they could relate to each other. Just try a first sketch.
Your current model
(Posted after the diagrams were added)
I still see no reason to go for 2 distinct systems. You are working on a solution for car sharing. It may have different sub-systems/components, but the actors do not care. And neither does your customer. But:
If you'd go for two independent systems, you'd draw two disginct diagrams, and in each diagram you'd have an actor representing the other system that interacts with the system under consideration. As said, this makes sense only if it's an independent system.
In your case, I could imagine this for the bank account verification and the video identity verification: unless you intend to develop your own super-secured AI component capable of doing this, you'd probably outsource this to a specialized company, that may offer this service via an automated API.
The identify verification is at a different level of details than the other use-cases. You may want to show it in a separate diagram, in order not to pollute the main diagram.
And lastly, your second diagram has some issues:
the arrows of extend and include should not following the same direction: the target of an include is the included use case whereas the target of the extend arrow should be the use case that is extended (and not the use case that is extending the normal use case as you have shown).
ID correct and Bank correct are states. Use cases do not show states. The end-state can be specified in the description of the use-case but not in the use-case diagram.
Post office, Bank account, Video seem to be use-cases, but they are not well described.
A possible diagram could therefore be:
Note: I'd personally prefer specialization of Ensure identity. This corresponds more to the reality that there are two very distinct behaviors. But extension is ok.
Just to stress this fact: you do NOT describe a scenario with use cases. A use case is "just" to show the added value a system under consideration delivers to one of its actors. What you are asking is functional decomposition and that's just plain wrong. You would describe a scenario with an activity diagram (or as plain text like in the Cockburn way).
I have developed an android application that communicates with a server. Through the application the user authenticates on the system that the server is running and after the server is able to send information to my application.
I'm making a use case diagram (UML) for my application but I'm not sure if I should represent the server as an actor (external) or omit it from the diagram... I'm new in UML so the definitions are a little confusing to me at the moment...
Can anyone help me with this?
(Sorry if this is not the right place to put those kind of questions).
First off, who is the diagram for? And what are you trying to communicate with it?
UC diags are typically used to dscribe Users (Actors) and what they want to achieve (Use Cases). They don't focus on how the user's goals are facilitated.
Your question focuses primarily on the technology; the only discernable Use Case is "Authenticate" for the "User" Actor. That doesn't seem particularly insightful. Developing this line of thinking, the next question would be: why does the User need to be authenticated? i.e. what can he/she do once successfully authenticated? And are those things in scope for your system? Relatedly, authentication commonly comes with a set of companion UCs: registering in the first place (e.g. setting name, pwd, memorable data), resetting / retrieving lost pwd, etc.
The above all assumes you're really trying to communicate who the users are and what they need to do. It may be that's not your purpose; maybe you want to communicate the solution design (User accesses application, app sends message to server, etc.). If so then you're probably better served with sequence diagram(s) and/or component diagrams.
Note the two aren't mutually exclusive: solution design naturally flows from user needs. So it may be both are applicable. All depends on what you want to communicate.
hth.
If the server is part of your system, omit it. Otherwise, it is an external actor, and you have to put it in the use-case diagram.
I'm finding it hard to get around my head how the specific scenario would work out:
I have a database server, a web server and a user.
When the user registers a service is created to the web server, the web server then goes to the database server and returns to the web server to register the details.
How would I actually illustrate this.
I have created the three Actors; User, Web Server, Database Server.
As a note I have read many online resources, and also a Book on UML.
Thanks in advance.
Are the DB/web servers part of the system you're implementing? If so you don't need them as Actors. UC Diagrams should only show actors outwith the scope of your system.
So you only need one Actor (User) in this case. The Use Case should describe the goal from the User's perspective (e.g. "Buy a Widget").
You could show the servers in a diagram showing how the UC is realised - usually a sequence diagram or activity diagram. Although I'd typically expect to see logical entities (classes) as well / instead of the physical servers.
hth.
I agree with maple_shaft's last statement. A high-level UC (use case) is a vehicle for capturing requirements.
Req'ts are the "what" of a system. What is the system supposed to do. What does the user need to accomplish. What interaction does the user need from the system.
By capturing system components in your UC you are injecting "how" into it and that's inappropriate for a UC. You don't want your use case to say how the system will accomplish something as that's an implemenation decision.
In short, I disagree that you really want to create a Use Case diagram. This sounds more like a component diagram.
Use case diagrams should represent user flow and non-technical flow from a user perspective, not demonstrate underlying architectural structure.
This is a fundamental design question about the service layer in my application, which forms the core application functionality. Pretty much every remote call reaches a service sooner or later.
Now I am wondering if
every service method should have a User argument, for which the operation should be performed
or if the service should always query the security implementation, which User is currently logged in, and operate on that user
This is basically a flexibility vs security decision, I guess.. What would you do?
There is also a DoS aspect to consider.
One approach is to offer (depending on your context) a publicly available instance / entry point to the services, on a well throttled set-up; and a less restricted instance to an internal trusted environment.
In a similar vein, if you identify where traffic originates you can (or should) be able to provide better QoS to trusted parties.
So, I would possibly keep the core system (the services you write) fairly open / flexible, and handle some of the security related stuff elsewhere (probably in the underlying platform).
Just because you write one set of services doesn't mean you can only expose those in one place and all at the same time (to the same clients).
I think you should decide which methods will need a user argument and which will need a logged in user. You'll get the following method types as a result for this:
1.) Type1: Method is best to have a User argument.
2.) Type2: Method is best to not have a User argument.
3.) Type3: A combination of 1.) and 2.)
The solution of 1.) and 2.) is simple, because they are trivial cases.
The solution of 3.) is to overload the method to have a version of 1.) type and another version of 2.) type.
I try to look at security as an aspect. User argument is required for things other than authentication as well. But, I think control should reach the service layer's more important methods only if the user has been authenticated by some other filter. You can't have every method in the service layer querying the security module before proceeding.