I am learning UML and I've focused on a Netflix-like project on which to practice on.
I'm trying to create a simple sequence diagram for 'stream movie' consisting of only the entity classes (so ignoring objects like the user interface, server, and database).
The idea is that members can search the movie catalog, select a movie, the system will then verify whether they have an unlimited or limited membership. If unlimited, they can stream the movie, otherwise, the system must check whether they have reached their limit of 10 movies that month. If they have, then they can not stream the movie and must receive a message stating why, or be asked to upgrade their account, otherwise, they can stream the movie as normal.
This is the class diagram demonstrating the associations so far:
And this is the sequence diagram for 'stream movie' so far, which I need some assistance with:
What is the best way to build that sequence diagram, yet keeping it relatively simple?
Thanks in advance.
I’m not able to give you a “best way” but I can comment on what I see in your attached diagrams. Maybe you can use this to refine questions that are more specific.
Starting at the bottom, your sequence chart is obviously incomplete. My only comment so far on this is that I don’t understand the logic of the flow, being your member calls “search” movie catalogue which in turn immediately calls “select” movie which in turn calls verify membership. These seem like an unlikely sequence of calls. I sort of get what you mean, I think — I suspect you’re missing return messages, and maybe it should be member that selects movie not the catalogue? Also, you have a member object (identifiable by the colon in “:member”) and then classes for movie catalogue etc. which is not really logical except in very specific contexts.
At the top, your class diagram looks much more complete and understandable. I can only really comment here on design choices rather than UML semantics/syntax. I’m happy to answer any specific questions you have on that but as it’s opinion I won’t post thoughts currently.
Related
I'm currently reverse engineering a ticketing system (a ticket booth system with human operator), in order to create a technical manual.
What I want to do was a flowdown from all the functionalities modeled as a workflow from the user PoV using a UML activity diagram. The objetive in this is to first lay the workflow of the user, to than specify all the interfaces/communications with databases and central systems and all the classes as class diagrams, regarding the functionalities displayed on the activity diagram.
The problem is that the system has so many options, like buy ticket, recover ticket, client info, shift managemen... the first problem i got is when i got to the main screen activity there are so many branches that i dont know if i could use a Decision point on the activity diagram.
Anyone can shed some knowledge here? Thanks to all. Cheers.
Even the system is already there the approach for building the model should be pretty much the same as if you were doing the analysis from the start. The main difference is you refer to how the system is actually used, however it's also a good occasion to discover the pain points in the current system.
Your use cases, scenarios etc will be based on what the system currently does.
Don't try documenting a complex system with just one diagram or even one type of a diagram. This approach will most likely fail. In a best case scenario you'll end up with something but it'll be difficult to impossible to read and comprehend.
I'm taking a UML class at my school, and my teacher wants us to do the basic, bare-minimum of the assignment, and will not answer any questions. That being said, the requirements of the system had use-cases of Registration, Student Record, Log-In, Course Record, and Class Record. All it really needs to do is the following:
A student will log into the system and the only thing they can do is
register. In the register page, it would list courses available, a
student would select one or many and then they would list the classes
available for each course. The student's records have to be checked
to verify that they meet the prerequisites.
A registrar can log into the system and they can not only register a student but also view and modify course records, class records, and student records.
Also, the classes can be either online or on-site and I'm wondering if that should be defined...
I can provide more detail if it's needed to understand.
Well, I think I took it too far, and I supposed I wanted opinions on how to go about determining the basic requirements.
I also have a couple questions:
Is a Log-In object required in an SRS? Or should it simply be assumed that the users have logged in?
Regarding cardinality and multiplicity, is it the same concept?
Looking at what I've made my multiplicities, did I make any remarkably obvious errors?
As far as making it less complex, would it make sense to only have: class-type, course, class, registration, student, and registrar?
A systems requirements specification is by far more complex than a simple diagram. There are many ways to accomplish a SRS, so your question is a candidate for being flagged off-topic as being too broad. Anyhow, here is what I did.
In a first step you need to group the requirements themselves. The first broad division is by separating functional and non-functional requirements. Non-functional are those requirements which can not be pinned to a single function. Eg. performance, legal, safety, security, you name it. Those are the categories you build first and eventually you have a set of them in the course of the SRS creation.
Grouping the functional requirements is a bit more tricky. You do that by synthesizing use cases. Each functional requirement needs to be realized by a single use case. You don't need to put in details for the use cases, but only a rough story. But once you have connected all functional requirements to use cases your SRS will be ready.
Note that the non-functional requirements are not yet related. This is because they have impact on a lot of functions and the system design in later phases. It's only necessary to have them clearly structured.
Another thing to note is, that requirements themselves should be traceable to their origin. That means you need a reference to the paper, meeting, phone call, personal talk, etc. from where you got it.
There are many, many details which make creation and maintenance of a SRS a science of it's own, but the above is your staring point.
A class diagram is not necessarily part of a SRS. It's part of a later design specification.
Now for your additional questions.
Log-in is no business object in no case. It is a constraint derived from a requirement "user must be logged in to..."
see cardinality vs multiplicity
I would simply leave away the .. notation. If left away it means just the same (unspecified). I'd remove the 'Log-in' word from credential manager since it will also handle log-out and much more. So the emphasis is not right. Else the class design is, as said, not really part of a SRS.
Suppose there is a scenario of Users having Tasks. Each User can either be a Watcher or Worker of a Task.
Furthermore, a Worker can file the hours he has worked on a given Task.
Would the following diagram be correct? I have looked around at domain models and I have not seen one with the two associations (works on, watches). Is it acceptable?
EDIT: What about this scenario? An User can make an Offer to another user. A possible way of modelling it is shown on the following diagram.
However, in that diagram it would seem possible for a user to make the offer to himself. Is it possible to model some constraints in, or is this handled further down the development line?
It is in principle correct, this is how you model multiple relationships between two classes.
As for the constraints, UML makes use of OCL (Object Constraint Language), so you can say that the associations are exclusive (xor - exclusive or).
Also note that it is generally a good idea to name the end roles of the associations.
Regarding one of the comments saying
There are no UML police to flag you down for being "unacceptable".
It is like saying: there's no code police to flag you down for writing shitty code.
You create diagrams to convey information (for school project anyway), if you diverge from standards or best practices you make it harder for other people to understand your diagrams.
And just like there are linters (jslint, ...) that check your code for common problems, for models there are model validations that do the same thing.
Also models, just like code, aren't set in stone so don't be afraid to modify them when you find a better way to express your domain.
Update
As Jim aptly pointed out, you usually do stuff not as a User (or Person), but as a Role. E.g. when you are student and you are filling a form, nobody cares that you are human, but that you are a Student. Typically a Person will also have several different roles (you could be a Student and a TA, a Professor, etc.)
Separating it in this way makes the domain much clearer as you are concerned only with the Roles, and not the people implementing them.
On the first model, there's not much to add after Peter's excellent and very interesting answer.
However your second diagram (in the edit section) does seem to give a true and fair view of the narative. From the strict 1 to 1 relationships, I'd understand that every user makes exactly one offer to one other user, and every user receives exactly one offer from another user:
"A user can make an offer to another user" implies a cardinality of 0..1 or *, not 1.
From this we understand implicitly that not all users need to receive an offer, i.e. also a cardinality of 0..1 or *
This can be debated, but "an offer" doesn't in my opinion mean at "at most one offer", so the upper bounds of cardinality shouldn't be * and not 1 to show that every user may make several offers and receive several offers.
As you can see, you can add constraints to the schema to increase expressivity. This is done in an annotation between { } . But you can choose the most suitable syntax. Here an example with the full expressivity of natural language (as suggested by Martin Fowler in his "UML distilled") but you can of course use the more formal OCL, making it {self.offerer<>self.offeree}.
I see #Peter updated his answer before I could post this answer, but I will post this anyway to show you some other tricks.
In general, it is perfectly valid to have multiple associations between the same two classes. However, I don't think it's a good idea here.
You say you want to build a [problem] domain model. I'm glad to hear that! A problem domain model is very important, as I explain in the last paragraph here. One thing to point out is that you want to build a durable model that transcends a system you can conceive. In the problem domain, there is no "User". There are, however, Roles that People play. For example, you mentioned Watcher and Worker. Hopefully these are concepts your customer already has in the "meat world".
In the model you posted, you have no place to hang the hours worked or progress made. You might try an exercise. If you had no computer, how would your customer track these things? They often have (or had) a way, and it was probably pretty optimal for a manual system.
Here is how I would model my understanding of your problem domain:
Some things to note:
A Person plays any number of Roles.
A Role is with respect to exactly one Task and one Person. A Watcher watches exactly one Task, a Worker is assigned to exactly one Task, and any kind of Role is played by exactly one Person.
A Role is abstract, and its subclasses are {complete}, meaning there can be no valid instance of a Role without also being an instance of a subclass.
A Task is watched by any number of Watchers and may be assigned to one Worker at a time. There is a constraint saying {person is not a watcher}. (You can show the OCL for that, but few people will understand it.)
I have added a Progress concept as a way of logging progress on a Task. A Worker makes Progress on one Task. Each bit of Progress has a Description and a Duration. Note that I have not committed to any computational way of representing a Description or a Duration. The designer of a system for this will be free to derive a Duration from start and end times, or ask the user to self-report.
I read many articles, and saw a lot of images and I can't answer the question whether objects of View classes or DB classes should be contained on the sequence diagram or it should be more generalized?
All classes that are going to relevant to the design of the operation contained within the sequence should be there.
By making too many things generalized you risk missing important detail. I tend to include references in my sequences from the UI element all the way to the DB. If you are worried that the View and the DB are not fixed and using concrete refs will make your disgram incorrect. This shows that the design will need a close look! Maybe the contract between the view and the middle tier and the DB and middle tier needs to be better defined. Then all you have to do is include references to the contract in a general diagram and further detail in seperate diagrams for each implementation.
You can see the depth that many go to in this intro.
Remember, UML is supposed to be about good communication of ideas/designs. Do what conveys all the iformation that is needed in the simplest way possible!
I have to develop a CRUD application, that will be coded in php.
I have 3 main actors (Users, Administrators and Doctors -- this is for an hypothetical
hospital), each one with different Use Cases already defined.
Although I feel the Use Cases are more than enough to successfuly model the Class Diagram, I am being specifically asked to also include DataFlow Diagrams into the project's documentation.
I've been reading about DataFlow diagrams, and it seems you usually have first of all a Level 0 DataFlow Diagram, to which they call Context Diagram.
Being that this is basically a 3-tier application with 3 different Actors, how should I model the Context Diagram?
Being that a Context Diagram is supposed to just tell us what comes in and what comes out of our System, I can't imagine anything more interesting/descriptive than the following diagram:
Is this supposed to be something like this, or am I totally missing the point? This php page will connect to an Oracle database, but I guess that if the idea is to consider the System as a whole in the Context Diagram, I should "hide" that fact in the above diagram.
Where should I go on from here? I know I should "zoom" the System process to something more detailed. Maybe the next step would be to depict each one of the User Cases in a DataFlow diagram? Do I include repositories of data, already? For example, one for Users, other for Doctors and yet another for Administrators?
Thanks
Are you sure there's nothing else the system interacts with? e.g. diagnostics input, etc.?
If not then your context diag is basically ok - although I'd probably show each entity once and use double headed arrows. I'd agree with your reasoning for the db - it's part of the system, not external to it - so don't show it on the CD.
As for next steps, again you're on the right lines. Try modelling the flow for each Use Case as a DFD. DFDs are very useful for illustrating processing-intensive apps. Difficult to know if that's a good match to your problem or not.
You'll find DFDs are also useful for driving out and validating your Class Diagram. In fact, that's one of their strengths: datastores on the DFD should correlate with the contents of your class diagram (not necessarily one datastore to one class though). So do include datastores as you work through the processes. You'll find it drives out more than just the Actors.
hth.
Some remarks:
You DFD does not tell me much, except that Users, Administrators and Doctors use it, but it gives me no clue what they get from the system (except "Output Data"). IOW the context diagram does not give me the slightest idea, what the system does.
Admittedly, if the system is large, then it can be difficult to describe the dataflows in few words, but just about anything is better than "data".
The fact that the system is a 3tier architecture is irrelevant for the DFD. This is an implementation detail. DFDs are an analysis tool. You describe what you want the system to do, not how this is achieved.
I find it particularly useful to focus on the outgoing flows. While Users, Administrators and Doctors provide input to the system, this is most likely nothing they want to do. It is something they have to do in order to get the desired output.