I am creating application for Diabetes log system. I am confused whether database in UML -Use case diagram count as actor or not ?
the application is recording the diabetes glucose reading which will be saved in firebase and it can also retrieve the readings for showing the progress in chart format.
please can someone help me?
thank you.
No, databases should not be included in a Use Case Diagram of an isolated system. Databases are a static internal part of a system and do not directly take part without a front interface (i.e. your system itself).
However, if your database is an external entity i.e. it is being shared between different systems then maybe it would be wise to show it as an actor.
That depends on what use case diagram are you working on. UML standard does not attach diagrams to levels of abstraction.
You can create a use case for the behaviour of the whole product with the whole surrounding system and all human users - from the point of view of an external user. And you can create it for a better explanation of behaviour of a small sub-sub-subsystem.
In the first case, even the main application won't appear as an agent or meant as a subject. In the second case, if that subsystem works with DB, DB will be an agent.
UML is a free enough standard and rarely strictly forbids something.
Related
I'm stuck and confuse if I need to identify Database as an Actor since the database is given in the scenario.
I tried first to make it as an actor since based on the scenario, the data needed is from database. I Also tried to create a use case for the whole scenario but not sure if correct.
Here is the link of the scenario: https://justpaste.it/7tljo
The Use Case Diagram I created:
Is the database an actor?
A database should in principle not be an actor in a use-case. Two reasons for that:
A database is in general a component used to implement a system, so it is part of the system's internals (even if it is bought from a third party and installed on a separate server). But actors must be external to the system.
Actors may represent separate systems that interact with the system. But some degree of autonomy is expected since they play a role in the case: either the system actor supports the use-case, like a human actor could do, or it uses the system for achieving its own goals.
More generally, some useful question to ask yourself about candidate system actors: does the business need to know? are users or business stakeholders interested in? is the system actor a system that would be useful if your system wouldn’t exist? could we imagine the same use case with a human user instead of a system actor?
Is the overall diagram ok?
Syntactically, the diagram looks ok. But it methodically break down features/functionality in smaller pieces. This is called functional decomposition: Although it is not forbidden by UML, it leads to complex and unreadable diagrams. This is why the use-case community recommends not to do this, and instead prefer to align use case on user goals.
Hint: if you start to think about workflows, order of operations or user interface components when you design your use-cases (e.g. review contract, approve contract), you probably should consider using an activity diagram instead.
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 am currently taking a course that gives an introduction to project planning. It is mostly about how to draw UML diagrams (blegh), but also has a few other topics.
One part in particular keeps bugging me. In the course they describe a method for going from a set of requirements to an initial class diagram, but everything about the method gives me this feeling that it is most definitely not the way to go. Let me first give an example before proceeding.
Let's consider a system that manages a greenhouse company. The company has multiple greenhouses, and every employee is assigned to his/her own greenhouse. A greenhouse has a location and a type of plant being grown in there. An employee has a name and phone number.
Here's what according to the course's method the class diagram would look like:
To me this looks like a database layout adapted for code. When I go about designing a program, I try to identify major abstractions. Like all the code that interacts with the database or the code that is responsible for the GUI are all different parts of the system. That would be what I consider to be an initial class diagram.
I simply can not imagine that this is a common way to start designing the architecture of a project. The classes look ugly, since if you take a slightly larger example the classes will be flooded with responsibilities. To me they look like data objects that have functionality to them they shouldn't have. It does not give me a clue on how to continue from here and get a general architecture going. Everything about it seems obsolete.
All I want to know if there's someone out there that can tell me if this is a common way to get a first class diagram on paper for reasons I am overlooking.
I would say it's reasonable to start with a logical model that's free of implementation constraints. That logical model is not necessarily concerned with physical implementation details (e.g. whether or not to use a database, what type of database, OS / UI choice, etc.) and thus represents just "real" business domain objects and processes. The similarity to a potential database implementation shouldn't be surprising for the simple example.
By understanding your business domain (through the logical model you've started to construct), you will be better placed to subsequently identify, for example, which architectural patterns are appropriate, what screens you need to build, and database elements to design. Possibly, there will be another part of the course that will aid you in this stage.
In practice, you will often know that you're intending to implement, say, a web-based application using MVC with a back-end database, and may look to model the implementation classes in parallel with your business items. For your course to use a method that emphasises the distinction between logical and physical stages doesn't sound unreasonable.
When I go about designing a program, I try to identify major
abstractions
Same principle in UML as well. You represent abstractions and their relationships and due to existing Visual Tools you can do a presentation of a system to stakeholders or even generate automatically stubs from your design.
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.
Is This use case is correct/proper according to UML? if not please give some input to improve it..
The ways we can look on it as the boundary value "Use Cases" can be described something as "Release Phase 1"?
Writer Module/Reader Module should be proper Ator?
alt text http://img190.imageshack.us/img190/6708/usecaseh.jpg
This diagram is telling me that there is something external to the system you are developing called a "Writer Module". The Writer needs three Use Cases, for example Initialization.
Similarly another actor needs Check Status and StackUp.
If that is what you intended to say, then this diagram works. Do you really mean it? Does only the Writer module Initialise the system? Or does the system initialise itself? Can the Reader check whether the system has been initialised, before it has been initialised? Is there another Use Case?
Small improvement: make the Use Case names match in their parts of speech. Initialisation is a "Thing", Check Status is an "Action". Perhaps Initialize System might be better? "Stack Up" not "StackUp", be consistent.
Normally the reason you group the use cases using a box is to show what system is helping meet or realize the use case. It is formally known as a system boundry ("The system you are building". Normally the systems, modules, etc that are actors are more black box, existing, or use only. If there are many new or modified systems this definition gets confusing.
The other comments are semantics of what you are showing, but are not sytax, still important.
Page 103 of Martin Fowler has a diagram and discription that uses the system boundry concept and system actors.
To pick on an example: this diagram says that Check Status is a scenario with two participants, a Writer and a Reader. Is that what you want to say?
Also, I don't remember seeing boxes around (sets of) Use Cases in general.
Use cases are meant to show how someone uses a system to get something of value. Actors always represent persons, in the sense of an independent being who has goals and is capable of seeking something of value.
Actors are represented in one of several ways, either directly by name, or by inclusion through a role, or by proxy in the form of an agent acting on behalf of a person or role (the "system" actor). Regardless of the form, the actor is always independent, and always capable of "acting" upon the system to achieve its own ends.
The diagram you have here is NOT a use case diagram. "Modules" are not independent, goal-seeking entities, they appear to be simply components of some system. They are not capable of "seeking" anything, they are just implementation details.
The diagram you are probably looking for is the Deployment diagram (if you want to model how specific components are wired together), the Activity diagram (if you want to model application logic), or the Class diagram (if you want to model the formal relationships between components).