I'm having a hard time understanding the difference between dependency and assembly(ball and socket) in UML component diagram.
I googled a lot and only found this relative question : uml component diagram difference between assembly and interfaces with dependency
But I don't really understand the answer to that question, I specifically want to ask :
What does he mean by "definition level" and "instance level" ? I understand that there is only one diagram, are there two ?
Whether there are two or not, can you give me a valid example which has "dependency" and "assembly" and explain why the first was "dependency" and the second was "assembly" ?
Note that I'm not asking about any particular image I found on web, I'm asking here in general, Also I want Uml 2 :) .
I prefer examples because I don't understand all the words in UML, also I prefer these examples to be somewhat realistic , that is not "A and B" but for example "Order and Person".
My goal of the question is to draw the Component diagram for our graduation project that we'll give to the professor :) .
A component is a piece of software. This is the class level (definition level). This piece of software may be installed on multiple machines, or maybe multiple instances may be running on the same machine. This is the instance level. If, in your case, each component is instantiated only once, then you only need one diagram, showing the instances. Otherwise, it would be good to have one diagram show the class level and one diagram show the instance level.
For example, there is a component called EmployeeProvider, which provides services to access an employee database. Suppose there is an instance running in the USA and one instance running in Europe. Suppose also that there is a report generator component, which only has one instance, which reads information from both employee databases. Below you can see two diagrams, one showing the class level (top) and one showing the instance level (bottom).
Related
I am trying to understand new piece of project. I am drawing UML class diagrams, but there is something missing for me in these diagrams: the creation of objects. What a traditional UML diagram can depict is how these classes are related to each other and how instances of these classes are related to other objects of other classes, but that is in the moment when they are already created. Sometimes it is not that obvious who creates who, sometimes it is totally misleading. For example objects of class A may create object of class B, but that A object just returns this B object and gives it to somebody else and doesn't hold any reference to it. And sometimes it holds (a reference or pointer). Sometimes it matters for the reader. So in fact there are two types (pieces) of information: holding and creating. I came up with my own way of visualizing this, but maybe there is something standard here? What do you think? And I don't have UML Object diagram in mind, that is not something very helpful when reading C++ or Java code and trying to understand the relation of classes and objects. And not sequence diagram also, that's a different kind of beast.
If you want to stick to class diagrams, you can use the «create» usage dependency from UML Standard Profile (chapter 22 of UML 2.5 specs).
«Create» | Usage | A usage dependency denoting that the client classifier creates instances
of the supplier classifier.
So e.g. here A creates an instance of B, and C just has a reference to B.
A type of UML diagrams show only one particular view of your system by abstracting the other aspects of a system. For example, a class diagram shows only the static aspect of the system, but not the dynamic behavior such as:
At what time an object was created
The central ideas of modeling a system is trying to deal with (or focus on) an aspect at a time, and at the same time to eliminate the complexity by forget about the other aspects of a system.
In this case, "creating an object at a particular time by who (another object)" should be dealt with behavior view, thus, we can use a sequence diagram to modeling the dynamic behavior:
You can see the Dimension of a sequence diagram in the Figure:
Horzontally, Objects Lifecycle
Vertically, Time
You might then be interested, how I can relate these models together? Will there be any inconsistencies among them? Right! if you are puzzling about this, you are in the right track!
Look! models are inter-connected each other, take an example, you can create a use case, and a use case can be detailed with a number of scenarios, then.. each scenario can be modeled by a sequence diagram, and the sequence diagram giving you the hints of what objects (and what operations and attributes in it) you need to build your systems, right?
I am studying UML. I have some confusion about realization and collaboration.
Consider the diagram (I hope diagram is correct)
"Make a call" is a collaboration. "connect to destination" is a use case.
According to the book and various resources, I read that we say "Make a call" realizes "Connect to destination".
But as far as I understand, Collaboration is a logical concept we use to group a repetitive pattern(as in design patterns). The use cases(which have their own diagrams) are the ones who implement them (indirectly, as use cases will eventually have an related class diagram. those classes must be implementing them).
So shouldn't we say that "Use cases" realize "collaboration"?
What am I getting wrong here?
The source of confusion is java, where we have interfaces, and classes which implement them. we say a class implements interface. Isn't realization same as implementation?
What adds to this confusion is collaboration diagram, which seems to have nothing to do with collaboration.
Because you first have the use case. It roughly tells what the added value of the system is. And there's also a story how this value is achieved. Now you start thinking about how the system under consideration (SUC) an realize (hence the name) this use case. So you construct collaborations where you show how the class design working towards fulfillment of the single goals in use cases. You can have multiple collaborations to either show different aspects or variants of the SUC.
Regarding your diagram: you have dependencies from Connect to destination to two other use cases. That's not correct. Use cases represent individual added value the SUC brings to its actors. So they basically can not depend on each other. All use cases of the SUC represent the total added value. Often people try functional decomposition with use cases and add a lot of include/extend dependencies. That does not lead to meaningful use cases and you loose focus. That is, you don't show the added values but stray around technical possibilities.
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 am trying to build a class diagram from use case. But I am not sure if I should include the system in class diagram. I have system as actor in use case diagram. If I include it in the case diagram can I use it without attributes....
"I have system as actor in use case diagram" - Actor can be human or non-human system external to your subject that is your whole system. For example, card payment system or buyer are actors for net stores. You can show your system in the use case diagram, too, but it will be a rectangle, containing ALL use cases - not really so much useful thing. But showing of SUBsystems can be useful.
Later you can draw a deployment diagram - if different subsystem lie on different computers. And maybe, some dynamic diagrams of how they talk to each other and actors.
If we are talking on static diagrams, your next step will be component diagram - you'll divide your system in smaller parts and show who talks to who and here already the classes of messages being sent can appear.
Later - you'll plan what packages will contain your classes and what will be visible from which. Package diagram.
Later - yes, at last we are here - you create the class diagram(s). Maybe, several - for different components. So, you are a bit too in a hurry.
Sometimes, especially, if you work with some special objects of some class(es), you need Object Diagram.
And don't forget - there are also dynamic diagrams, I have mentioned static ones only.
Can you please elaborate your question with specific example in order to get better knowledge about the scenario?
As far my knowledge, one can use the system such as any controller class which is again an actor here as class in the class diagram.
"I am trying to build a class diagram from use case"
Use-cases are a very abstract and user-centric view of the system while class diagrams are fine-grained and technically focused.
So you should not try to infer your classes directly from a UC diagram. Instead, use the repertoire UML gives you (component-, activity-, sequence diagrams etc.)
In my experience, I usually create Object interaction Diagram from Use Cases. Mostly, the nouns on the Use Cases are Classes ... In Object Interaction Diagrams, I can have clear ideas about the methods and lifespan of the Classes ...
"Object Interaction Diagrams" or "Interaction Diagrams" are usually to elaborate a single use Case ..
A simple google search gave me this link and it gives you some idea ...
http://www.cs.unc.edu/~stotts/145/CRC/Interactions.html
Is This use case is correct/proper according to UML? if not please give some input to improve it..
The ways we can look on it as the boundary value "Use Cases" can be described something as "Release Phase 1"?
Writer Module/Reader Module should be proper Ator?
alt text http://img190.imageshack.us/img190/6708/usecaseh.jpg
This diagram is telling me that there is something external to the system you are developing called a "Writer Module". The Writer needs three Use Cases, for example Initialization.
Similarly another actor needs Check Status and StackUp.
If that is what you intended to say, then this diagram works. Do you really mean it? Does only the Writer module Initialise the system? Or does the system initialise itself? Can the Reader check whether the system has been initialised, before it has been initialised? Is there another Use Case?
Small improvement: make the Use Case names match in their parts of speech. Initialisation is a "Thing", Check Status is an "Action". Perhaps Initialize System might be better? "Stack Up" not "StackUp", be consistent.
Normally the reason you group the use cases using a box is to show what system is helping meet or realize the use case. It is formally known as a system boundry ("The system you are building". Normally the systems, modules, etc that are actors are more black box, existing, or use only. If there are many new or modified systems this definition gets confusing.
The other comments are semantics of what you are showing, but are not sytax, still important.
Page 103 of Martin Fowler has a diagram and discription that uses the system boundry concept and system actors.
To pick on an example: this diagram says that Check Status is a scenario with two participants, a Writer and a Reader. Is that what you want to say?
Also, I don't remember seeing boxes around (sets of) Use Cases in general.
Use cases are meant to show how someone uses a system to get something of value. Actors always represent persons, in the sense of an independent being who has goals and is capable of seeking something of value.
Actors are represented in one of several ways, either directly by name, or by inclusion through a role, or by proxy in the form of an agent acting on behalf of a person or role (the "system" actor). Regardless of the form, the actor is always independent, and always capable of "acting" upon the system to achieve its own ends.
The diagram you have here is NOT a use case diagram. "Modules" are not independent, goal-seeking entities, they appear to be simply components of some system. They are not capable of "seeking" anything, they are just implementation details.
The diagram you are probably looking for is the Deployment diagram (if you want to model how specific components are wired together), the Activity diagram (if you want to model application logic), or the Class diagram (if you want to model the formal relationships between components).