How to draw a component diagram where the same component is used in multiple places?
Do I simply draw the same component twice?
You are not clear about the use of instances. Components are just blueprints you can use and re-use.
In this example we use a Motor which is associated with either a Boat or a Car. It's an (abstract) component which means that the imagination cloud will include gas, diesel, steam, rubber band, electrical or any other kind of motor. The context where this is used might fence this a bit more. But it's definitely not meaning the motor in your personal car.
As you see this Motor can be re-used in the model to be associated with a Boat or Car. Also note that it's not clear here whether it's used for driving or to remote control the back mirror.
Now for something more concrete.
The Motor and Car are now two distinct physical things. Re-using the Motor with this serial number somewhere else would mean you could no longer use it in this Volkswagen.
If you have an interface between things you can re-use the same instance (though not at the same time)
like the above wheel could be easily re-mounted on different cars with the same mounting holes. (Don't bother that there's only one wheel for the car.)
Just as thought food: you can also use Generalization with components. E.g. you can classify different motor types. Components are not so much different from classes. It's more or less just that components are a cluster of different classes working together.
Related
I have a task to make a simple information system for the functioning of a guest house. I need to make a USE CASE diagram, but I don't know if what I've done is correct, or if I need to add something, I don't know where to include the maid.
As users of the system I have put - client, receptionist, manager
As objects of the system I have put client, room, occupied rooms, employees (maids, receptionist, manager), tour agency, payment
Can you give me a hand?
Well, you are at the verge of functional decomposition. And that's not what UCs are about. They are about added value. So the bubbles contain headers describing those added values. For a hotel the basic UC would be Reserve room. (A real hotel would of course offer more added values, but for your example that's it.)
Now, the reservation is usually going along with payment. But would you consider that added value? I would not. So rather than making these UCs they are constraints (from requirements defined elsewhere). There's a lot one could talk about representing requirements and business rules, but that is far too much for a discussion here. I recommend reading Bittner/Spence about UC sythesis. It takes that book and a lot of experience to get familiar with this area.
Note that UCs are described with subject/predicate(/object) to be meaningful. Room is no UC. If you intend to show an object, use a rectangle (with object notation). That however, is in most times more confusing than helpful. Stay with actors and (real!) use cases.
Another note: the downward association from Hotel manager should rather be a generalization (open triangle instead of an arrow). And the actors usually are also shown with arms ;-)
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
So I was given a task of making a class diagram for a bicycle. I know what a class diagram is and the concepts behind one.
Now to me, a bike has three major components: the brake system, drive system and steering system. And each system has each own activators for actions: a brake handle, a pedal and a handlebar.
For my bike to actually brake, I need to go through the brake lever to trigger my brake system (pass data on how hard the lever is squeezed from the lever to the brake system). Same for the other two systems as well. This is what I've come up with so far:
My question: Is there a better way to illustrate the connection between the activators and the systems they're supposed to pass data to? Also the system works in isolation, meaning that external factors such as crashes or mechanical failures are not in the scope of the system.
Yes, there is "a better way to illustrate the connection between the activators and the systems they're supposed to" activate. These "activators" are, in fact, part of these subsystems. Consequently, you should not use plain UML associations on the first two levels of your composition break-down hierarchy, but rather UML composition relationships (with "black diamonds"), which are special associations representing part-whole relationships where parts are exclusive (= non-shareable).
Bicycle would be composed of BreakSystem, DriveSystem and SteerSystem. Then, for instance, BreakSystem would be composed of the "activator" BreakLever and Brake. Likewise, for the other subsystems.
Since you don't model a digital bike, better say that an activator (like break lever) causes a subsystem (like the break system) to react, instead of "activators are supposed to pass data to" these subsystems. In a mechanical system, it's about physical causation, and not about passing data.
See also https://www.uml-diagrams.org/composition.html for an explanation of the UML concept of composition, which often comes with, but does not imply, a life cycle dependency.
I would like to make a component diagram for a multiple robot coordination system.
I would like to show on the component diagram that the sub-component "Perception" of each "Robot" component communicates through an interface with each other. Indeed, the sensors of all robots are used in order to estimate the position/velocity of each robot, it is a cooperative sensing.
How can I do that ? Should I have an interface which would be both provided and required by the component "Robot" ?
Thanks.
For this type of system you are in position to use full power of UML and make really effective documentation. You will most likely need some (or all) of the following diagrams:
Component diagram - to show the "big picture" and the main parts of your system ant their interfaces and dependencies. Components are "black boxes" here and will be detailed in the following diagram
Composite structure - are perfect to open up the components and show their internal structure. You can take "black boxes" and their interfaces as kind of input to this work. Each component (except the external ones) should be modelled internally. This kind of diagrams lets you use the whole-part paradigm to model internal structure as a network of interconnected elements. Previously detected interfaces will be used here to show how they are actually implemented.
Class diagrams. If you need to further specify the elements of internal structure (their attributes, methods, associations, etc), this is the diagram to draw.
State machines. In embedded real-time systems, lots of classes are active and have states. Identify those classes (or even components) and use state diagrams to show their internal logic.
Sequences and interactions. These diagrams will help you to specify how different elements of your system work together to implement different scenarios.
Deployment diagram. As robot is a piece of hardware and these components run on it (or them, if there are more than one hardware node) you might want to show how the components are distributed over the hardware structure.
You could also have a look on timing diagram, relativelly new one, designed especially for real-time systems. It might come on handy if you need to express time restrictions, durations, etc.
If you are new to UML, I would recommend to start with components and deployment. They are relativelly easy to learn. As you feel understanding and need to express your ideas further, dive in the composite structure and states. And finally classes.
Have fun!
EXAMPLE
This is how I understand your model and its elements. This extends my comments.
Explanations are in comments and in the diagram notes.
A component diagram:
A component instances' diagram:
Note that the first diagram should be extended with the "connectivity rules" that define all valid connectivity possibilities. Is there only one CentralManager? Must each Robot be connected to CentralManager? Can a Robot talk to itself? And so on...
These and other questions should be modelled separatelly. On class diagrams benavior diagams, according to concrete details.
I have a equipment which I am representing with a class and there are two actors a remote and local operator who can put the equipment on or off. Both actors will use the functionality of the equipment. But How do I now represent them using sequence diagram, since if I draw an event from both local and remote its going to show at the equipment the one happened after the other but in reality two actors are using the same function and can invoke it any time. So how do I represent the two actors in the below sequence diagram.
P.S. The RAN40L is the equipment and CMS is remote operator and Simulator Operator is the local operator.
As it happens I have extensive experience from the defence industry, including naval CMS, so I am familiar with the domain.
The crucial question is, as always with UML, what you want to show in the diagram, which of course ties in with what you are showing in other diagrams. No diagram is ever read in isolation and you will never capture the entire radar functionality in a single sequence diagram.
Remember that a sequence diagram is intended to show things happening in a strict sequence. It is possible to show some rudimentary concurrency using the appropriate fragment, but if you want to show that the two actors do exactly the same thing, that the sequence is in fact one and the same in both cases, then the sequence diagram is the wrong place to show that.
Assuming that this sequence is intended as an elaboration of a use case, then the solution is to replace the two actors with a single actor, eg "Radar Controller". This actor can then be specialized into CMS and Simulator, which makes sense if the radar is unaware of, or unconcerned with, who is interacting with it in some (use) cases but not in others.
If the radar never makes the distinction, there shouldn't be two actors at all. The actors must make sense to the system they're interacting with, otherwise there's something wrong with your actor model.
So one solution is to structure the use cases as below.
http://sdedit.sourceforge.net/images/webserver.png
This is a good example where two actors are used. It is default to put one actor to the opposite the other (this is not done in the example).
Actor is considered to be just another object in the sequence diagram. You can plase arbitrarily many actors and use them just like any other object, no restrictions in this sense.
There are some stylistic guidelines though, most of all regarding Actors positioning on the diagram. It is a common practice to show the actores on the border of the diagram, keeping internal system objects inside. Moreover, human actors are typically shown on the left side, while system actors are kept on the right. Actors should not be "mixed" with system objects. Here is a simple example:
Everything in behavioral diagram is executed after behavior defined by diagram started.
If actors interacts individually, and their interaction are not moxed in single execution, you must draw diagram for each case.
I would say you need two diagrams, each for one actor.