Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I am trying to implement a state machine, however I am very confused about it at the moment.
Can you have states that model alternative flows, such as Vehicles not existing - if a penalty fine is to be issued, or a Reg no being invalid?
I understand your problem - state machine has no easily visible fork element in VP UMP . But it needn't. Every state block works as multi-fork. All arrows from a state to other ones are cases, "what changes if..." The text of condition is on the arrow. An arrow can have more, than one condition.
So, the answer is
YES!
And really you can use forks, too. They are hidden under "initial pseudo state". But use them only if there is one event coming from a state and it is forking without the relation to a state. Or if it starts some flow.
I can't commment yet, therefore feedback to your question is not possible for me in another way than answer. My answer'd depend on your problem
If you're thinking in flows maybe you should use an activity diagram instead of a state machine, there's a difference between the functional und the behavioural view.
Rethink the states you use
Use a hierarchical state machine (e.g. have a look in http://www.barrgroup.com/Embedded-Systems/How-To/Introduction-Hierarchical-State-Machines)
There are alternative flows and paralel execution possible in state machines of course. Use Shoice pseudstate to define alternative transitions. Condition to decide outging transition is defined as a guard of transition. States must reside in the same region. For concurrent states activation, use Fork pseudostate. Transitions outgoing from fork pseudostate must be directed to the states, all in differen regions.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a problem in "include" & "extend" relation between my principal use cases.
I`m using IBM Rational harmony-SE in IBM rhapsody tools. The issue is, how to depict the link between them self, in activity or in sequence diagrams?
In rhapsody, when you want to create a sequence diagram of a use cases, you can use Harmony Toolkit that draws automatically do that, but in a generated Sequence diagram, Harmony Toolkit doesn't consider the "include" and "extend" relation between use cases.
How can I solve this?
Disclaimer
There is no definite answer to this question. This is only one of possibilities, however fully conforming UML and working quite well. Moreover it doesn't provide redundancy in models (each UC flow is defined at most once and the included/extending ones are the only referenced).
Activity diagram
On UC Activity Diagram use Action that is a call to included/extending UC Activity (as part of your flow). Depending if it's includes or extends the action will either have to happen for includes (i.e. it'll be on a flow that is always executed or on all alternative flows) or will be possible to use either a flow containing it or not for extends (i.e. it will be on only some but not all of alternative flows).
Sequence diagram
On UC Sequence Diagram use Interaction Use block (ref), referencing the included/extending UC Sequence Diagram. Like for Activity Diagram it will either have to happen for includes or be on only some of Combined Fragment sections allowing to pass the whole sequence either including or omitting the referenced part for extends.
Note about automated generation
I don't think there is any diagram generation tool that will automatically support inclusion/extension on Activity Diagram or Sequence Diagram of a UC and there are many reasons for that. You'll have to draw diagrams yourself or correct the automatically generated ones accordingly.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to write use case diagram for a wireless NIC driver. There is no direct interaction of the user with the driver. How can one write use case diagram for drivers?
The 'user' in a use case is not necessarily a person hitting keys or anything. It is an 'actor' external to the system being described who can interact with the system being described.
Here, such actors could include routers or other bits of hardware that your NIC wants to connect to or that want to connect to it; it includes the hardware and OS the NIC is plugged into which the NIC exchanges signals with; and devices it is connected to and the signals they exchange.
Use cases would include:
The NIC detects available routers....
The NIC receives a request from......
Et cetera, to cover what you want the NIC to do.
Extending the previos 2 answers with a bit more info and an example...
The key aspect of the use case model is its context, or the system scope (depicted with a Boundary element on the diagram itself - see example). Everything that is "inside" the scope is abstracted by a UC and everything from the "outside" is modelled by an actor (human or system). Use cases model the interaction, the dialogue, the exchange of information between the two of them.
I see at least two system actors in your case, a controlled device and a client program. Another possible actor has been added in the following example, to show some eventual periodic communication with the device through the driver:
This is a very nice example on how different UML diagrams play together to show the whole truth. UC diagram focuses on the meaningful interactions between the System and its environment, showing no technical info about it.
In order to do this you need another diagram (here component, but classes are also ok, even both). This diagram is the place to define interfaces, APIs, method signatures, dependencies...
You can of course go a step further and use a sequence/interaction diagram to connect the Use cases with the corresponding components (on my example are only shown the "traces" to clear up which actors are implemented by which components). Something like this:
Note that something called "Data" is sent to the Driver (and the Device). This can further be defined in a class diagram, making a whole new point of view on this system.
It is common practice to put all this info in use case description. Although this approach might even be syntatically correct, the full power of UML is released by separating the concerns in different diagrams, keeping each one as simple and clear as possible, focused on only one concern and clean of others.
In your scenario Actor is system. You can include a system into use case as an actor, if that system is outside of the system you are developing and if it directly interacts with that system you are developing.
You may also need to define boundary of your system, which means its scope and interfaces. For example: you may want to create an actor for Routers. Preferable actions would be how they will interact with the driver of yours, as they are directly interacting with the system you are developing.
Hope this helps.
If you need further explanation with example, please comment below.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How to model logic of complex operations? For example save methods for root entities where state, versions and various atributes should be handled according to some logic. DTOs and entities exist.
I was thinking about sequence diagram, activity diagram, natural language and some abstract code.
I think sequence diagram is not appropriate because it's more likely for modeling of an interaction.
Activity diagram seems to me too clumsy and I don't know where to put instructions like assignments of attributes. It doesn't look right in a note or description of an activity.
Natural language is ambiguous and there is little information in large volume.
Mayby abstract code could be the right choice. Or its combination with natural language. Is there any recommended form? I don't want to write Java code.
If you mean - complex algorithms, they are probably best modelled by activity diagrams. Since UML 2.0 they have actions for practically all kind of operations (including assignements). That's not the problem.
I agree though that in some cases it would maybe better to use some more informal approach. Activity diagrams are very slow to draw and to layout and the added value is questionable (if no automation is used later on). Regarding the statement that they are "clumsy" - you can always overcome this problem by a nice structuring and hierarchical breaking your model in several levels (as single activities can contain whole diagram inside them).
Maybe a mix would do the work - outline the main steps of the algorithm, maybe main decisions, loops, invocations, whatever is importang for you. Later add detailed description of those single activitis: using pseudo-code, natural language or even another embedded diagram (states, activities).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
If I use include or extend, will I have to use the same primary actors for those extending or included use cases? (In the screenshot: Could AddProspectiveIngredient have a different primary actor than CreateRecipe? Same question for include)
EDIT: I don't think the question is asked broadly: If I use include or extend, will I have to use the same primary actors for those extending or included use cases?
I agree, as this was one of my first questions on Stackoverflow, that there is some unnecessary boilerplate in the beginning. If that is the case, I can edit my question to keep it open. I am still hoping for someone to stumble upon it and provide me with more knowledge or sources.
If I use include or extend, will I have to use the same primary actors for those extending or included use cases?
Extend means that one Use case is a variation of another one. It is the definition, sorry. So, I am not sure you really meant it, but different variations of activity can be easily conducted by different actors.
As for include, it is not so simple. One behaviour is inserted in another one. It is some variation for generalizations for use cases.
So, if behaviour A includes B, and actor X is connected only to A and actor Y is connected only to B, that means, that Y really makes A, too, only not all of it. X has all behaviour of Y and some additional behaviour. And that means that X is derived from Y, or X is a subclass of Y.
Simply, if you have different not-tied actors for A and B, you have simply mistaken. They ARE tied.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm working now on a big system that consists of many subsystems , each subsystem depends on the other. I wrote a usecase for this system , but I note that I have many processes in my usecase ( more than 40 processes ! ) . it looks like this :
Group subsystem:
add Group.
remove Group.
join to Group.
upload file.
create poll.
remove file.
remove poll.
write post/topic
close post.
edit post.
....
Messages Centers
send message
view inbox
read message.
and so on ..
this is a screenshot, just to know that is a large usecase :)
http://farm2.static.flickr.com/1308/4691773979_4c5a30f26c_b.jpg
each user interacts with these processes .
How can I reduce the number of these processes?
Is it possible to divide the usecase processes into many pages?
I'm not sure of what you meant by dividing it into many pages but you can certainly divide it into multiple use cases, or multiple subsystems... but is it worth it?
Use cases, as far as I know(which isn't much), are used to show clearly what kind of interactions an user can make with a system, or even a system with another system. It is possible to produce a comprehensive use case with only one system having all these options, but it is also possible to do it while separating everything into smaller subsystems.
I would suggest you use whatever you're more comfortable with, as long as whoever need to see that diagram can have a clear idea of how each actors interacts together.
Furthermore, if you're working on uses cases, chances are you've made a package diagram/list before. If you did, you could simply do one use case for each package.
Your terminology isn't quite right.
From the picture, that's not ONE use case.
That's dozens of use cases. Each oval is a separate use case. Each box is a separate system. You're showing 7 systems with 32 use cases.
Read this: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
I don't know what you think a "process" is. Guessing from your picture, each thing you're calling a "process" is a use case. An actor interacts with the system to create something of value.
Since you've got the terminology wrong, it's difficult to say if it's "normal". It is quite common, however, to get the terminology wrong.
It is possible to divide in several pages. You can divide the diagram according to the actors. So you can have one actor and all use cases associated that that actor in one page.
Try to analyze if its necessary to include all the use cases in the diagram, but of course this depends for what and who are you ding this diagram.
You should group your use case. For example create a use case "Manage Group" which would include the 3 use cases:
add Group.
remove Group.
join to Group.
You can then choose the granularity of your view to show details or not.
See other examples here:
http://askuml.com/files/2010/06/yuml-use-case-diagram03.png
http://askuml.com/files/2010/06/yuml-use-case-diagram02.png
taken from http://askuml.com/blog/yuml-use-case/