Modelling a PDU

[Bokkie]

Ok, here's another:

How do we model a PDU using EA/UML?

A PDU is a message of a given protocol comprising payload and protocol-specific control information.

Traditionally a PDU is specified as a 'table'; header and a single row. A Columns specify the meaning and size.

Regards, M.

[«Midnight»]

You may have answered your own questions.

Create a Table class - rather than using the <<table>> stereotype, which is intended for other uses - and give it appropriate properties. You can drill down to lower-level contained entities later, but this should work for now.

Create a Header class, containing additional information. You may have a link to the Table class, with an appropriate role, depending on how you view the logical relationship between these classes.

Now create a PDU Class. This will have properties (or roles as the case may be) with types of Table and Header. There would also be other properties depending on what you need.

If your PDU class might be constructed in different ways, depending on specific protocol (perhaps you could have custom implementations) or if you build several variants of the PDU that differ in the additional information, then you could make the PDU class abstract, and then specialize it through inheritance. This also holds true for the Table and Header classes.

HTH, David

[Bokkie]

Asuming that you ment by a Table class and Header class classes with the name 'Table' and 'Header' - I am aware of this technique but would prefer a plain table (or matrix) because it is more easily readable and much clearer.

What I am looking for is how to express this e.g.:
http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/pics/pdu60.png
or this:
http://www.linux-france.org/article/gvallee/snmp/pdu.jpg

[thomaskilian]

Looks like any iterator could do the job.

[Bokkie]

Not looking for a solution/design pattern here... Instead looking for how to specify it  

[«Midnight»]

Bokkie,

I think my first answer is still appropriate.

Create classes to represent each of the lowest-level components. Then create several specializations of an abstract PDU class; you might want to have a couple of levels of these, but can leave that for a later time.

Build a VariableBindings class that has a set of parameters of type Name. These can be a collection, which could be ordered. You could also specify some kind of upper bound on the collection if and handle it as appropriate.

In the specialized PDU classes, create attributes typed to the various low-level classes earlier, or as VariableBindings. You could specify an Integer (or whatever) that is forced to a default value of zero, perhaps as read-only, to cover the SetRequest PDU et al.

Follow this logic until you have your model.

Remember throughout that you are not modelling the data, you are modelling the structure. Data can be specified via logic elsewhere in your model and your application.

David

[thomaskilian]

Not looking for a solution/design pattern here... Instead looking for how to specify it  

What do you want to specify? The memory layout? Well, maybe one can use UML for that, but I never thought of that. Probably you could use some Component or Stereotyped Artifact for that. However, I'm with David: not data but structure model you must. Be the force with you.

[Bokkie]

Or simply insert a picture /wmf of the Pdu.

Would be nice however if EA would allow you to create a 'real' table like in OpenOffice/word/excel. There are so many things that can be simple expressed in a matrix/table.

Thanks for the support!

[potterm]

Bokkie,

If you're happy to use a free text table and associate it with an element or package, you can use a Linked Document instead (use the Linked Document option on the context menu).

You could then just create the table using the RTF editor (it supports MS-Word like tables).  The editor supports templates, so you could could create a generic template for PDU definitions and EA will prompt you for the template to use the first time you create the linked doc.

The docs created in this way can also be inserted into any RTF reports that you generate.

The only downside to this is that you're not modelling the PDU definition - it's just a free text description.

Martin.