Good experience for both PC and avionics products
on
How Do You Use UML?
·
· Score: 2, Informative
I am currently a software technical lead at a well-established avionics company and have been involved with
many UML-related discussions, training classes, meetings, and FAA certified projects, in addition to smaller
at-home PC-based projects. I have taught UML and the Unified Process in house for more than a year and have also
read and applied many of the key books on object-oriented design, business modeling, use-case modeling, the
Unified Modeling Language (UML), and the Unified Process. I've seen and used UML used in quite a variety of ways
(pc game, web-based genealogy database, quality system business modeling, embedded product design, embedded
graphics driver design), with a variety of goals in mind, with engineers ranging from hardcore embedded avionics
guys to throw-it-together PC app developers. On some projects UML has been very successful, and on others it has
failed, but before I mention why, let me first address a misconception I've seen as I've read the posts above.
Many engineers new to UML mistakenly think that the UML dictates a process. However,
The UML is not a process, it is a modeling language
In other words, it isn't UML that dictates the activities and process of your software development. That is
instead the job of a process like the Unified Software Development Process, or the standard waterfall, or rapid
prototyping, or Extreme Programming, or DARTS/CODARTS, or structured analysis & design, or some other
customized process. UML is a language for capturing the models and views of a system independent from any process
your project may choose to follow. A process (such as the Unified Process) will customize and extend the
available UML modeling elements and define the activities and resources necessary for developing those models.
So, when you are having process issues (such as using too much of the UML or fleshing out too much design before
starting implementation), don't assume that it's the fault of the UML--it is probably instead the result of a bad
choice of development processes.
Strengths and Weaknesses of the UML
From my experience, UML excels at specifying requirements, documenting high level design, describing both the
static and dynamic architecture of the system, highlighting core structures and key interfaces, bridging the gap
between requirements and design, bridging the gap between business modeling and application design, bridging the
gap between database design and application design, and facilitating communication between software developers
and the users of the system. (I've actually used it in all of these ways.) UML encourages engineers to think
through the problem before hacking together a solution. This doesn't mean that the design should be set in stone
first. The requirements and design can and will change, sometimes significantly, over the course of a project.
However, I've seen enormous gains in both quality and efficiency when the project team has done a prelimary
design of the core structures first in UML, then tried to code them up in C++, learned more about the problem,
revised the design in UML, then
tried again. Sure there's a cost to documentation but it's cheap relative to the cost of getting the design wrong
in C++. One last strength--UML is capable of supporting the development of a multiple layered system, even when
that system spans business processes, multiple embedded products that must be integrated together, individual
cards with separate software in those products, the layered subsystems in those cards, and on down as far as you
care to go. Few if any other modeling languages could say the same.
UML is not so good at documenting low level design except when a certain complex key area needs to be
discussed in depth with multiple engineers; "self-documenting" code with appropriate comments is much better at
documenting low level design. I have also not seen much use yet for node or component diagrams.
Slashdot Mirror
I am currently a software technical lead at a well-established avionics company and have been involved with many UML-related discussions, training classes, meetings, and FAA certified projects, in addition to smaller at-home PC-based projects. I have taught UML and the Unified Process in house for more than a year and have also read and applied many of the key books on object-oriented design, business modeling, use-case modeling, the Unified Modeling Language (UML), and the Unified Process. I've seen and used UML used in quite a variety of ways (pc game, web-based genealogy database, quality system business modeling, embedded product design, embedded graphics driver design), with a variety of goals in mind, with engineers ranging from hardcore embedded avionics guys to throw-it-together PC app developers. On some projects UML has been very successful, and on others it has failed, but before I mention why, let me first address a misconception I've seen as I've read the posts above.
Many engineers new to UML mistakenly think that the UML dictates a process. However,
The UML is not a process, it is a modeling language
In other words, it isn't UML that dictates the activities and process of your software development. That is instead the job of a process like the Unified Software Development Process, or the standard waterfall, or rapid prototyping, or Extreme Programming, or DARTS/CODARTS, or structured analysis & design, or some other customized process. UML is a language for capturing the models and views of a system independent from any process your project may choose to follow. A process (such as the Unified Process) will customize and extend the available UML modeling elements and define the activities and resources necessary for developing those models. So, when you are having process issues (such as using too much of the UML or fleshing out too much design before starting implementation), don't assume that it's the fault of the UML--it is probably instead the result of a bad choice of development processes.
Strengths and Weaknesses of the UML
From my experience, UML excels at specifying requirements, documenting high level design, describing both the static and dynamic architecture of the system, highlighting core structures and key interfaces, bridging the gap between requirements and design, bridging the gap between business modeling and application design, bridging the gap between database design and application design, and facilitating communication between software developers and the users of the system. (I've actually used it in all of these ways.) UML encourages engineers to think through the problem before hacking together a solution. This doesn't mean that the design should be set in stone first. The requirements and design can and will change, sometimes significantly, over the course of a project. However, I've seen enormous gains in both quality and efficiency when the project team has done a prelimary design of the core structures first in UML, then tried to code them up in C++, learned more about the problem, revised the design in UML, then tried again. Sure there's a cost to documentation but it's cheap relative to the cost of getting the design wrong in C++. One last strength--UML is capable of supporting the development of a multiple layered system, even when that system spans business processes, multiple embedded products that must be integrated together, individual cards with separate software in those products, the layered subsystems in those cards, and on down as far as you care to go. Few if any other modeling languages could say the same.
UML is not so good at documenting low level design except when a certain complex key area needs to be discussed in depth with multiple engineers; "self-documenting" code with appropriate comments is much better at documenting low level design. I have also not seen much use yet for node or component diagrams.
In all the projects I've worked on from avionic