I have two components A and B. I want the model to show that they both <<include>> and <<use>> the third component. Which picture is correct, the top or bottom one?
Often, when you have two possibilities in UML, both are correct. But not here. I am afraid, both are bad.
According to the current standard 2.5 :
A Usage is a Dependency in which one NamedElement requires another
NamedElement (or set of NamedElements) for its full implementation or
operation. The Usage does not specify how the client uses the supplier
other than the fact that the supplier is used by the definition or
implementation of the client.
So, in UML <<use>> means "must have for some use". And notice, it is absolutely independent on the containment/inclusion relationship. The object we are depending on can be even contained, for it is not said we need it for creation of the dependent object.
We can use a component that belong to anywhere. But in the including (top) diagram we can't show the usage. So, it won't pass.
As for the second sort of relationship, including, there are greater problems here.
The standard UML component diagram has no "include" stereotype. But it is allowed to use elements of other diagrams.
But the component is not a class, it is an object. So, your component C simply cannot belong to both A and B. The other diagram fails, too. And if you want to have two different objects/components based on the same class or package, absolutely different diagram appears.
So, either A or B has its own instance of C and uses this instance. It is clean, without peeking into the other component.
If you use the tool that has not that containment connection, use the "include" association from the use case diagram.
I have also a strong suspicion that you could need not Component, but some different diagram, for your wish to put one box into different ones is unnatural.
Related
I'm working on a project where I'm using an SDK that provides things I need via some classes. I've named these ProviderProvider and Provider, that grant access to OneThing that is an IThing.
An example is shown here
.
My question is: What is the correct (or best) way to show that the Model provides the list of OneThings to the View through those classes?
Do you show this explicitly as in my example, by drawing a dependency arrow from Model to OneThing? That doesn't seem right to me and quickly becomes visually cluttered.
Do you not explicitly define that relationship, but is it simply implicitly defined through the other relationships?
Do you define that relationship semi-explicitly through attributes, notes or some other way?
What relations and attributes should I add/remove specifically and why?
You already have the implicit relationship since you use this class as a type of data returned by Model so you do not need to add that relationship explicitly.
It may be useful though, especially for classes that are core in the system, to add a diagram with dependencies only. Then you don't care about relationships between other classes, you only show on one diagram all classes that depend on the core one (it may be even more than one diagram).
One hint - in Case tool (like EA) even if you don't intend to show the relationship on the diagram since it is indicated implicitly it is still good to create the explicit dependency and just remove the arrow. This will support the traceability through tools like traceability matrix or dependency tree.
In my previous question I was trying to achieve the idea of ordering the classes. Although the example I presented wasn't appropriate.
So here is the situation I want to ascribe by UML class diagram:
In ODT document I have something called figure. The figure is comprised of two atomic elements: image and title(of the image). The standard allows me to put the title, either on top of the image or bellow the it. Although In my application the title will always be beneath the image like this:
So in my case I want to submit the (more specific) information that the title must be beneath the image (although the standard does not obligate so). Thus I came up to the idea of making order in my class diagram (this is first, then this, then this, etc...). Because in my case that matters.
Here is my despaired attempt:
Is there any approach to present that information through a UML Class Diagram?
In the UML meta-model, there are meta-elements called Class and Property. An instance of a Class meta-element (e.g., called Figure) may own instances of a Property meta-element. Each instance of a Property meta-element has a type (e.g., Image and Figure). Both of the instances of the Property meta-element in your model are unnamed, which, unfortunately, makes it difficult to refer to them. Nonetheless, all of the instances of the Property meta-element that an instance of the Class meta-element owns are ordered. When you create a property in a UML tool, you generally add it to the end of an ordered list.
In your diagram there are two unnamed properties that are already ordered (implicitly, based on which you created first in the tool). This order can be seen and changed in a UML compliant tool. Here is an example UML model:
I strongly recommend you name all your properties, as I have done in my example model. For example, I named them title and image, starting with a lower-case letter. Among other benefits, that way you can see which is which more easily when you reorder them.
Here is a specification window in a professional tool called MagicDraw, where you can drag properties into the order you like:
You could change the order to say that the image comes before the title.
P.S., in an analysis model, if this ordering is a rule that's important in the problem domain, I would actually show an explicit association between Image and Title having association ends called something like comes before and comes after.
I have a class (let's call it "CLASS") in two different EA diagrams.
CLASS is the same object in both diagrams.
I want to change the attributes order in one diagram without it automatically changed in the other diagram too.
Any ideas?
Thanks.
That depends on what you want. Do you want to show different aspects of the same element in the two diagrams then you can play with the Feature and Compartment Visibility (Ctrl-Shift-Y)
If you want to show different elements, but one starting as a copy of the other then you can Copy the element (Ctrl-C) and Paste as duplicate (Ctrl-Shift-V)
You can not do that. And it does not make much sense to hide single attributes or methods of a class in specific diagrams. Either all or nothing (to show just the class). EA has a way to hide single stereotyped element parts for a whole diagram. But that's not what you're looking for.
Maybe you can explain WHY you want to do that.
No, you can't do that. As you note, it is the same element (avoid using the term "object" here; object is actually a type of element in UML, just like class, component, use case, etc).
Attributes can either be sorted alphabetically (by default) or in some custom order which you set manually, but EA stores this order with the class, not with the diagram. In other words, the attributes of one particular class will always be displayed in the same order in all diagrams.
New users often find this type of issue confusing or even frustrating, until they realize that a diagram is only a visualization of the underlying model data -- it is not a drawing. This is why you don't do search-and-replace in models: you make a change to an element in one place and it is immediately reflected wherever else that element is shown.
The only way to show two different attribute sort orders is to make a copy of the class, but then of course it's not the same element anymore.
Can someone explain in what's the difference between elements marked in diagram?
I think it only depends on how many interfaces we want to connect. Am I right?
http://i.imgur.com/ZnW02Ar.png
You are not right and the diagram is syntactically incorrect.
Let me first explain the concepts and their meaning:
Dependency between components exist on the definition level (top part of the diagram). They can be drawn between the required and provided interface, between a component and interface or even between two components (no interfaces), depending on what we want to show.
Assembly is completelly different relationship and it does not make sense on the definition level (between components). It's because it is a special kind of link - a relationship established in run-time between two instances of a classifier (here - component, the lower diagram).
So, in summary we could say that a dependency between two components on classifier level expresses a potential link or assembly between the corresponding instances in run-time.
On your example there are several syntax errors (if you could compile it, it would give you this report :)):
Assemblies "Item Code" and "Customer Details" cannot connect two components (only their instances)
Dependency between Order and Account is in wrong direction (should go from required to provided interface with the same name)
Note: I must say that this diagram looks extremelly suspicious even semantically. You should probably reconsider it.
I have a CU that extends another CU, let's say: Add inventory extends Add product, so in one product interface I need to use fields from inventory CU, how I can described this in a CU?
"Extends" means that during the "execution" of the extended UC, execution of the extending UC has been voluntarily invoked by an actor. Each UC is described by several scenarios. Scenario is decribed as an ordered sequence of "steps".
You have to specify so called extension points - steps in the scenario(s) of the extended use case, in which the Actor can invoke the extending UC's execution. It can be a single step or a range...
You can think of the extension point as of a method with parameters, tmplemented in the extending UC and invoked by the extended UC. These parameters could be these fields, you need to "pass" to another interface.
In my projects I always "back up" the my case model with the domain model (class diagram) and use elements of it in the specification of the UCs (preconditions, postconditions, scenarios, extension points).
UPDATE (after the comment)
UML does not define the concrete format of the use case specification, it only defines the concepts and their semantic meaning. A UC can have so called Behavior, can extend another one (or be extended), has Extension points.
The way you define Behavior and Extension points are your own choice.
So, in my example:
Behavior of both UC is defined as a textual sequence of steps, as performed by System or User (alternative is a state machine, activity diagram, even user interface prototype)
Extension Point is defined as a step in the sequence and additionally described by this "method" signature, to illustrate the exchanged information
Remember that UCs show INTERACTIONS beetween the System and the outside world. For them is the System kind of black box. Conceptual model I've used here is therefore NOT a DB or system design, but rather a conceptual, implementation-agnostic view on the entities used by the app. They can even be mapped on 2 different systems on the implementation level!
Relationships between the UCs similarly exist purely on the user-system interaction level of abstraction, and DO NOT BY ANY MEANS reflect some internal system dependencies!
(note added after Gangnus's comment)
(Scenarios and concepts are fully invented for the example sake)
UML standard 2.5, p.680, definition:
An Extend is a relationship from an extending UseCase (the extension)
to an extended UseCase (the extendedCase) that specifies how and when
the behavior defined in the extending UseCase can be inserted into the
behavior defined in the extended UseCase. The extension takes place at
one or more specific extension points defined in the extended UseCase.
Extend is intended to be used when there is some additional behavior
that should be added, possibly conditionally, to the behavior defined
in a UseCase.
I wouldn't call what you are describing an extension. Inventory instance is a container that has Product instances as items. So, Add Inventory is a behaviour that depends on existent products, but not on ways of their adding. So, if you use correct OOP strategy, Add Inventory is absolutely independent on Add Product behaviour. They are both independent behaviours.
Yes, they work on structures, that are dependent and associated, but structures mostly are described in other diagrams. So, normally, these two behaviours are two different independent UCs.
On the other hand, according to standard, you can mix elements of different diagrams, and if you MUST show that intermediate dependency on UC diagram, you can draw there appropriate classes(Product and Inventory), connected by an association. Your use cases will be connected to these classes by arrow "dependency" - - - - - - >
Notice, that Use Case "add Product" and method "addProduct" in some class are absolutely different things. The first is behaviour, described in manual, with participation of user, and the second is a piece of code. The first is the task and the test for the second - that is a realization. So, beware, put classes into Use Cases only if you understand what you are doing VERY WELL, it is not the way for starters. Minimally, reread the Use Cases chapter of the UML standard before. Personally, I would show classes in separate classes diagram here. It is much more easy way.