Java Class Diagram Display Rules


Uploaded by AgileJStructureViews on 22.03.2010

Transcript:
hi I'm Paul Wells from AgileJ
in a previous video
we saw how diagram styles
are a powerful mechanism for controlling what is displayed
and how it's displayed
on a class diagram
and according to project specific rules
however in that video
we only touched on how to
make up your own diagram style
in this video we'll have a look in more depth
at how you go about
defining the rules
which make your own diagram style
now if you take a look at the standard diagram styles which ship with the product
you'll see that (here's one)
you'll see that
there are a few rules that control basic options like
the canvas color and
whether types are
are
displayed qualified unqualified
but after that
you find that there's a list of all
'displays' statements
and you can have as many 'displays' statements as you like
and if you look more closely you can see that they follow a pattern of saying
displays something
using something else
so you can think of them as bindings
between what to display
and how to display it
there's a bit more to it than that but that's the basic idea
so what happens is that as the class diagram is displayed
each Java element is tested against the rules in order
until one of the rules says:
er.. 'yes. I know how this should be displayed'
it's basically the chain of command pattern
what you'll also notice
it's that some of the display rules are to do with
the display of
types, fields and methods and
the rest of the displays are to do with
the display of lines
types, fields and methods are excluded or included
from the rule by something called a 'selector'
if you want to see the selector all you have to do
is click on as you would do following any reference in the
Java editor
so if I click on that one it takes me there to all types; it's not a very interesting one
because it just qualifies
any type
but if we scroll down here we can see there are
ones with a bit more to them, so this is abstract types
and
there it permits only types which are modified as
abstract
there are three
different
separate selectors for types, fields and methods
and there are also
- the equivalent - so they do the selecting they control
'what', erm.. but in the 'how' side of things
how things are displayed
we have something called 'display styles'
and the display styles
there's only two of them
one is for handling types
so if we look
at this one here we have
something called a 'field or method' display style because the information's the same in
both cases
and that's a field or method display style
let's have a quick look at the line display rules
each rule refers to dependency
inheritance or
field lines
UML makes a a distinction between aggregation composition and association
but Java doesn't make that distinction and so we don't do either
you don't have to worry about multiplicity
that gets figured out automatically from the Java model
so one of these rules can be paraphrased as, say,
inheritance lines from one type selector to another type selector
so that would be from the supertype to the subtype
should they displayed in a particular color
and that's useful where you are interested in highlighting all of the inheritance lines for
one particular collection of classes
There's another aspect to the definition of diagram styles
they themselves
have an inheritance mechanism mechanism
of their own
this is very useful because, as is always the case with inheritance
it means that you don't have to have a definition
of all these rules from scratch
every time you make a new diagram style
you can't just pick an existing diagram style
which is more or less what you require
and then add some additional rules of your own
ok - remember the
chain of command
pattern usage I just mentioned?
well the way it works is first of all it looks for a matching rule in
your diagram style definition
if there's a match then all well and good
it doesn't find a match
that it checks the
inherited diagram style then
the checks through the rules down inside there
and that applies for
display of
Java elements
add to that the display of
lines
one other issue is - how do you actually hide lines or Java elements?
well it's worth pointing out that
if you don't supply a displays rule the it will fall off the end of the chain of command anyway
and by default it won't get displayed
but what if the diagram style which you are inheriting from
what if that
diagram style
does have a
display rule?
well in that case you use something called
a 'hides' rule
and a hides rule is syntactically similar to a displays rule
but with the difference that obviously you don't
need to
supply a display style
you just say what it is that you want to hide
so we've spent quite a long time now looking at the configuration language itself
and once you get your heard around how it declares
what to display using selectors
and how to
display it using display styles then hopefully
you'll want to have a go at defining your own diagram styles
geared up for the needs of your own project
however what you'll almost certainly find at some point is that
after you've created your own diagram style
it won't work in the way you expect
that's actually quite normal
we found that when we created the standard diagram styles that ship with the product
they often wouldn't work as we expected
normally because of a selector not working as intended or...
because it would
fall off the chain of command and then hit a different displays rule
either too early or to late or not at all, and...
it just doesn't display the Java element as you'd expect it
or the line between two Java elements
so we build a debugger
and I'll show you next how to use the debugger
so to get to the debugger
go back to the diagram
right click on empty space and select
configuration debug
and the
dialog which opens is a tree of every Java element which you have on the diagram
and not just the top level but the members
you can drill down inside here
and
if you
select one of them
and then select this tab here
'configuration debug'
what it produces is a
diagnostic of
how it arrived at the decision to display
that elements in the way that it did
so you get these parts here which are just narrative and tells you what...
what it's thinking on the inside
so here it's saying that it's been asked to match a
display style for
this method called 'normalize' that's the er...
that's the element that we're looking at
which is the er
Vector.normalize() method
and you can see that it went through
and it
didn't find a match in the
hideConstructors
diagram style
so then it got passed
via the inheritance through to the default diagram style and
got passed through and
and it
matched this
method selector here here which is called 'allMethods'
if you drill down inside you can see how it matched it it actually matched it by name
and because it matched
then the outcome was it decided to use it
and so
it's
matched it so the binding has
then been resolved to
this display style.