Re: More CChildFrame questions

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

You can write a bad FORTRAN program in any language, including UML.
joe

On Fri, 22 Jun 2007 16:40:44 +0100, "GT" <ContactGT_remove_@xxxxxxxxxxx> wrote:

[snip] - I / We have sorted the original problem, but I feel the need to
defend myself / UML:

UML is simply a language - we cannot blame UML for bad design. We can only
blame bad designers for bad design. You have obviously encountered work from
many bad designers who chose to document their work using the UML,
unfortunately!

OO/UML projects are completely iterative - the design is not finished until
the product is released. In this case a coding issue has fed more
information back to the static design (class design) and the design has
evolved. This is how UML is supposed to work.

Note that if you "know UML" then why didn't UML tell you that your design
was bad?

UML can't prove a design will work - its just a language to enable visual
representation of analysis, design, testing etc. In my case, the design
looked fine at the point of documenting it - I had a view class containing
all the methods and variables that belong with that view. That view class
was shown at one side of an association. At the other end of the association
was a frame, which could be a docking pane or CChildFrame. I did not know
that the view-frame relationship is actually a composition, whereby the part
(view) is destroyed along with the whole (frame). My design was not bad, it
was just not refined enough! I had used the UML to document a conceptual
class which in reality (coding time) has turned into 2 concrete classes! We
have effectively enhanced the original UML design using a variant of the
State pattern.

This
is what I meant by "Voodoo design". You can create all the UML diagrams
in the world, and
they don't tell you that you have confused two orthogonal concepts!

They don't need to - either experience will prevail and someone will modify
the design before coding starts (you in the case below), or (as in this
case) coding will throw up a problem which will feed back into the design.

I've had to review designs done by "UML Experts" and they are uniformly
bad designs.

That doesn't mean the experts didn't do the UML properly - it just means
they didn't do their design very well!

Pretty pictures picturing bad designs doesn't contribute to the design
process, and they
were convinced that because they had pretty pictures, they had good
designs. One project
I worked on had a set of UML diagrams which ran for 20 pages claimed to
enumerate all the
possible state transitions; we found six that they hadn't considered, and
in fact were not
handled by their code; the only effort we had to spend was reading those
20 tedious pages
to make sure that each of our cases wasn't actually covered. But the
diagrams were quite
pretty. Useless, but pretty.

I would suggest that the diagrams were not useless, they were simply not
complete. It is not normal to have to go through pages and pages of
statechart diagrams - these are usually used to 'flesh out' the static
model, one per class and ONLY when necessary! Why they needed to produce 20+
statechart diagrams does not make sense - bad use of UML!

We wrote the state machine as an FSM diagram and studied the code and
realized that they
had not designed from a formal model, just an enumeration of all the
states they had
thought of, and so we went back to verify that it all was consistent, and
it wasn't. But
when we wrote our critique, the answer came back that "the design is
complete and we have
the UML diagrams to prove it", and it took weeks of arguing with their
manager that the
code was wrong before he was willing to accept that the code couldn't
work. We finally
generated a test case that locked the code up into a non-recoverable
state. Since this
code would run in an embedded system, this would have been a serious bug
requiring a
massive recall, had it actually shipped.

Sounds like they didn't know what they were doing!

I've hit a lot of UML "True Believers" and as far as I can tell, every one
of them thought
that if they used UML their design would be correct, and in NO case have I
found a correct
design as a result. In these cases, the code accurately reflected the
design, and the
code was uniformly wrong. In addition, it usually reflected fundamental
bad design such
as violation of abstraction boundaries, poor control constructs, poor data
abstraction,
and so on.
joe

Sounds like you don't like the UML due to bad experiences, but I would like
to defend the language as it is simply that - a modelling language. It has
industry wide acceptance, but unfortunately not everyone in the industry
uses it properly and/or knows what they are doing! I should include myself
in the last category over this particular problem!!

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Humble opinion on UML
    ... I am not a real developer, but I use it sporadically since 1998 and I ... Even if one decides to employ OO techniques for a small application, it is even less likely that UML would be worthwhile for anything other that informal communication or sketching out design ideas. ... Activity Diagrams have been largely replaced by Abstract Action Languages because they are much easier to modify. ...
    (comp.object)
  • =?windows-1252?Q?Re=3A_13_reasons_for_UML=92s_descent_into_darkness?=
    ... This happened because UML was ... Lots of programmers instinctively ... code generation you have to be able to represent specific language ... diagrams: you need to read the code to understand what the diagrams ...
    (comp.databases.pick)
  • Re: Interface usage best practices
    ... > The dynamics of the physical elements of the design. ... anything one does with software can be described with existing UML. ... >>and unambiguous semantics. ... On the standard side, the squiggle definitions and the organizational ...
    (comp.object)
  • Re: OOSE is outdated ?
    ... I have finished reading most of OOSE. ... I see most of the book has only theory + diagrams only and I experienced ... authors deal with other topics like application partitioning and design patterns today. ... OOM & D with UML - Rumbaugh ...
    (comp.object)
  • Re: LSP and subtype
    ... relevant to 3GL and OS design because the level of abstraction is already so far above the hardware. ... Turing-completeness is the context where the "software design" has meaning. ... What is the class of problems solvable using UML? ... wants to solve the problem on a Turing machine. ...
    (comp.object)