I know that <<>> is for specifying the view layer,
However, I saw some examples and the DataAccess is like this <<DataAccess>>, is there an explanation behind it ?
That just looks bogus. This is a stereotype and the object has neither name nor type. You would likely need to ask the diagram author for an explanation. Without you can interpret it at will (if you like or allowed to). My interpretation is that is some object which has at least a WriteDB and a find operation.
Related
I am making a class diagram. I have a Person class and an Address class. I am thinking there is a 'Has-A' relation between the Person class and Address class (Aggregation):
Am I right in marking the relationship as association?
Does it depend on us how we want the model the relationship?
For example, if I have two classes, Book and Library, I could say that Books shall not exist without a Library (composition) or I could say that Books may exist independent of library(Aggregation).
There is no one correct answer. There are many valid ways to model a scenario. In this case you could either mark the relationship between Person and Address as an association (more specifically aggregation), or you could mark it as a complex attribute.
Yes, details like that should be discussed with stakeholders / people who understand the domain you are modelling.
Is the association right?
Yes, you are right: a simple association expresses perfectly that a Person has an Address. Nobody could claim on the base of your narrative that your model would be wrong.
But modeling is a form of communication: You may well chose a different notation to add nuance in what you express, and you may decide for different semantics to tell how you see things in view of your needs.
Does it depend on us? Notation
In our example, you may want to clarify what you mean with the association by giving it a name:
Or you may prefer to clarify the role of the address in the association:
Or in complex diagrams you may prefer the shorter but equivalent property notation, nevertheless keeping in mind that "A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not":
Does it depend on us? Semantics
You could go for aggregation, but I'd strongly discourage it since UML does not define any semantic for it. So there's no benefit compared to a simple association.
You could consider composition. It might in general not be the best choice, as addresses exist independently of the persons. But in an application that creates separate Address objects for each Person, it could reveal how you intend to manage addresses.
Or you may want some richer semantics, for example with an association class to tell that people could have plenty of addresses of different kinds:
I've just read a book about UML and an currently trying to create a use case diagram of one simple domain.
The domain states:
There are two kinds of users: default and vip.
Default user can create no more than 10 posts.
Vip user has no restrictions.
What is the right way to bring this restriction into use case diagram?
Is my diagram correct?
If it's correct, can I model the same way the next statement?
User can give only one star to post
Thanks a lot for your attention!
It's almost correct. You should write the text in curly brackets. That will identify it to be a constraint. Further you should use the correct case for Default User. Eventually you can link the constraint to the actor as well. And yes, you can go on like that. Maybe, Rate Post is another use case. Think about that.
I'm wondering if my use case diagram is about right and if anyone could give me some pointers if it's not.
It's for an application where users can login (always required). When they login they see a list with posts which they can up or downvote (like reddit). When selecting a post they can place and delete(only their own) comments.
The user that's logged in can place posts when logged in, but also has a button to view posts they've already placed where they can be edited and deleted.
Finally there's an admin that can delete inappropriate posts and comments.
Am I supposed to define that users can only edit and delete their own posts and comments? If so, how do I do that? Perhaps a different actor?
Thanks in advance!
There are a couple of flaws in your UCs.
Login is not a UC at all (it does not add any value to the actor). It is a constraint you may apply to UCs.
Wrong username/pw is no UC, of course. It's some message that will pop up somewhere.
Register is a UC on it's own. Connect it directly to User.
Using generalization with UC is not a good idea since it will bring in a lot of stuff for discussion. Leave it at the Manage level and describe inside the UC what this means.
<<include>> is usually used the wrong way (namely for functional decomposition). And you are doing that too. So leave it away, concentrate on the basic UC Manage comments and connect that directly with the actor.
If for some reason you need to describe some order for UCs you can use pre-conditions inside the UCs.
Remember that you cannot model everything using use case diagram. A single UC is a set of action flows that provide a specific business result. You can provide details on limitations (e.g. condition that you can manage only your own comments) in a description of UC (either modelled by activity or sequence diagram or simply in a written description) but not on UC diagram.
As the commenting is optional in your system, definitely you've used incorrect relationship. include means that the included UC will be always executed when executing including UC. In your case this is up to a decision of a user which means you should use extends instead (and of course in this case the relationship is in the opposite direction). See 18.1.3.2 (second paragraph) and 18.1.3.3 (first paragraph). You can also find confirmation of that in almost any book about UML based analysis (e.g. Howard Podeswa's "UML for the business analyst" to name one)
Besides that I agree with the list of flaws given by Thomas Kilian.
[Original Title] : Does an actor need to point directly in use case diagram?
or can I do it like this?
in this Use Case Diagram, I want to say that actor can use any use case in the pointed group-of-use-case.
does this kind of thing allowed?
Edit #1
The reason why I ask this question, is because when I create this use case there's a lot of line intersecting each other that makes me confuse.
And there's a comment :
It would be better to split that into smaller diagrams
does it mean like this?
Edit #2
after reading comment :
A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject.
so I decided to change to this :
is this how a use case diagram should be?
Edit #3
CONCLUSION
An actor should point directly to use case
Read more the detail about how a Use Case Diagram should be in comment on this question
To be UML compliant you can not do that. But I guess one can understand what you are trying to communicate.
As a side note: Login is not a business use case. It is a constraint. Also with CRUD use cases I would not separate them but have a Maintain <object> instead (which itself is some borderline use case since maintaining something is not directly business relevant). You can constrain maintenance operations to certain actors separately.
Edit Regarding Login (one of my favorites): Use cases are most commonly used to describe business context (exactly as you are doing). So when looking from a business perspective, a Login is not a use case, but a simple constraint (you can do the business relevant things only when you are logged in).
Now for the Manage/Maintain use cases. They are on a similar level. Usually the "managing" itself is not directly business related. In many cases the focus on the real business was lost. So instead the reason why you manage something is the real use case (e.g. Correct User Data, Collect User Data). This is quite challenging and I confess that sometimes I also fall back to Manage. Most people don't bother but doing a good job requires to think over basics and not adopt bad habits.
Like you can see from the diagram it has three objects. Object_1 has a variable-sized ordered array with references to objects 2 and 3 in that order which is exactly the thing I want to say with the diagram. My problem is that I didn't see anything in the UML standard specifications when I browsed them through for a notation to do something like this.
How do I fix this diagram so that it would be a valid object diagram according to the UML standard? Or is it even possible? Does UML specify a way to say something like this?
There is no specification of what an object diagram (what you show) is (see a full explanation here). So whatever you do will be right (or wrong :-))