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).
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 1 year ago.
Improve this question
I am coming from the Embedded Systems domain with more than 3 years experience.
In my current project, at the beginning, I was only responsible for only software development and the Team consisted of 3 people.
But, as time passes, hardware eng. and project lead eng. left the job respectively. So far, the project moved with a zero- architecture documentation to give an output as fast as possible. Later, new project lead took over the project and started from the begining with applying V-model. We started to create product specs->HLR->DLR on EXCEL. But now, He left the job too :). Now, I am alone on my way with nearly 700 pieces of well written product requirements. Anyway, I started to gathering and classfying requirements as non-functional, functional, business, stakeholder etc. As gathering non-functionals, I also classified them scalability, performance, regulatory, design contrains etc. So far, I did not draw any use-case. Please verify me here, what I know is that input of use-case are functional requirements. So, I created a use-case cards and now I am planning to write use-case cards for each functional requirements then also write a sequence diagram for each use-case card. Now till here, am I going right ? Does notations used in use-case such as include, extend etc. help me to create class diagram ? Is this also right way ?
Can classes be derived from use-cases?
When Ivar Jacobson invented use-cases he aimed at a development method that would be driven by the use-cases and allow to methodically derive the implementation from the use cases. That was his vision end of the 80s. His first attempt was called Objectory, which was bought by a larger company and lead to Rational Unified Process, which was generalized to be less proprietary into the Unified Software Development Process (Unified Process, or UP in short).
There is in particular one practice that allows to translate a use-case into classes: the Entity Control Boundary approach: use-cases become «control» classes, links between use-cases and actors become «boundary» classes, and «entity» classes are created for the business objects identified in (or derived from) the use-case narratives.
Once these first candidate classes are modelled, further work is undertaken during the design and classes may get reorganized to best fit into the solution (e.g. several boundary classes are regrouped for designing the GUI, and may thereafter be decomposed into UI elements, etc...).
But is this the best approach in your case?
UP is iterative and incremental, and fits well into modern version of the V-model, since the early iterations of the elaboration phase aim to stabilize the architecture and teh components (or sub-systems).
However, this may be a very time-consuming approach, especially considering the huge number of use-cases that you have. If you look at all the questions that modelling a use-case usually raises, especially if you add «include» and «extend», you risk to spend a lot of time (more than 300 days?) to draw robust use-case diagrams. And then, using ECB, your requirements might be outdated before you finish the design!
Alternatives
On the other side, some non-academic authors claim that every system has 3 to 5 really main use-cases: as a user I don't have 700 goals for using a system. So you'd better identify these and see how they relate. It's probable that many of the other requirements are far too detailed and could easily be assigned as additional information for the main use-cases.
In a similar thought, Ivar Jacobson has adapted his method to the current software engineering reality, with the use-case 2.0 approach. Don't misunderstand me, the UML would still be the same, but ECB no longer appears (modern frameworks influence much more the design of the boundaries than the use-case model, and entities are modelled using more focused approaches, such as DDD).
The idea behind use-case 2.0 is to slice the main use-cases into several smaller parts and start to develop something that makes sense for the user and can then be further refined.
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 5 years ago.
Improve this question
I have a scenario which involves a vending machine and then asks us to create to "model the problem domain". I've covered modelling very loosely and was hoping someone would clear this up.
From research it looks like a problem domain is just a domain model which in turn is pretty much a UML Class Diagram.
The examples I've seen look they're almost database schemas with a customer entity, order entity etc etc.
I'm just not sure what the differences are exactly.
So I just wondered if I was on the right track and would anyone mind elaborating on this or perhaps pointing me towards a concise definition. Thanks.
The "problem domain" is just the stuff you're interested in. In your case, it's all the stuff a vending machine does, and who interacts with it.
It boils down to a collection of use cases, which can be diagrammed in a use case diagram. What does the vending machine do? It takes coins from a buyer (the actor), gives change (maybe...so make sure you understand "extension points"), spits out stuff (always, because we aren't in the real world), and so on. Then maybe you can get creative with a different actor. A maintenance person takes out money, adds change, fills up the machine, runs a diagnostic stack, whatever. Each one of these is a use case. Put them together into a use case diagram.
If you want to go into detail about what each use case does, then use an activity diagram. One for each use case.
Any system (software or not and modeled or not) has structural and behaviour aspects.
The structural aspects are non-time bound aspects of your system, such as which classes your system is made up of, their associations and dependencies, how they are divided into subsystems, etc. Most of these elements are often referred to as classifiers.
The behaviour aspects shows how these structural aspects collaborates together over time to achieve the goals of the system, such as methods, state machines, workflows, use case realisations, etc.
The structural and behaviour aspects are what you specify when you are writing your code or creating a model.
Objects, are by definition instances of classes. This means that objects are the "things" that actually exists when the system executes. Hence, you do not program an object; you program a class, which when executed, is instantiated into one or several objects.
However, in many modelling languages (but not common in programming languages), you can also model specifications of scenarios, which show specifications of objects and how they interact, for example in UML you may create an object diagram, showing one example of how the system of objects (i.e., instantiated classes) might be structured and collaborate during execution.
Now, a system always strives to a achieve one or several goals for it's surrounding. The surrounding is made up of persons and/or another systems (actors) interacting with the system. This "surrounding" or "background", on which the system is situated in and makes sense in, is often called the "domain".
These "actors" have a "problem" they would like that the system helps them to solve. When this problem is modelled, one calls that model the "problem domain model" for the system. It states the logical structural and behaviour aspects of the problem domain, without stating how it is going to be implemented in a specific implementation of a system. I.e., it is not referring to implementation aspects, like Java, SQL, primary keys, transactions, reflection, angular, etc; it is instead focusing on the core structures of the domain, like Orders, Parties, Contracts, Products, etc.
The problem domain model is one of the most important "contracts" between the system developers and the persons paying for the system or being owners and users of the system. It makes it possible for you all to understand the problem to be solved in the same way and are makes sure that you all are using the same concepts to reason about it. Since it, by definition, is not a technical artefact, you should describe it using as simple notation (but still stringent and crisp clear) as possible so that also non-software professionals could understand and agree on it. Class diagrams (stripped from all technical details) and use case diagrams are two notation techniques available. But also object diagrams and activity diagrams could come in handy.
If you are interested in this, I deliver a course in advanced concept domain modeling on Udemy. Here is link and 90%-off code: https://www.udemy.com/get-your-concepts-straight/?couponCode=CONCEPTS29
Regards
Per
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 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 5 years ago.
Improve this question
I'm referencing a book by bennet, s et al (2002). Object-orientated systems analysis and design 2nd ed. McgraawHill:Maidenhead.
In the book when describing requirements analysis Bennet refers to three types of 'analysis class stereotypes' as a way of breaking down use case diagrams into defined classes.
The first two seem fairly straight forward : an boundary class is the terminus between the user and the system, or the system and other systems that it relies on. An entity class is the 'information and associated behaviour of some phenomenon or concepts such as an individual, a real life object, or a real life event' i.e. the data that you're trying to model or store, such as a person.
Finally, there are control classes which 'represent co-ordination sequencing, transactions and control of other objects'. This definition isn't as clear as Bennet states:
"meanwhile, the boundary class represents interaction with the user and the entity clases
represent the behaviour of things in the application domain and storage of information that
is directly associated with these things"
This rather begs the question what exactly is an application or software domain in this context? How does the control class fit in with these other two definitions?
I think this offers a best case solution :
http://epf.eclipse.org/wikis/openuppt/openup%5Fbasic/guidances/concepts/entity%5Fcontrol%5Fboundary%5Fpattern,%5FuF-QYEAhEdq%5FUJTvM1DM2Q.html
Entity objects represent the persistent information tracked by the system.
Boundary objects represent the interactions between the actors and the system.
Control objects are in charge of realizing use cases.
Modeling the system with entity, boundary, and control objects provides developers with simple heuristics to distinguish different, but related concepts.