Home > Archive > Software Engineering > May 2004 > Graphical notation for physical design dependencies
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Graphical notation for physical design dependencies
|
|
|
| Does anyone know of a graphical notation for physical design
dependencies?
The closest I could find was the package stuff in UML but this does
not get one very far. I have come across a notation in the book by
John Lakos "Large scale C++ development". It invents a notation but if
there is no established std what else could he do? It is a pity the
notation choses pictures etc that are easily  with other well
established design notations (e.g Rumbaugh).
I realise that this is not the remit of UML since UML is not language
specific and the issues Lakos discusses specifically apply to C++.
Still it would be nice for the industry to agree on a std notation.
Regards,
Andrew Marlow
| |
| Alexei Polkhanov 2004-05-13, 11:31 pm |
| On Thu, 13 May 2004 15:24:13 -0700, apm wrote:
> The closest I could find was the package stuff in UML but this does
> not get one very far. I have come across a notation in the book by
> John Lakos "Large scale C++ development". It invents a notation but if
> there is no established std what else could he do? It is a pity the
> notation choses pictures etc that are easily with other well
> established design notations (e.g Rumbaugh).
>
> I realise that this is not the remit of UML since UML is not language
> specific and the issues Lakos discusses specifically apply to C++.
> Still it would be nice for the industry to agree on a std notation.
>
Perhaps it make sense to have such notation, but consider for example Ada
compiler like GNAT. It is an error to have body of package "MyPackage" in
file named anything but mypackage.adb, or other file named according to
well defined "compression" rules.
C++ standard does not enforce or recommend any relationship between class body
and file name, but it does not mean you should not follow well defined
naming rules. I am familiar with "Large scale C++ development", but in the
book notation is necessary for illustration. In well managed project physical
dependencies should be clear from logical design and hence there should be no
need in notation to document them.
Cheers,
---
Alexei Polkhanov
Sr. Consultant/Software Systems Analyst
Tel: (604) 719-2515
E-mail: usenet@monteaureus.com
http://www.monteaureus.com/
| |
| Alan Gauld 2004-05-14, 3:31 am |
| On 13 May 2004 15:24:13 -0700, apm35@student.open.ac.uk (apm)
wrote:
> Does anyone know of a graphical notation for physical design
> dependencies?
What kind of physical dependencies?
Booch usd to have a rich notation for this but UML has diluted it
significantly, however you can show dependencies in UML.
> The closest I could find was the package stuff in UML but this does
> not get one very far.
I'd use components for physical dependencies rather than
packages, packages are esentially just a grouping mechanism in
UML. You could use packages with stereotypes to show groups of
classes in a file, or groups of files in a library etc.
But if you are trying to show dependencies between files in the
sense that library X will only work if library Y is also
installed then that's probably better done with components.
Similarly for the dependencies between processes.
And of course deployment diagrams coupled with component diagrams
show geographic physical dependemncies...
> I have come across a notation in the book by
> John Lakos "Large scale C++ development".
Don't know the book, but what particular type of dependency does
his notation show? Documenting physical dependencies is obviously
one of the most important types of documentation for downstream
maintenance and operations teams. But without being clear about
what type of dependency you want its hard to be specific.
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
| |
|
| "Alexei Polkhanov" <usenet@monteaureus.com> wrote in message news:<pan.2004.05.14.02.12.11.243760@monteaureus.com>...
>
> C++ standard does not enforce or recommend any relationship between class body
> and file name, but it does not mean you should not follow well defined
> naming rules. I am familiar with "Large scale C++ development", but in the
> book notation is necessary for illustration.
I think this shows that there is a need to communicate these ideas
from time to time. IMO it would be good to have a std notation for
this. AFAIK Lakos's book is the ONLY one on managing physical design
issues in C++. But hopefully over time there will be others. They will
hit this problem unless it is resolved by then.
> In well managed project physical
> dependencies should be clear from logical design and hence there should be no
> need in notation to document them.
There is not a /pressing/ need for the notation but I maintain that
there is a need. If there was a std then tools could be used to
produce the diagrams associated with a physical desgin by processing
the source files. Perhaps this is something that in the fullness of
time could be added to a tool like doxygen.
-Andrew M.
| |
|
| Alan Gauld <alan.gauld@btinternet.com> wrote in message news:<sto8a0t9ek5bb5hid3c1avfnfjb3s8jpgg@4ax.com>...
>
> Don't know the book,
I am suprised. This book is extremely dated. It uses an old C-like
dialect of C++ with no STL) but it is the definative work on C++ and
physical design (mainly because no-one else has written a book that
addresses the same subject.
> but what particular type of dependency does
> his notation show?
If A depends on B than A will not compile unless it can see the header
for B.
> Documenting physical dependencies is obviously
> one of the most important types of documentation for downstream
> maintenance and operations teams. But without being clear about
> what type of dependency you want its hard to be specific.
I agree that one does not often talk about physical design
dependencies. But not having a notation PREVENTS us from being able to
do so. Lakos found this to be a problem because he needed to talk
about the design issues in his book, and so he came up with his own
notation.
|
|
|
|
|