I'm struggling at understanding UML component diagram.
I've just been through the "assembly connectors" and here's what I (think I) understood:
the circle represents an interface, which I understand as a set of functions that a component can offer to the others.
the half-circle... well, don't know how to call it, but it says something like "there's some functions I need in order to operate correctly". In the image, I guess that an order must have access to functions that return details of the Customer (e.g: methods GetName(), GetAddress(), etc.), that's why it has the assembly connection with the Customer Details interface, provided by Customer.
My question is: why is there a dependency relationship arrow from the interface which Account provides (AccountDetails) and the interface which Order requires (Payment)?
The link of this image doesn't explain it.
The assembly connector (two shown on top) is a kind of provisional concept. You know that there should be an interface used instead, but have not yet made up the details. This is a connector which looks like socket/lollipop. But it's a connector.
The separate lollipop/socket are concrete interface uses. These are real elements. The interface itself is not actually shown (you will have a separate diagram showing the details). But to make clear that the depending interface is related to the providing one you draw a dependency.
Simply spoken, the above is something in the middle of a design phase. Finally all assemlies should be replaced by provided/required interfaces.
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.
I defined my software system using EA. I stayed mainly at the high level so far. The software interfaces between my components are represented as Structural Elements "Provided Interface" (the little purple bullets) and "Required Interface" (the little sockets).
Now, I would like to go a little bit further into the details, and define the API corresponding to each of these Provided Interfaces, ideally as a class diagram. It would be perfect if I were able to create a nested composite structure diagram for each of these Provided Interfaces, like for software components for example. But it seems that EA does not enable that.
What I do is that I create an Interface nested in my software component, then I link the Required Interface (the purple bullet) to my Interface (purple square) with a Dependency link. Then I can create a nested composite structure diagram in my Interface. But I doubt this is the optimal method.
Can someone tell me what is the "EA-approved" way of defining Required Interfaces ?
Thank you :)
You can directly select the Interface in the ProvidedInterface or RequiredInterface without needing to explicitly create a Realize or Dependency connector to the target interface.
You can do this as shown in the figures below:
One advantage of this is that you do not have to show the actual target interface on the same diagram as the components while still being able to navigate to them. This becomes handy when you have components that provide or require many interfaces (and you do not want to clutter your diagram). With this approach you can use the Find | Locate Classifier in Project Browser context menu and directly jump to the composite diagram.
Can I use directed named association on component diagram to show fact that "sys A" sends data to "sys B"?
Example:
No, you should use general purpose dependency instead, with optional title.
However, the title is not very common in this context. Better use some other diagrams (sequence for example) to show the communication details (e.g. open connection, send data, close connection, etc).
If there is a well defined interface between those systems, you can indicate that as well like this:
Association is used between two classes to show that their instances are potentially connected (again, not for data flow indication).
In UML 2.0 the concept behind association is vague, read this article: http://www.uml-diagrams.org/uml-core.html (search for "Semantic Relationship"). Association denotes a "semantic relationship" between two components, and I think it wouldn't be appropriate for data flow.
I think that even dependency isn't appropriate for data flows: maybe the client depends from the supplier, maybe the opposite is true... so the arrow can be very confusing.
The lollipop notation is the best, IMHO: it shows clearly that there is a component providing an interface, and another one requiring it. You can use stereotypes on the interface to show the type of communication/data transfer, and labels to make clear what data is transferred.
The book "Documenting Software Architectures" adopts another style, using prevalently associations: see p.145. It's similar to your initial proposal, but with explicit roles and without arrows. I think isn't a really satisfactory solution, without stereotypes...
If sys A sends information to sys B and you're not interested in how exactly the transmission takes place, then that is a classic application of the Information Flow connector.
A Dependency would in this case say that sys A needs (is dependent on) sys B for something. An Information Flow often (but not always) goes in the opposite direction of a Dependency, since it is typically the receiver that needs the sender.
There are many different ways of showing these types of relationships, and the best one depends on the situation. If your focus is on the type of information being transmitted, then Information Flow is the best fit. If your focus is on the way the transmission takes place, something with an Interface, possibly an Assembly, is better.
EA actually allows you to specify an Information Flow over an Assembly, so you could even combine the two. It's all down to what exactly you want to express.
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.
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).