Let's say I have an Android app that communicates with a desktop program via Bluetooth sockets.
Pseudo code on Android:
class sendToDesktop{
sendMsg(String msg){
socket.send(uuid, msg)
}
}
On desktop:
class Read{
getMsg(){
return socket.read(uuid, msg)
}
}
So how do I represent the relationship between these separate programs in UML? Can I use Component diagrams, or are they only meant to illustrate separate components of a single program?
As #Gangnus points out there are quite many options and none is the one and only.
For example this websequencediagrams.com script depicts your scenario:
The required level of detail (intermediate classes, method names, argument lists...) depends on who will read it and why.
For example this websequencediagrams.com script shows also additional internal worker classes:
See also:
uml-diagrams.org: UML Sequence Diagrams
That depends on the level of abstraction. You can use:
Composite structure diagram (if you want to notice what exactly instances call different services of other applications),
maybe Timing diagram,
Sequence diagram(if you are interested in the sequences of mutual calling),
Interaction overview diagram (messages and timelines are hidden),
Activity diagram (for analysis of business rules),
Communication diagram (for naming the pieces of translated information and their addresses),
and even State or Use Case diagrams.
Try to start from below and continue up to the level where you will have one A4-size diagram.
If using UML is imperative, then you may want to consider using a communication diagram as shown here. While a communication diagram is ideally suited for elements of a single application, you can adapt the diagram to show communication from one application to another.
If you are not tied down to UML, I have found data flow diagrams to be very helpful to demonstrate the information that is flowing from one information source/consumer to another (via an intermediary process--in your case the intermediary process might be your methods that contain the Bluetooth logic).
In answer to the original question: no, component diagrams are not restricted to parts of a single program so yes, you can use them.
UML diagrams are not tailored to any specific level of abstraction or scope of work. If your "system under consideration" contains two programs, then that's what you should show in the diagram.
Related
In the context of bounded model checking, one describes the system as a State Transition System and the properties that need to be checked.
When one needs to provide multiple system descriptions and properties to the Model Checker Tool, it can become tedious to write the property by hand. In my case, I use some temporal logic.
How does one automate the process of translating/parsing the system description and deriving verifiable properties from it (ideally, a set of Initial states, Transitions, Set of States).
For example, consider the Microwave Example given here Given such a system description, how can I arrive at the specifications in an efficient manner?
There is no such open source tool that I know of, that can do this. Any approaches in terms of ideas, theories are welcome.
You can't automatically derive LTL formulae from automata as you suggest, because automata are more expressive than LTL formulae.
That leaves you with mainly two options: 1. find a verification tool which accepts specifications that are directly expressed as automata (I'm not sure which ones do, but I suspect it is worth checking SPIN and NuSMV for this feature.), or 2. use a meta-specification language that makes the writing of specifications easier; for example, https://www.isp.uni-luebeck.de/salt (doi: 10.1007/11901433_41) or IEE1850/PSL. While PSL is more a language definition for tool-implementors, SALT already offers a web front-end that translates your input straight into LTL.
(By the way, I find your approach methodologically challenging though: you're not supposed to derive formulae from your model, but from your initial system description as it is this very model which you're going to verify. But I am not a 100% sure, if I understood this point in your question correctly.)
I think properties of a system, e.g. Microwave system, come from technical and common sense expectation and requirements, not the model. E.g. microwave is supposed to cook the food. But it is not supposed to cook with door open. Nevertheless a repository of typical LTL pattern can be useful to define properties. It also lists properties along with more familiar regex and automata properties.
If you certain you still want to translate automata to LTL automatically check
https://mathoverflow.net/questions/96963/translate-a-buchi-automaton-to-ltl
Kansas Specification Property Repository
http://patterns.projects.cs.ksu.edu/documentation/patterns.shtml
Let's say I have a collaboration diagram that models a process named CheckMessage which is quite complex and spans over few lanes and pools. Now I would like to model another process, e.g. CreateMessage which would make use of the previous process to check first if message doesn't exist already or if all its fields are valid, etc.
The thing is, that both processes make use of the same swimlanes and pools. What is the proper way to model such interactions? I was thinking to model CheckMessage as a sub-process of CreateMessage, however sub-processes can't be attached to pools or lanes - if I understand it correctly they just stay within a lane of activity which invoked them. Can a Call Activity encapsulate such beahviour (cross pools and lanes)? Or can I somehow reference the CheckMessage diagram as a whole?
Thanks in advance.
I could think of the following approaches:
Using Diagram Reference: This is used quite often when you want to switch easily to the more complex part. The disadvantage is that, unlike Fragments in SDs, you do not have ways to really connect flows in and out of referenced diagrams.
Repeating parts of the process: here you just pick those actions from the complex process which ought to interact with the other process. You can highlight that by putting a boundary around these and adding a diagram reference as described above.
Call Activity: This is another valid way. Here you have an activity which you instantiate as action. The advantage here is that you can add pins for input and output parameters.
I guess there is no silver bullet and you have to choose what is appropriate in each case.
Edit Regarding #3 it looks like that:
(this is an example and not to be used in practice)
The Action to the right is an instance of the Activity as you can see by Ctrl-L (show parent).
This is the scenario.
There are three components, A, B and C.
Component A can access methods of component B.
Component B can access methods of component A and component C.
Component C can access methods of component B.
To implement this scenario how many interface description language (IDL) files are needed? How many stubs and skeletons do we require?
I was thinking four IDL files. But can we have multiple stubs and skeletons?
Depending on the size of your services/components (number of methods), I would rather try to split them into logical units rather than based on the number of computers you want to connect.
For example, it can make sense to have two different services implemented by the same server: One for internal purposes and one that is to be published. Or a service is split into two parts, because these two parts do not really belong together logically, although they are for some reason implemented by the same component. All of these services may or may not share the same IDL file.
Last not least, if you still want to minimize the amount of files, keep in mind that declaring, publishing and knowing about a certain service interface does not imply, that a given component must implement the service, must be able to reach the service, wants to use the service, or is allowed to call it.
I have a sequence diagram in Enterprise Architect.
In it is a process which can be initiated by one of two sources: either a timer process or a manual one (a user hitting a button on a GUI screen).
How do I show this on the diagram, please?
A sequence diagram does not allow you to show two alternative invocations of the same operation. You could achieve this in an activity diagram using two different receive events leading to the same activity, but in a sequence diagram you can't draw two messages to the same sequence.
What you can do is call other sequences from within a sequence.
You do this by first drawing the sequence for the process, not showing how it is initiated or by whom but only what happens within the process.
You then draw two separate sequence diagrams for the two different cases, and into each you drag the first sequence diagram and drop it as an "Interaction Occurrence."
Finally, you draw a message from the actor to the interaction occurrence. The occurrence can be double-clicked in the diagram, which opens up the sequence diagram describing the process.
A related problem is, of course, that there is no standard way of showing spontaneous occurrences (timeouts) in sequence diagrams, since they focus on interaction between a caller and a callee (often in a cascade). The simplest way of dealing with this is to create an actor "Clock" or similar, and have it initiate the process.
You might want to introduce an interface (or a superclass) that is common to the timer process and the manual invocation and set that as the user, as the calls (I assume) are likely to call the same basic method anyway.
If they behave quite differently, I'd go with Uffe's advice and create 2 diagrams.
Some tools also allow for using fragments in sequence diagrams (see corresponding help text for Enterprise architect).
Then you may use e.g. the "alt" fragment. Note the advice in the given link, though: "sequence diagrams are not intended for showing complex procedural logic".
Just for my personal wiki, I want to draw a diagram that shows how a message is processed via a couple of Message Queues.
(Like, xml message comes from source1 to the Queue1, then it is passed to a system where the message is converted into another format and...)
What kind of UML diagram should I need here?
And additionally, how do I show a Queue in UML?
Order and time are best seen in an Sequence diagram. Also the communication between the different parts (source, queues) and parameters will be visible.
A queue is just an object (the squares at the top of the diagram).
Sequence Diagrams are a good choice but they have limitations when used for interactions with a large number of steps. They excel at describing the steps to a single operation, such that the actors are related to the behavior required. I try not to left any single sequence diagram take up more than one page. If I need more, I break it up into two serarate diagrams because I'm usually wasting whitespace due to the calling depth and the interacting quickly becomes harder to understand instead of easier.
You might use two types of diagrams. On a system-level diagram, show the interaction between the queues (or their hosts), and on a Sequence Diagram show the steps taken within a single host.
I think that the best good is an activity diagram. In my view it is the best way too show process flow. Sequence diagrams are harder to understand and also has a lot of clutter (the lifelines) which just bother the reader. And having two diagrams just makes things complicated