C++ and Design certification

[neelsmail]

Hi,

I have been working on C++ for some time now, and I think I have a
flair for design (which just might be only my imagination over-
stretched.. ). So, I tried to find a design certification, possibly
that involves C++, but, if not, C++ and UML. All I could find was Java
+ UML design certifications (one such is detailed on
http://www.objectsbydesign.com/tools/certification.html). Although UML
is expected to be language independent, if the certification itself is
Java + UML, I cannot expect to be able to pass it since I am only a
beginner in Java.

Is there any exam/certification which evaluates one's design
capability in object oriented design without any language or design
capability in C++?

Thanks in advance,
Neel.

 

[Alf P. Steinbach]

* (e-mail address removed):

Hi,

I have been working on C++ for some time now, and I think I have a
flair for design (which just might be only my imagination over-
stretched.. ). So, I tried to find a design certification, possibly
that involves C++, but, if not, C++ and UML. All I could find was Java
+ UML design certifications (one such is detailed on
http://www.objectsbydesign.com/tools/certification.html). Although UML
is expected to be language independent, if the certification itself is
Java + UML, I cannot expect to be able to pass it since I am only a
beginner in Java.

Is there any exam/certification which evaluates one's design
capability in object oriented design without any language or design
capability in C++?

I don't know of one. Any existing one would be bogus, in the sense of
lying to you and others about evaluating your design skills. Design is
the application of intelligence, and judging the result(s) is a matter
of seeing whether the design stands up in actual usage and, not the
least, wrt. maintenance, and that can't be done via an exam, except to
say that this or that design really and obviously sucks. There is
seldom any single right or even right answer to a design question,
although there are an infinity of clearly wrong answers.

If you find design interesting, then that's good: programming in C++ is
all about design. So if you think you have a flair for C++ design, then
you're really thinking you have a flair for C++ programming. The
question you should be asking, given what you mention above, is then
whether you're far more happy at the UML level than at the C++ code
level; for if so, it may be you're deluding yourself, but if you're also
happy at the C++ code level, and can switch at will, translating one to
the other effortlessly in your mind, then you're probably not mistaken.

About "programming in C++ is all about design": read up on what e.g.
books like "Modern C++ Design" are all about. They're 95% about C++
code. Much of the design is driven by considerations of C++ code
safety, efficiency, portability, maintainability, and so forth, and not
the least, C++ code clarity -- maximize, and you have a good design.

 

[James Kanze]

* (e-mail address removed):

I don't know of one. Any existing one would be bogus, in the sense of
lying to you and others about evaluating your design skills. Design is
the application of intelligence, and judging the result(s) is a matter
of seeing whether the design stands up in actual usage and, not the
least, wrt. maintenance, and that can't be done via an exam, except to
say that this or that design really and obviously sucks. There is
seldom any single right or even right answer to a design question,
although there are an infinity of clearly wrong answers.

It's possible to evaluate certain aspects of a design
beforehand. And even if the certification only worked to
eliminate the totally incompetent, it would be useful.
(Generally, from what I've seen, such certification only works
to eliminate those not willing or able to pay the fees. Which
really isn't a useful criteria.)

If you find design interesting, then that's good: programming in C++ is
all about design. So if you think you have a flair for C++ design, then
you're really thinking you have a flair for C++ programming. The
question you should be asking, given what you mention above, is then
whether you're far more happy at the UML level than at the C++ code
level; for if so, it may be you're deluding yourself, but if you're also
happy at the C++ code level, and can switch at will, translating one to
the other effortlessly in your mind, then you're probably not mistaken.

UML and C++ complement each other, and I would never start
coding an application without having done some design (in UML)
first. C++ is, first and foremost, and implementation tool, not
a design tool.

About "programming in C++ is all about design": read up on what e.g.
books like "Modern C++ Design" are all about.

About the only "design" in "Modern C++ Design" is in the title.
The book is mainly about implementation techniques; any design
considerations are limited to low level interface design, or
detailed design of specific components. C++ design, in sum, and
not application design. (E.g. how to design a shared pointer,
but not when to use one.)

They're 95% about C++ code. Much of the design is driven by
considerations of C++ code safety, efficiency, portability,
maintainability, and so forth, and not the least, C++ code
clarity -- maximize, and you have a good design.

You need high level design first.

 

[Alf P. Steinbach]

* James Kanze:

UML and C++ complement each other, and I would never start
coding an application without having done some design (in UML)
first.

I don't like the way UML is abused because the idea of a conforming
rigidly to a standard notation is in direct conflict with the need to
express higher level concepts, and because it's an ungood compromise
(the "U" is the unification of Booch notation and two others whose names
escape me right now). Also, the tool support is still very poor, or
alternatively, tools (e.g. Rational Rose licenses) are not exactly
cheap. But, some UML-like illustrations, and UML generated from code,
can sometimes be nice.

C++ is, first and foremost, and implementation tool, not
a design tool.

Depends what you mean by design. There are many levels and shades of
purity of design. And design does absolutely not need to be only
annotated graphics created via an UML-based tool (limiting oneself that
way would be like donning a straightjacket before starting the job).

About the only "design" in "Modern C++ Design" is in the title.

I think Andrei would disagree, since presumably he chose the title... ;-)

The book is mainly about implementation techniques; any design
considerations are limited to low level interface design, or
detailed design of specific components. C++ design, in sum, and
not application design. (E.g. how to design a shared pointer,
but not when to use one.)


You need high level design first.

There are many levels of design. "Design" by itself means the whole
thing. And does not imply a phase in a waterfall methodology.

 

[Ian Collins]

UML and C++ complement each other, and I would never start
coding an application without having done some design (in UML)
first. C++ is, first and foremost, and implementation tool, not
a design tool.

Well that depends on what you consider design and how you go about it.
If you practice Test Driven Design, the language is a design tool, in
the form of tests cases.

 

[JohnQ]

Hi,

I have been working on C++ for some time now, and I think I have a
flair for design (which just might be only my imagination over-
stretched.. ). So, I tried to find a design certification, possibly
that involves C++, but, if not, C++ and UML. All I could find was Java
+ UML design certifications (one such is detailed on
http://www.objectsbydesign.com/tools/certification.html). Although UML
is expected to be language independent, if the certification itself is
Java + UML, I cannot expect to be able to pass it since I am only a
beginner in Java.

Is there any exam/certification which evaluates one's design
capability in object oriented design without any language or design
capability in C++?

"C++ design" is an oxymoron. The language is not conducive to "design"
(something that should be language-independent) because the complexity of it
keeps your mind in the solution space (the language details) instead of the
problem space (the thing you want to actually build!). The
"platform-independence" (a.k.a., a PITA on any platform in practice) and
"backward compatibility" (a.k.a., perpetuation of obsolete ideas and worst
practices) is becoming more and more too big of a pill to swallow.

That said, I think I know what you meant though. I just used your post as a
springboard to make the oxymoron point. "Small C++" may be "a language that
facilitates higher level design".



John

 

[Ian Collins]

"C++ design" is an oxymoron. The language is not conducive to "design"
(something that should be language-independent) because the complexity of it
keeps your mind in the solution space (the language details) instead of the
problem space (the thing you want to actually build!).

Nonsense, just write the tests and let the design find its self. Same
in any language.

 

[JohnQ]

Nonsense, just write the tests and let the design find its self. Same
in any language.

That doesn't sound like design to me at all. It sounds like some kind of
inductive reasoning way of sneaking up on a design (_hoping_ that one will
emerge). The program may behave as desired, but good architecture/design may
indeed be lacking in the final product. It seems ludicrous to me to think
that just having specifications and adherance to them in the final product
would somehow automagically produce a good architecture/design.

John

 

[Ian Collins]

That doesn't sound like design to me at all. It sounds like some kind of
inductive reasoning way of sneaking up on a design (_hoping_ that one will
emerge). The program may behave as desired, but good architecture/design may
indeed be lacking in the final product. It seems ludicrous to me to think
that just having specifications and adherance to them in the final product
would somehow automagically produce a good architecture/design.

You'd be surprised.

It also gives the customer what they want, no more, no less; which is
the best way I know to get paid and generate repeat business!

 

[JohnQ]

You'd be surprised.

Indeed I would!

It also gives the customer what they want, no more, no less; which is
the best way I know to get paid and generate repeat business!

Until maintenance time: "who wrote this spaghetti?!". This is a silly debate
to have. It does not follow logically in any way that "test-driven
development" or "adherence to specifications" are conducive to achieving a
"good" design nor any architecture at all (indeed, the design and
engineering steps may have been compromised or eliminated!).

John

 

[Ian Collins]

Until maintenance time: "who wrote this spaghetti?!". This is a silly debate
to have. It does not follow logically in any way that "test-driven
development" or "adherence to specifications" are conducive to achieving a
"good" design nor any architecture at all (indeed, the design and
engineering steps may have been compromised or eliminated!).

Don't knock it until you try it.

 

[JohnQ]

Don't knock it until you try it.

Apples and oranges. I'm as likely to try to get architecture out of TDD as I
am using chants and incense for the same.

John

 

[Ian Collins]

Apples and oranges. I'm as likely to try to get architecture out of TDD as I
am using chants and incense for the same.

Then stick with what you know and leave TDD to those of us who know what
we are doing.

 

[JohnQ]

Then stick with what you know and leave TDD to those of us who know what
we are doing.

And when that architecture producing miracle forms from the concepts of TDD,
you will let me know, won't you?

John

 

[James Kanze]

* James Kanze:

I don't like the way UML is abused because the idea of a conforming
rigidly to a standard notation is in direct conflict with the need to
express higher level concepts, and because it's an ungood compromise
(the "U" is the unification of Booch notation and two others whose names
escape me right now). Also, the tool support is still very poor, or
alternatively, tools (e.g. Rational Rose licenses) are not exactly
cheap. But, some UML-like illustrations, and UML generated from code,
can sometimes be nice.

Yes. It's important not to loose sight of the goal, which is
the design, or the documentation of the design, and not using
such and such a tool. On the whole, I find UML a good basis,
although I'm quite flexible with regards to how it is used; if
parts of the design can better be expressed using other means,
so be it.

And you're right about tool support. (IMHO, IBM would be wise
to follow the example of Unix, and make the Rational product
line available free, or almost free, to schools. All of the
students coming out knowing Rational Rose, and the companies
which hire them would have to cough up for the licenses.)

Depends what you mean by design. There are many levels and shades of
purity of design. And design does absolutely not need to be only
annotated graphics created via an UML-based tool (limiting oneself that
way would be like donning a straightjacket before starting the job).

Design does mean knowing what the code should do before you
start writing it. In large projects, it means knowing what each
class you write does in the context of the project. And in my
experience, you don't "know" anything until it's down in
writing. UML works well for this. I don't know, off hand, of
any viable alternatives. And I've never really felt it to be
much of a straight jacket.

I think Andrei would disagree, since presumably he chose the title... ;-)

Maybe. But at the most, it's very low level design. My
impression, however, is that it is more about how to write code
which can be used to do anything, without knowing what it might
be used for. Useful for authors of very low level libraries
(who obviously want their code to be used in the widest variety
of applications), but not the sort of thing to get involved in
if you're being paid to produce a working application.

There are many levels of design. "Design" by itself means the whole
thing. And does not imply a phase in a waterfall methodology.

What's the waterfall methodology? I've only seen the expression
used as a red herring for people trying to justify a lack of
engineering. (See http://www.idinews.com/waterfall.html. For
that matter, you might want to check out the entire site:
http://www.idinews.com/. It's one of the best sites I know of
for C++/Java based software engineering.)

Design is a continuous process. It starts before you start
coding---you can't code until a certain amount of design can be
done. The usual model I've seen is a spiral: design, code,
test, then start over, refining the design. But all code is
designed before it is written.

 

[James Kanze]

James Kanze wrote:

Well that depends on what you consider design and how you go about it.
If you practice Test Driven Design, the language is a design tool, in
the form of tests cases.

The language doesn't have the means for expressing higher level
concepts, and of course, you can't even begin to write tests
until you know what you have to test: some form of design. (I
am assuming, of course, that you mean unit tests here, and that
you're not claiming that the only design for a MegaLOC project
is the tests for the entire system.)

 

[Alf P. Steinbach]

* James Kanze:

What's the waterfall methodology? I've only seen the expression
used as a red herring for people trying to justify a lack of
engineering. (See http://www.idinews.com/waterfall.html. For
that matter, you might want to check out the entire site:
http://www.idinews.com/. It's one of the best sites I know of
for C++/Java based software engineering.)

Design is a continuous process. It starts before you start
coding---you can't code until a certain amount of design can be
done. The usual model I've seen is a spiral: design, code,
test, then start over, refining the design. But all code is
designed before it is written.

It seems you think the same as me, but using different language.

Cheers,

- Alf

 

[Ian Collins]

The language doesn't have the means for expressing higher level
concepts, and of course, you can't even begin to write tests
until you know what you have to test: some form of design. (I
am assuming, of course, that you mean unit tests here, and that
you're not claiming that the only design for a MegaLOC project
is the tests for the entire system.)

It really all comes down to what one defines as "design" and this is
often driven by the quality and nature of the requirements. In my
experience, these range from "I want a reporting tool" through to "we
want to replace product X, here are the detailed requirements".

In the first instance, one has to coax the requirements from the user
and the best way to do this is through an incremental, agile process.
The end product may well be a MegaLOC project, but at no point along the
way will anyone have sat down and done an up front design.

 

[JohnQ]

It really all comes down to what one defines as "design" and this is
often driven by the quality and nature of the requirements. In my
experience, these range from "I want a reporting tool" through to "we
want to replace product X, here are the detailed requirements".

In the first instance, one has to coax the requirements from the user
and the best way to do this is through an incremental, agile process.

I see the "flavor of the month" process stuff is still going full force.
Kinda reminds me of when Microsoft decides on a "new" <something> and then
names everything up and down the line in some form of it (the latest being
..Net of course). Looking back, if I would have "kept up" with the
proprietary "technologies", I wouldn't know how to build anything! So what
if I don't know .net? It's just a black box API IMO. But I do know how to
build a memory manager, a database, a point-of-sale system, a GUI etc. (lo
and behold, now I know what I think I want in a programming language and
kinda wanna get that done to make software development easier).

(What sparked my above response was the use of "agile". First one to say
"pair programming" wins a pie in the face).

John

 

[Gennaro Prota]

I think Andrei would disagree, since presumably he chose the title... ;-)

Well, I'm not sure. You snipped the rest of James' statement, where he
says

The book is mainly about implementation techniques; any design
considerations are limited to low level interface design, or
detailed design of specific components. C++ design, in sum,
and not application design.

FWIW, I've always parsed the title as <modern> <C++ design>, not as
"design in modern C++", too. Even before reading the contents. And the
fact that the book isn't about *application design* is quite
incontrovertible IMHO. That's not saying that it wasn't interesting or
useful, of course.