I'm trying to model some requirements and I saw some examples in the web with use cases generalization, but the UML 2.5 standard review doesn't say anything about generalization in Use Case Diagrams, or I can't find it.
So, is generalization supported by standards?
Since a UseCase is a Classifier, they can be generalized. The UML 2.5 spec contains an example of this in Fig. 18.11 on p. 686 (the "ATM Services" example).
Tricky.
While the Generalization relationship is defined as going between two Classifiers, and a Use Case is itself a specialization of a Classifier, the semantics of the Generalization relationship are primarily focused on Features (eg Attributes). These are inherited, but relationships are not.
On the other hand, the UML specification itself includes an example of use case generalization (2.4.1 Superstructure, fig 16.7, p 609).
Back on the first hand, the same specification omits generalization in table 16.1, "Graphic nodes included in use case diagrams" (p 611-613), but does include the two main intra-use case relationships; Extend and Include.
On the other hand again, the same table includes Actor but excludes the Association between Actor and Use Case.
Sadly, the UML specification is in many respects a horrifying mess, and the 2.5 version is in part an attempt to rectify this.
On balance, I would say no - you can't generalize between use cases.
I don't know if use case generalization is "supported" by an official UML standard. But
it is supported by Kirill Fakhroutdinov's online book (a site that I personally use as "standard" reference) at http://www.uml-diagrams.org/use-case.html#abstract-use-case
it is supported by the Agile Modeling online book at http://www.agilemodeling.com/essays/useCaseReuse.htm#InheritanceUC
it is supported by the Sparx Systems Enterprise Architect tool
it is supported by the Modelio the open source modeling environment tool
So my conclusion is that use case generalization is supported just enough and practically you can use if you need it.
But more usual way to express that one use case is specialization of another use case is (IMO) through the <<extend>> relationship. See http://www.uml-diagrams.org/use-case-extend.html and http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html (and Wikipedia) for some more detailed discussion
As gwag has mentioned, generalization/specialization is indeed included in the use case spec. What's more, there are plenty of situations where it is useful. Here's an example, from this page:
Related
Is use case narrative part of the UML?
A textual description of the business event and how the user will interact with the system to accomplish the task.
First of all, UML means Unified Modelling Language. It is a language which helps in designing and modelling software systems. So use case is not a part of UML. UML is a tool that helps to represent Use Cases (Among other things). And Use Case Modelling is an approach in requirement engineering for understanding and describing the functional requirements of a System.
It can be both narrative and graphical. Textual representation part is called use case specification while the graphical representation part is called Use case diagram.
So what is a use case? A use case is a summary of scenarios for a single task or a goal like "pay bill" in the above image. And a Use case model typically consists of several use cases. It helps to provide a clear picture about the external actors (both users and external systems),the functional requirements of the system and the relationships among them which in turn leads to a better design.
I'm going to assume that you mean "use case narrative." That given, the short answer to your question is "no."
A "use case narrative" is a document that describes the entire behavior of a use case. The UML doesn't define documentation methodologies specifically, so this isn't part of the UML specification.
The UML community has yet to build any sort of consensus on a term for this document (and, indeed, exactly what it ought to contain). Nipun Sampath, in his answer, calls it a "use case specification," for example, and muszeo calls it a "textual description," which, of course, it is.
The behavior of a use case would be modeled in UML as an activity diagram. So, an activity diagram is a diagram of a use case narrative.
For more information on use case narratives, see this post.
I believe you mean Use Case, rather than User Case. The description you give (textual description of steps to accomplish a business task using a system) is broadly what Use Cases are about.
To be clear, a Use Case is a kind of functional requirement; namely a description of a process that a person and/or system (role(s)) performs with information to accomplish an objective that has business value. With Use Cases this specification generally starts with a model ('blobs on a page') which illustrates the process, system and actor (role) context, with a textual description and/or supporting models (e.g. Activity Diagrams) to express the steps of the process. There are other ways to express functional requirements -- User Stories and BPMN process charts are two other examples that achieve the same thing but in different ways. You may be confusing Use Cases and User Stories, perhaps.
I'm learning software engineering at school and right now we're focusing on data diagrams. That is, Objec Classes, associations (and multiplicities), Ternary (or in general N-ary) assocciations, aggregation classes and so on.
I've been taught that we are using the UML standard, but as far as I can see, most UML editors I've found don't even support (or do it very poorly) the UML concepts I am using, I find myself using text labels all over the diagram to express almost anything, and I can't even define an N-ary association properly. I can draw a diamond from the flow-chart drawing part and draw some arrows, then define multiplicities with labels, but I find that unprofessional.
So, I've got two questions: Is UML what I've been taught? Does it have a more specific name (I was told they were called data diagrams).
How can I check that I am using the correct tool and that it is really UML what I study?
n-ary associations are UML. But they are not so often used really. Most of associations are one-or two-directional binary ones.
DATA diagrams are NOT UML. But the standard allows to use class diagrams for showing tables and their relationships. If you use class diagrams, it is UML, if data diagrams, it is not.
Multiplicities are UML. You should define them as attributes of association.
As for arrows, UML standard allows not to show them. But of course, they should be again set as attributes of association.
It seems that you use diagramming tool without UML class diagrams support. And youu need rather a modelling tool. Try VP-UML - it has free community license, including all types of UML diagrams. Or if you can install Eclipse, it has many UML plugins. The largest are EMF or Papyrus. They are free. Green UML is for starters.
I understand your troubles - many "UML" courses do not teach real UML. Many widely used tools have errors in UML realization. Some of them (IBM) are very far from the standard. The best place to check if you are on the right way, is the OMG UML 2.5 standard. It is beta2, but the content is virtually equal to the current 2.4.1, and is more easy to understand. (the current change has merely to simplify the documentation)
Back in the Dark Ages (mid-1980s), I used Data Flow Diagrams from Structured Analysis a fair amount, and found them very useful.
My current employer loves UML. I normally use BOUML, which doesn't do non-UML drawings.
What is the UML drawing that corresponds to the Data Flow Diagram?
If there isn't one, what is the recommended UML diagram to present the corresponding data?
Probably the closest thing is the activity diagram. It's not quite the same; more influenced by flow chart than dfd. However: you can do some of the useful things in DFDs, e.g. ADs do support concurrency and differentiate control flow from dataflow.
More details on comparisons & differences in this question.
[fwiw, I still use DFDs: they're simpler and more elegant in many circumstances]
hth.
UML 2 has a very good analogue to a data flow diagram:
the "information flow diagram".
Information flow diagrams are explained here:
https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Note that UML 2.5 has information flows and information items, but the term "information flow diagram" is not part of official UML 2.5 diagram taxonomy. So formally, you just create a class or component diagram with lots of information flows in it to obtain your "information flow diagram".
I do this all the time, using information items of UML to represent my data.
There is no equivalent model in OOD. The emphasis on DFD's is data separated from the function. This is most helpful when dealing in a procedural way. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc.
I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better.
I too am looking for a diagram that could do this sort of work. In Go structs are used intensively which are basic data types. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on.
My advice, is that if you're doing OO code, then use OOD. They map better, and do help in the thinking about a system. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. Once you're in the zone with thinking about objects then the OOD methods work fine. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. A good book on this is "Object Thinking--David West"...it helps to think about objects first. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. This is a form of coding hell which I have stayed clear of for many years.
If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This will decide which diagramming tools that should be used, and how you are going to analyze the system.
Recently there have been shifts in Java and c# to provide functional programming techniques. These I have discovered don't fall into either category of programming (OO or procedural). Trying to map functional programming code into an object is a nightmare.
I am sorry I haven't provided an answer, but it depends on what code you are writing.
There is no direct analogue, since UML emphasises OO design wheras DFD comes from structured systems analysis and design (SSAD). In UML a number of diagrams, specifically those in the with interaction diagrams group have characteristics that might model elements of data flow and processing. A Communication Diagram can be used to reflect most aspects of a DFD in general, while a sequence diagram may model specific sequences of flow. If you wanted to suggest DFD semantics then you could use stereotyped objects for data process and data store, and use actors for external entities.
It may be worth noting that Sparx Systems Enterprise Architect, while primarily a UML tool includes DFD as an extension.
Similar diagrams would be:
information flow diagram
communication diagram
sequence diagram
Theoretically, new diagram kinds can be defined in UML, optionally extending of one or more conventional diagram kinds. The canonical diagram kinds defined in UML are essentially defined as a part of the UML metamodel itself.
Formally, a definition of the UML metamodel is provided in the UML specification published by the Object Management Group (OMG), as well as the corresponding meta-metamodel defined of MOF - to which there is also a corresponding specification - moreover as accompanied with the formal OCL specification, as with regards to definitions of constraints in UML models in applications of the OCL language in UML - and then there's the XMI specification, as with regards to specifications for how UML models may be stored in machine-readable format.
Ostensibly, all of these specifications may be combined for application as though "Under the hood" of any single framework for UML modeling - whether in applications of the Ecore subset of the UML metmodel, or in canonical UML.
Reviewing a short academic presentation about Data Flow Diagrams -although somewhat in departing from formal definitions of UML diagram kinds, but nonetheless in a broader context of applications of the MOF meta-metamodel - perhaps the canonical BPMN metamodel - in its conventional, graphical abstract syntax - perhaps BPMN may serve to provide something of an analogy to Data Flow Diagrams?
Of course, modeling practices may vary by vendor and by application environment.
I consider a Data Flow Diagram as a Sequence Diagram, with Data Producers and Data Consumers creating, using and destroying Data objects by means of synchronous and/or asynchronous messages.
I use Enterprise Architect 'Dynamic View' Analysis diagram.
Control = Process
Information = Data Store
In many ways their Analysis diagram is much better than a data flow diagram, as you can also show events in the form of sending and receiving and there is a process symbol too but I prefer Control. It includes object and decision.
How to represent Repository pattern in UML?
Is there any stereotype that can be used to describe repository pattern? I am using Enterprise Architect to create diagrams. I specifically looking for class diagram representation.
According to Martin Fowler, P of EAA, p. 322:
(However, you must have already found this since it's the first hit on Google.)
Based on this example (and the text from P of EAA), this roughly translates to the following DCD:
jensgram has already provided an answer on how to represent the pattern as classes.
When it comes to using patterns in EA, you can quite easily create them yourself using Save UML Pattern under the Diagram - Advanced menu. This saves an XML representation of the pattern.
You import the pattern for use in your project either using the Resources window or by creating an MDG Technology (more complex, but a much better alternative for medium and large-scale deployments).
Unfortunately, the one UML diagram type where EA does not support pattern creation is the sequence diagram.
What are the steps to be followed when we start UML diagrams for new features or requirements?
I need the entire steps like
Identify the actor,
Identify the use cases,
like this etc....
What you need is some sort of methodology.UML doesn't come with any, because it is ment to be methodology independent. However, the authors of UML have created some methodologies, which heavily use UML. One of the methodologies, which is free, is Unified Process or UP for short. Try to look at that, there are plenty of books, which discuss UML and UP at the same time.
Create a simple model of the existing system, and a detailed model of the area you plan on working in. There are a number of different types of diagrams (activity, sequence, class, etc), you should use the ones most appropriate for the complexity of your system and its interactions with other components, systems, and people.
This is a very board expression. In general, I would start with Use Case diagrams and go from there. As Gabriel pointed out, there are entire books written on this and there is no one right answer. My personal favorites for Use Cases are:
Advanced Use Case Modelling
and
Writing Effective Use Cases
Take a look at Craig Larman's book "Applying UML and Patterns". That describes very accessibly how to use UML to tackle a problem (Use Cases, Class Diagrams, ...).