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 3 years ago.
Improve this question
I'd like to clarity something:
As I understand it, the purpose of object diagram is to show relationships among objects. The sequence in which these objects interact is not relevant. Is this correct?
If possible, could you provide general comments on the diagram below:
Yes, the goal of an object diagram is to show the relationships between a set of objects (i.e. the links/pointers between them).
The object diagram shows a static snapshot of the system. Objeect diagrams are not useful to show the sequence of events they exchange (not even those that provoke the system to reach the current state represented by the object diagram). You have the interaction diagrams for this. In particular, the collaboration diagram, looks very similar to an object diagram but the "lines" in it represent method calls, not links
Comments about diagram:
If your purpose is to show interaction between your objects( object sending/receiving mesages) you should use Sequence or Communication Diagram. Actually the diagram you draw is a kind of Communication Diagram NOT an Object Diagram( in terms of UML jargon).
IN UML Communication Diagram you can also label methods calls( object interactions) to show their orders.
Sequence diagrams and Communication
Diagrams show same things with
different focus ( From a pragmatic
view point, they are same). Sequence
diagram emphasize order of messages,
Communication Diagrams emphasize
collobrators more clearly.
Object diagram rarely used and they show static relationship between(
there is no time) objects. They
generally used for making Class
diagram more concrete when the static
relationships are complex in Class
diagram.
Related
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 2 years ago.
Improve this question
I have a project which requires me to create a UML Class Diagram. What I have from the previous tasks in the same project is an ERD using UML notation. Also worth noting, this project is related to database and does not have much coding in it, so creating a class diagram based on other coding is probably not the main objective here.
I tried Googling "how to convert erd to class diagram" but all the search result only shows how to convert ERD using Crow's Feet notation into UML Class Diagram.
I also Googled about UML notation ERD, and found this site which said,
In UML notation, entities are modeled as a “class” with an Entity stereotype.
Does that mean that ERD using UML notation is the same with UML Class Diagram? If not, what are the differences?
Note: I know there are already questions regarding difference between ERD and Class Diagram, but I am asking specifically about ERD using UML notation.
In Chen's original ERD notation attributes are ovals connected to their entity which is represented with rectangles, which can have relationships represented with losanges. This resulted in very large and complex diagrams, due to the many attributes.
Crow's Feet notation became therefore more popular since it allowed to express the same models in a more compact way, grouping attributes together with their entity in the rectangles, and using an intuitive visual representation of cardinality. But now that UML is the Lingua Franca of modellers, it's tempting to look at other alternatives.
Your linked source suggests a very natural mapping of the core ERD concepts of entity, attribute, relationships, into the UML class, properties and associations:
(...) entities are modeled as a “class” with an Entity stereotype.
(...) attributes can be arranged in a box style (...)
Relationships are shown as a single solid line connecting the two entities. The minimum and maximum cardinalities are shown along the line and verb phrases can be added to completely characterize the nature of the relationship.
And indeed, the most suitable notation for an ERD diagram in UML would be a class diagram.
Beware however of the subtle semantic differences. For example:
in UML any property (what your mapping relates to attribute) could be modelled either within the box (as what you call an attribute) or as a related associated class (as what you call an entity) with an owned association end.
UML classes are expected to have behavior (it's because of the underlying OOP concepts). Having classes without behavior can be misunderstood by UML reader as a bad design (anaemic domain model). The «Entity» stereotype is not sufficient to disambiguate, since it's in general associated in the UML context with the Entity-Control-Boundary paradigm, which also expects entities to have behavior. Maybe you define an UML profile using a less ambiguous stereotype such as «Data-Entity»
Your linked source is misleading about Crow's feet transposition in UML: you can add a verb phrase on an association in UML, but in the middle oc the association and with and with an arrow head next to the text to show the direction of the reading. In UML, the text at an association end is something completely different: it's called "role". The equivalent in an ERD diagram would be to include an attribute with the role name in the entity at the other end (and which would correspond the the primary key identifying the other entity).
A better source about how to note ERD concepts in different notations can be found in the side-bar of the Wikipedia article on ERD.
Edit: A mapping algorithm is proposed in a more general article "A framework for transforming structured analysis and design artifacts to UML": it mentions that in addition, ERD diagrams sub-type relations should be transformed in UML generalization under the condition that it's an IsA relation.
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 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 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
Looking for a bit of a steer on "how things are done" with regards to defining requirements for a software based project.
I'm fully up to speed with what goes into a requirements catalogue and how useful UML modelling can be.
My question, how are the two linked? Should you write out requirements into the catalogue for any requirements you model using UML - essentially duplicating requirements?
For example,
- A user wishes to source a "product" from a supplier
- To do this they will enter their product details into a "breifing" form
- In this scenario I'd look to use a class diagram to list out all the "briefing" fields (shown on the briefing form) against a "product" class
But, how do I tie those requirements back to the requirements catalogue? If they're not referenced there how will a developer know those requirements exist?
Any help greatly appreciated!
Thanks,
Dan
You should use an Use Cases diagram to make the bridge between requirements and UML.
You could then explicit relationships between your classes and each use case.
A developer can see a particular class is linked to one or many use cases (requirement).
Some modeling tools allo wto include requirements into your UML model. Then you have an explicit link.
For example: http://www.sparxsystems.com.au/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf (see p. 16)
Otherwise you may export your diagrams and include them into your catalogue document.
Forming the requirements catalogue and having elicited and analysed your audiences requirements up to the point of formal signoff, based on the needs of a project you UML diagrams would normally make reference to a working of functionality or a process which you captured, process workflows/activity diagrams are sound for stakeholders to visualise how there internal processes work, use cases, class diagrams, sequence diagrams etc are more useful for development and QA teams during the design/development phases for devs and qa's.
For each requirement just make reference to the UML diagrams through the use of the requirements ID. But as mentioned earlier, ensure you have traceability between requirements and UML and vice versa,
Hope this helps
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.