UML in software design

[Sae1962]

Hello!

My question concerns software architects that have experience with UML/UTP.

Introduction:
We are currently in the start phase of a new project, where documentation for hardware with embedded software is written. I am responsible for the GUI development. As the starting point, a predecessor model is used. Its GUI was presented to me as the first information with some planned modifications to it.

Although I have more than 15 years of software development experience, I was rarely involved at the start phase of projects, as I am working as a consulter. Consulters are often called when the project is running out of time...

As I consider it important to start with test documentation in parallel to functional specification, I think about using UML for the description of functional parts. For the test, I think of model-driven testing and to use UTP (UML Test Profile).

Details:
In our system, three types of users (actors) exist: power plant technician, commissioning technician, and system expert. The GUI is primarily used to
1. Watch values and change index values
2. Make the commissioning of the device (commissioning mode)
3. Install new software or make system maintenance (expert mode)

There only exist prescriptions for the commissioning phase. Reading and changing values over currently nine menus and their submenus is not described in detail, as it is more or less straightforward.

My question:
Is in such a project the use of UML/UTP to be recommended, and to what extend? Is it OK to draw for each simple menu access use case diagrams? I do not want to get caught by the UML fever (see http://queue.acm.org/detail.cfm?id=984495).

[Netcode]

Hello!

My question concerns software architects that have experience with UML/UTP.

Introduction:
We are currently in the start phase of a new project, where documentation for hardware with embedded software is written. I am responsible for the GUI development. As the starting point, a predecessor model is used. Its GUI was presented to me as the first information with some planned modifications to it.

Although I have more than 15 years of software development experience, I was rarely involved at the start phase of projects, as I am working as a consulter. Consulters are often called when the project is running out of time...

As I consider it important to start with test documentation in parallel to functional specification, I think about using UML for the description of functional parts. For the test, I think of model-driven testing and to use UTP (UML Test Profile).

Details:
In our system, three types of users (actors) exist: power plant technician, commissioning technician, and system expert. The GUI is primarily used to
1. Watch values and change index values
2. Make the commissioning of the device (commissioning mode)
3. Install new software or make system maintenance (expert mode)

There only exist prescriptions for the commissioning phase. Reading and changing values over currently nine menus and their submenus is not described in detail, as it is more or less straightforward.

My question:
Is in such a project the use of UML/UTP to be recommended, and to what extend? Is it OK to draw for each simple menu access use case diagrams? I do not want to get caught by the UML fever (see http://queue.acm.org/detail.cfm?id=984495).

UML would be good to graphically represent the flow of the program but like you mentioned, time is not on your side so you have to be very fast if you conclude on using UML and UML may be perfect for you as a developer but may not be comprehensive to the clients you work for.

[ithinksoft]

I personally feel UML will be a better way to start no matter how much less time you have...Even you yourself can get a precise and crisp view of the development you'll be doing once you start developing in UML.

[Sae1962]

I personally feel UML will be a better way to start no matter how much less time you have...Even you yourself can get a precise and crisp view of the development you'll be doing once you start developing in UML.

That is the point: feeling is not a good criteria, if one has no experience at all; feeling of an expert is a good indicator whether something will help or not.

I read the above article about UML fever and want to find out where the boundary to this "UML sickness" is. :-/

[JeffGrigg]

I am a very visual person, so I do like visual representations, such as UML. With years of experience in Diagram/Document-Driven approaches and also the Agile and Extreme Programming (XP) community, I would have to say that my experienced expert opinion is that less UML is generally better.

If your project uses a relational database, then I would say that you need to create an Entity-Relationship Diagram, and to keep it up-to-date for the life of the system.

I add other diagrams, both UML and ad-hoc, as I see the need. (The "rules" for UML are quite flexible, actually.) Start by drawing diagrams by hand on whiteboards and paper. Many diagrams will turn out to be temporary and will not need to be maintained over time. When you find it useful to maintain or update a diagram several times, then it makes more sense to put it into a tool than to keep redrawing them -- particularly for diagrams that get more detailed over time.

Focus your efforts first and primarily on the interfaces between systems. If your programmers are any good, they can figure out the low-level details themselves, without requiring an excessive level of formality. Very few implementation classes benefit from UML diagram formalities.