UML for structured programming

[Ronaldo Juliatto]

Hi all

We are currently getting into an aerospace development, more specifically a satellite subsystem. Although our project manager wants the software programming to be coded as structured, we would like to be able to specify and design it using UML.
The main reasons for that are:
1 - There are few people that understand notations for structured real-time specification and design.
2 - There are few tools that are able to help with structured methodologies in a complete framework as EA does for UML

So, the question is:
Do you know any kind of UML-based process that could be used to specify and design a structured program as a result?

I think that the higher-level diagrams could be used without change (e.g. deployment, component, use-case diagrams), as well as some lower level ones (e.g. Activity, Sequence). The main problem, from my point of view, remains on how to represent the software modules themselves, once classes could not (conceptually) be referred at this level.

Would any of you have any idea or have you faced this before?

Thanks in advance

Ronaldo Juliatto

[cpns]

Two suggestions:

1) Use stereotypes to map class model elements to structured entities such as <<module>>, the nature of this stereotype being a container for static operations and attributes, and  <<structure>>, a class comprising solely of attributes, which may be passed as parameters between <<module>> member functions or instantiated as global objects or member attributes. A <<module>> holding a reference to a <<structure>> would show that with an aggregation link, whereas a <<module>> containing an instance of a <<structure>> would show that by either a member attribute or by a composition link. The key here is that in structured programming, data and control/transformation are separated - which is easy to represent in UML if not very natural. Obviously it could get far more elaborate, but remember to document your stereotypes and patterns so that everyone knows and agrees what they mean in practice.

2) Do an OO design and implementation in a non-OO language. For years as a C programmer I often programmed that way without even realising it was OO!

The latter does not really do what you asked, but the question is does the project manager really want structured programming, or simply a constraint to use a structured programming language? For example in C you can do OOP with some effort, and the simpler Object Based Programming subset is very easily done; it is merely that the language does not directly support the paradigm. EA will generate C code from a class model, therefore doing much of the tedious work for you.

It is more common on projects to have a constraint on programming language that on programming style or paradigm, so the second approach may be permissible.

Clifford

[cpns]

I came accross this article on Functional C profile for UML by Bruce Powell-Douglass. It may be of interest: http://techonline.com/article/pdf/showPDFinIE.jhtml?id=1992014901

[jeshaw2]

We are currently getting into an aerospace development, more specifically a satellite subsystem. Although our project manager wants the software programming to be coded as structured, we would like to be able to specify and design it using UML.

A request for clarification:  By structured coding, do you mean the traditional structured control flows of logic or do you mean the functional decomposition of the application process as opposed to the object oriented paradigm?

-Jim

[cpns]

A request for clarification:  ...

I imagine that it is probably too late to re-open this discussion that started in June 2007. The OP failed to respond at the time, so I would not imagine he would now. He was either very satisfied with the response, or just plain rude. :-/

I merely posted to it because I originally responded and had come across information from a respected author on the subject that may be relevant to the OP, or at least useful to any one searching on the subject later.

Regardless of what the OP means by the term (all these terms have probably been used, reused, and abused over time), I think the paper addresses his main concern stated as "The main problem, from my point of view, remains on how to represent the software modules themselves".

Clifford

[Ronaldo Juliatto]

Hi

First of all, sorry for not responding promptly to the answers that you kindly presented me. It was due to some difficulties both regarding to the definition of the "methodology" itself as well as the actual work of creating the suitable documents.
Well, our boss (who was engaged in aeronautical software development 20 years ago) likes methodologies like Ward-Mellor and Hatley-Pirbhai. His vision is tied to the functional decomposition, data flows and some architecture diagrams.
Our goal, more than effectively design the system, is to justify the use of UML to the design. However, it is necessary to show the design from the functional point of view.

Roughly speaking, by now the point we got to is:
1. The system is represented by a node in a Deployment Diagram, where other systems are also nodes. The target system has some exposed logical interfaces. This can, more or less, represent the Context Diagram from SA/SD.
2. The following step is to functionally define the system. To do this, we are using the UML 2.1 Activity Diagrams, which allows for the control and data flows. This diagram supersedes the DFD (Data-flow Diagrams) with advantages, presenting the sequence of processes besides the data interchange architecture.
3. A Component diagram can show the internal architecture of the system in terms of hardware and software.

Basically, these two steps define the system, allowing us to describe the system itself, its functions and interfaces. We did not start to design the software, but we are expecting to do the following:
1. Define the architecture of the software as a Component Diagram.
2. Define the internals of each component as a set of modules. The modules are effectively classes stereotyped as a <<Module>> or something like that, as cpns stated in his first post.
3. Generate Interactions diagrams to show the dynamic relationship between the modules.

There are still doubts, some related to UML itself and some related to the process as we intend to create. Here they go:
1. What is the best way to represent a physical interface such that:
a - It can represent a physical channel (e.g. RS422) implementing a set of logical data (e.g. Inertial Unit telemetry)?
b - It can be traceable to lower levels of the system detail?
c - The information regarding to the interface can be exported in a document (I guess I should use Tagged Values, but I am not sure)
2. How would I represent a Function Tree?
3. How would I represent a product tree?
4. Is it reasonable to somehow relate (by realization or something like that) the data interfaces of the Activity Diagrams representing the functions of the system to the physical/logical interfaces defined in the upper definition levesl? It would be good for traceability (a constant worry in aerospace development), but is it acceptable from an UML point of view?

As soon as we get into the software development (we are hopefully finishing the system design phase) I think that more doubts will arise.

By now, once again sorry for the long delay and thanks for the answers.

If some of you could help, thanks in advance

Best regards

Ronaldo Juliatto

[cpns]

The answer to some of your 'doubts' (I have not considered them in detail) is almost certainly SysML .

For (1) SysML ports and <<flow specification>> and <<interface>> stereotypes would be appropriate. You define the interface for one end, and the other is its conjugate. If you wire your RS232 as a DTE-DCE link this works right down to the physical layer. If you use a null-modem connection the physical layer will be ports of the same specification rather than conjugated. I think (2) is dealt with in the Bruce Powell-Douglass document. For (3) Perhaps a structure diagram with composition and/or generalisation - note I am being deliberately vague about which structure diagram - as an idiomatic use it probably does not mater much. Or you might use a SysML block diagram which also supports composition and generalisation and other associations. With respect to (4)... yes probably.

Sorry I suggested you may have been rude.

There is nothing much wrong with Ward-Mellor or other structured methodologies other than the current lack of tool support since all tool vendors have followed the money with UML and associated OO methodologies. Remember however, UML is a notation not a methodology. You can say what you like how you like so long as you respect the semantics of the language.

I once asked Stephen Mellor at a conference panel discussion on UML and MDA (Bruce Powell Douglass was also on the panel BTW) what was wrong with the Ward-Mellor methodology he co-authored I had worked so hard to understand and use 15 years ago that he now backed UML/MDA and that authors, tool vendors, and methodologists now exclusively promoted. He replied "this way I sell more books". Which is about the crux of it; methodologies are promoted by tool vendors and authors, they may be right, but what they told you 10 years ago is not necessarily wrong either - just no longer supported. There's no money in it. With comprehensive and low cost tools such as EA there may also be no money in this for some vendors either, so they will drive toward yet more increasingly arcane notation to create UML 3.0 and SysML 2.0 perhaps. I am sure it still will be called UML/SysML however since it was designed to be extensible and has teh weight of multiple authors and vendors behind it.

Note you can still buy Yourdon SELECT which supports Ward-Mellor extensions.

Good luck.  

Clifford