Is there a formal/traditional way to describe data/command exchange protocols? For example, for programming languages there are multiple approaches to describe the syntax and semantics (like: http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form).
The approach I am looking for is rather utilitarian (in contrast to academic). I need something for day-to-day use for data exchange description while working on specifications, just to transfer/spread clearly the idea to others. So, if there is something that is not recognized as a de-facto standard but is useful - it is ok too.
I took a look at UML sequence diagrams and "Formal Methods for Communication Protocol Specification And Verification, by Carl A. Sunshine, 1979". Former method is missing the description of "payloads" (at least from what I understood) while latter one is rather an educative paper describing considerations rather than methods (I am still going through this paper, though).
Thanks in advance
Protocols are about messages sent in accordance to a series of interactions.
The best way to specify protocols that I have seen is with Colored Petri Nets (CPNs).
CPNs are based on ("uncolored") Petri Nets (PNs), which define how parallel activities synchronize, e.g., the message responses, by using Places to represent possible states, Tokens-in-places to represent state, and transition (synchronization) gates to indicate where parallel states must coincide to make progress. Petri Nets can model Finite State Machines (an FSA is a PN that always has a "single token", e.g., the "current state") and so are a generalization; in fact, they can "exponentially compress" certain FSAs into very small descriptions and can thus be quite succinct even for complex interaction sequences. But a conventional PN does not address the data being exchanged.
CPNs generalize PNs to add data types. The tokens now have "colors" (funny way to say "data type") and transitions can not only synchronize but can combine tokens to produce other tokens, e.g., compute new values.
A protocol modelled as CPN thus has message content as data types, and PNs states to indicate the syncronization. If you've never used a CPN, it is really worth your trouble to learn what they are, because they are such a pretty generalization of FSAs.
Regarding OPs' "utilitarian" remark, there are very good tools available at CPN Tools, including graphical modelling and code generation.
In telecommunications, the standard for describing interaction between network elements is Z.100 : Specification and Description Language (SDL) and the companion Z.120 : Message Sequence Chart (MSC) recommendations. The suite includes a testing framework.
A more mathematically bent approach would be to use various state machine models of some type.
One of the early publications, Design and Validation of Computer Protocols (1991), was written by Gerard Holzmann to describe the SPIN model checker and the PROMELA language.
Almost any other notation like TLA+, Petri-nets, Alloy, CSP, Z, ... can also be used to reason about protocols and the choice often depends on familiarity and tools availability.
If rigour is not essential, then Harel state charts provide a notation familiar to many engineers.
Fundamentally, the problem with sequence charts on their own is that they describe a single trace through the protocol. They cannot easily show the non-determinism required to describe parallel operations, and struggle to succinctly represent choice. When extended with hierarchical message charts (HMC) then they fall back into the state machine space.
If by "utilitarian" you mean "useful", consider Petri Nets. Please see my reply below or consider a PDF version of the reply.
first page of reply http://www.aespen.ca/AEnswers/lMtbX1428143440-0_Page_1.jpg
second page of reply http://www.aespen.ca/AEnswers/lMtbX1428143440-0_Page_2.jpg
For what it's worth, since you mention BNF: I believe I have read that Wirth used EBNF to specify protocols, with prose explaining which parts of the string were to be emitted by the client and which parts by the server. I am unable to find the reference off-hand, but my recollection is that the example I read was clearer than most protocol descriptions I have read elsewhere.
Related
I would like to to create a sequence diagram to show some interaction, and then use that sequence diagram as an interaction occurrence (sub-sequence) on other sequence diagrams. The point is I would like to apply the sub-sequence each time to a different object instance that is involved in the interaction in the sub-sequence. In my case the instances are simply various file artifacts. Is there any legitimate way of doing this prescribed by UML?
EDIT: some more clarification of my context:
I have 2 main sequence diagrams where I want to reuse the sub-sequence as an interaction occurrence
on the 1st main sequence there is one file for which the sub-sequence has to be applied 3 times
on the 2nd main sequence there are 3 different files for which the sub-sequence has to be applied 3 times
the files are read by the same object instance
I model reading from a file by a call arrow stereotyped as <<read>> to a on object instance which represents the file.
I need to reference the file somehow in the sub-sequence, but I haven't found a good and simple way of doing this.
Complicated, but formally (almost) correct solution with Collaborations
Just using InteractionUses is not enough, because this doesn't allow you to assign the actual roles in the main interaction to the generic roles of your used interaction.
Collaborations, CollaborationUses and Role Bindings can be used for this.
See my example here:
This defines a Collaboration with generic roles sender, relay and receiver and shows the interaction between them.
You can now use this collaboration in a concrete situation:
Class S uses the Collaboration two times with different role bindings to its parts (A, B and C are assumed to be able to send and receive Sig1).
With these definitions you can now create your main sequence diagram:
Unfortunately, this is not correct UML, even though there is an example in the specification (I filed an Issue https://issues.omg.org/browse/UMLR-768). You will have to fake this notation until the taskforce comes up with a fix. How to fake it, depends on how strict your tool implements the specification.
Advantage: formally correct and versatile solution, backed by an example in the specification
Disadvantage: complicated and difficult to explain, not completely usable, because of a bug in the specification
Basically there are three different ways to specify such situations.
Using a gate. Whith gates you specify the sequence with messages that start or end at a gate that is defined and in most tools (if usable at all) not shown explicitly. Instead it is modelled with messages starting or ending at the interaction border.
Similar as gates are lost and found messages. These are special messages that pass out the control to another sequence or returns from one. Such as in the case before you can define a set of further diagrams specifying the interaction in more details.
Using abstraction, which is my favorit for most of the cases. This means you extract the common interface from the classes and specify the interaction against the interface instead of the concrete classes.
Use an Interaction with Parameters:
Now we would like to reference the Lifelines of the main Interaction in the arguments of the InteractionUse. Unfortunately, in UML this is not possible, since arguments are ValueSpecifications and they cannot reference another modelelement.
However, NoMagic suggested and implemented an additional ValueSpecification, called ElementValue, that does exactly this. I think this would be a valuable addition to UML and hopefully it will be added some day. Up to then, only MagicDraw users can use this solution (as far as I know).
With this non standard element, we can model this:
The connection between the lifelines is now via the arguments for the parameters of the generic interaction. Technically the lifelines would not need to be explicitely covered by the Interaction Use, but I think that it makes sense to do it (shown in my tool with a non standard circle on the border of the Interaction Use).
Advantage:
compact and versatile solution, almost conformant to the standard
Disadvantage:
uses a non standard model element, currently only available to MagicDraw users.
pragmatic non conformant solution with covered lifelines:
The collaboration and parameter solutions allow to specify it (almost) formally correct. However, in many cases, a simplified model would be sufficient. In your case, for example, you only have two participants and they have different types. So, even though there is no formal connection between the lifelines of the used interaction, and those of the main interaction, there would be no ambiguity. You could use the covered attribute of the InteractionUse to specify, which of the lifelines (files) you are targeting at a specific InteractionUse. Could that be the pragmatic solution, you are looking for?
Advantage:
compact solution
Disadvantage:
not conformant to UML, ambiguous in more complicated situations
I'm wondering if System Sequence Diagram (SSD) belongs to design part or analysis part?
A System Sequence Diagram (SSD) is be a special type of UML sequence diagram that intends to document for one specific use case the the sequence of exchanges between the system under consideration and the outside actors.
It is not a standard UML diagram, but build upon such diagrams. The book "System analysis and design in a changing world" seem to have popularized this approach, but I could find articles dating back to the early 2000' (like this or this).
The above mentioned book places the SSD in the analysis activities. The reason is that analysis is about understanding the requirements, which often start with use-case. The SSD is then a fine-tuning of this analysis.
However, one could argue that it's part of the design activities, since the use case are the requirements, but how these requirements are addressed through a sequence of exchanges is already the start of the design of a solution, exactly as when you start to sketch an UI: more than one SSD could satisfy the needs and you have the choice.
So the answer depends on the purpose for which you're using the model.
My own point of view is that you're already drafting a solution, so it should be design, unless you do some reverse engineering of an existing application, or your client has very detailed requirements
Elaborating a little on Christophe's answer:
I would add that analysis and design are two highly intertwined activities, so you would probably see these SSDs in both contexts and it would be perfectly fine and acceptable. Use Cases, those that involve a system, are necessarily a design artefact (they are a design of what the system does in relation to external actors) although you can of course see that same thing as a pure analysis output (telling you what the system is required to do). These things are very hard to separate. The point may seem philosophical (it is somewhat), but it is useful to think in these terms.
When you see people creating "Login" Use Cases you can bet they already stepped into pure design, in other words: functional decomposition. In analytical terms the state of a User being logged in is a constraint on a Use Case, not a Use Case itself. Having a Use Case called Login therefore represents only a design choice (incidentally, if you see this in contexts where there is a division of responsibilities between the people performing analysis and design, then you'd do well to consider it an analysis fail: the analyst is essentially designing the system and that's not their role). Analysts sometimes use Use Cases to model layers of requirements that relate only to business processes, usually referred to as "Business Use Cases", that don't involve any system per se. But the origins of Use Cases from 20-odd years ago was in the system space.
I was given a special task to learn and discuss about UML at work. I have a little background about the topic, though I'm not sure what area should I give more priority since UML has now multiple versions. Should I stick with the the UML first version and give an overview for the UML 2 instead? or should I focus more on the UML 2 since it's the latest version? I'm confuse since I'm not familiar with the difference of the two versions.
I need advise regarding the matter. Thank you in advance. Pardon if this question is irrelevant in this site.
It might be practically difficult to restrain to UML 1 just for the following reason: Nearly all available tools for drawing diagrams implement UML 2 since long time ago. So, each time when drawing some construct, you would manually have to check whether it was already available in UML 1.
The step from 1 to 2 was in a large part motivated by the software engineering hype named MDA (Model Driven Architecture) some 10..15 years ago. This was about generating software directly from the model. To support this, all model elements got defined via some formal semantics. Also, some model and diagram types got enhanced. Sequence diagrams were enriched to control structures to express control flows. Component and deployment diagrams got enhanced.
Now, apart from suggesting that it won't make much sense to go back to UML 1, I read from your question that you need to set priorities. That makes sense, as the definition of UML (1 as well as) 2 is quite lengthy, and you don't want to study every detail of it. So here are a few hints:
With object oriented technology everywhere around, class modeling is the central notion. So you should be familiar with classes, associations, aggregations, composition, inheritance, attributes, operations and their parameters and results, visibility of methods and attributes, abstract classes and methods, and interfaces.
Objects of a class change their states by application of their operations. A central, and sometime underestimated, type of model therefore is state modeling. Here, UML offers two partly redundant model and diagram types: State and activity models. You should get familiar with at least one of them -- switching to the other should then be not too difficult.
Most users of UML are quite fond of use case modeling. I'm not, as those use cases tend to lack either significance (if you constrain to naming use cases and actors) or structure (if you start documenting system data and functionality with your use cases). But the rest of the world will only accept you as an UML expert if you know them, so you won't be able to avoid them. Just before using them extensively, think about how to reach the DRY (don't repeat yourself) principle when describing a system via use cases.
I have a small UML assignment due Monday; it doesn't seem too complicated, and I'm not asking this site to solve it for me -- I'm just asking for clarification over a couple doubts of mine.
I'm just telling parts of the assignment because its content is probably not so relevant.
We're provided a basic use case where the actors "officer" (e.g. police officer) communicates with the actor "correspondent" in order to report an emergency. The use case is expressed in the form:
Use case name: Report emergency
Participating actors: Officer, correspondent
Flow of events: ...
Preconditions: ...
Postconditions: ...
Then we're given three scenarios that "refine" the use case. I say "refine" because they turn it upside-down: they involve team leaders, respondents, incident handling -- nothing that was even mentioned in the flow of events described by the very basic use case given.
On top of these scenarios we're given ten "events" (i.e. they basically chunk the three scenarios into ten easily recognizable sentences). The assignment asks us to make one collaboration diagram for each of these events.
I know that collaboration diagrams describe the behaviour of the system, i.e. how the different parts of the systems interact with each other. So I thought that, even with these "creative" scenarios given, I could make something out of them. But then this part comes:
"Collaboration diagrams should make use of controller, boundary, domain objects and other new fabricated software objects (e.g. data structure components) necessary to completely handle each event."
And then:
"Your assignment will be evaluated in terms of the quality of your design (i.e. modularity: low coupling, high cohesion)"
My questions are:
1) Are scenarios supposed to present so much new information compared to the basic use case?
2) Do I just have to draw ten simple collaboration diagrams? Using which classes?
3) Why are things like low coupling, high cohesion, domain objects, mentioned? What do they have to do with all of this?
1) A scenario is a detailed description of a use case. There can be several scenarios based on constraints. The use case itself just describes the sunny day scenario in a condensed format. The meat is in the scenarios.
2) Classes related to the UC can be extracted when going through the scenario. You will find text parts that tell certain functions need to be performed. Take these classes and place them in the collaboration diagram and connect them with the right message.
3) These are general design rules. Low coupling/high cohesion means good design (and vice versa). The domain objects are those which are in the center of the system and the sum of all use cases will deal with the sum of all domain objects.
How do I determine what should I add to my use case diagrams? 1 for each button/form? Should things like sort and search be included? Or are they under "list items" for example? Though, a list of items seems understood?
The Use Case diagram is intended to help define the high-level business tasks that are important, not a list of functions of the system. For example, a system for use in customer service might involve a research task of looking up information to help someone on a support call.
Most of the literature describes Use Cases as a starting point for defining what the system needs to accomplish. The temptation has always been to be as complete as possible; adding ever more details to define the use case down to a functional (code-wise) level. While it is useful to have a comprehensive understanding of the requirements, the Use Case diagram is not intended to provide that level of documentation.
One thing that makes the issue worse is the syntax which I've never seen used in a working project. It isn't that the terms aren't useful, it's due to the lack of consensus over when to use either term for a given use case. The UML artifacts expect a process that is more focused on the business language instead of the implementation language - and by that I do not mean a computer language. The tendency by some has been to approach the diagrams with a legalistic bent and worry about things like when to use for related use cases or how to express error-handling as exceptions to a defined list of process tasks.
If you have ever tried to work through the Automated Teller Machine (ATM) example, you'll know what I mean. In the solar system of UML learning, the ATM example is a black hole that will suck you into the details. Avoid using it to understand UML or the Object Oriented Analysis and Design. It has many of the problems, typical of real-world domains, that distract from getting an overall understanding even though it would make for a good advanced study.
Yes, code will eventually be produced from the UML artifacts, but that does not mean they have to be debated like a treaty in the Senate.
The OMG UML spec says:
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems
that may interact with the subject are represented as actors. Actors always model entities that are outside the system.
The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors. Strictly speaking, the term “use case” refers to a use case type. An instance of a use case refers to an occurrence of the
emergent behavior that conforms to the corresponding use case type. Such instances are often described by interaction specifications.
An actor specifies a role played by a user or any other system that interacts with the subject. (The term “role” is used
informally here and does not necessarily imply the technical definition of that term found elsewhere in this specification.)
Now most people would agree that business and user level interactions are the sweet spot, but there is no limitation. Think about the actors/roles being outside of the main system/systems you are focusing on. But in one view a system could be an actor, but in another the implementer of other use cases.