Patricia said:
Stefan Ram wrote:
...
I have a variant on this. I often don't actually write the code, but I
spend a lot of time imagining the outlines of the code. Especially if
I'm working in a language I know well, I can often think up mid-level
structures that I know I could program, if they turned out to be useful.
I then think of the high level design in terms of those mid-level
structures.
To describe the elephant from yet another projection, I use a combination
of intuitive and cognitive models derived from the linguistic space of the
application domain.
The intuitive portion matches domain-specific language ("TPS Report") with
a ready-to-hand skill set of noun-verb object metamodels.
"Hmm, a report /has-a/ {title, ...}, /is-a/ {Retrievable, Readable, ...}."
The metamodel is the idea of "/has-a/" and "/is-a/", the notion of objects
having types, attributes, and behaviors, and the toolbox containing
polymorphism, assertions and all the panoply of design and programming skills.
Mixing in or out aspects such as functional programming is rather a mind
twist, but really an extension of the metamodel. I use different programming
languages, so I will slot in architecturally parallel constructs such as
first-class functions vs. SAM interfaces to the same spot in the mental
model.
I've got in trouble with certain managers for using skeleton Java interfaces
to generate UML diagrams, because "it isn't time to code yet; we're doing
diagrams". I defended my approach as being at the same level of architectural
design as diagramming, and consonant with how a programmer thinks. They let it
go.
Begrudgingly.
But it was exactly what Patricia describes. If you think structurally, it might
look like code - but hey, structure's structure however you describe it.
You sketch what you can see, try it as quickly as you can get a prototype up
(hours, not days), and proceed in however fashion you proceed to fill in the
details.
As a fillip, I correlate Java elements to UML differently from (and therefore
superior to, by my definition :-') some. Java idiomatically, and
controversially, exposes all attributes as accessor and mutator (getter and
setter) methods. Some diagram 'getX()' and 'setX()' methods as methods under
UML. Tsk. They're still attributes - 'get' and 'set' are just conventions
for expressing their public face. Architecturally, at the level where UML
can hope to do any good, I diagram them as attributes.
I'm not religious about it. If a paycheck is at stake I'll diagram them
as blueberries if you like.