This Webel zone is dedicated to providing an alternative subset of documentation for the Drupal™ (home http://drupal.org) Content Management System (CMS), employing Dr Darren's "Snippet-Driven Engineering" strategy, combined with Dr Darren's UML™ Parsing Analysis strategy.
I am calling this project
DrUML (pronounced 'droo-em-el', with intonation like 'U-M-L'.)
The educational aim is to transform carefully selected portions of core and contributed module documentation from Drupal.org into systematically analysed snippets (usually sentences), where each Snippet gets to its own "focus" node (served as a web page), mostly also with UML™ diagrams to complement text analysis, live examples, test results, testing and editorial flags.
These
DrUML Snippet pages are also to form the basis of a new advanced
Drupal course offered by
Webel, and also serve as educational demonstrations of the
UML™ Parsing Analysis and
«wrapper» Component principles (and hence the enormous effort).
Every single Snippet must also under this recipe find some expression as a live (online or reported) example, or must at least be bound clearly to passive artifacts of a live example somewhere. No exceptions ! Because Snippet-Driven Engineering is also a recipe that promotes testing and software integrity, and the motto of UML™ Parsing Analysis is: "making words run".
Q: Do I need to understand Unified Modeling Language™ (UML™) to benefit from this DrUML project ?
A: No. Many examples will use plain screenshots from Drupal web interfaces and other accessible artifacts, and many of the UML object diagrams will be as easy to understand as database table entries.
Q: Why don't you put DrUML on Drupal.org as a project or module ?
A: Because I use custom Snippet types as analysis templates (one node per Snippet), with custom flags, and highly customised delivery of graphics (esp. for UML diagrams) and rich media.
The
DrUML project sits downstream from
Drupal.org, and it consumes sentences from the online docs there. You might like to think of it "spying" graphically on Drupal.org docs, snippet by snippet, applying a systematic analysis recipe per retrieved snippet.
So why do this at all, and why now ?
I am obviously fed up with errors in core and contributed Drupal modules that I know could be avoided by better (or at least some) use of many common software design patterns, better object-orientation, and certainly better documentation, which I insist should be digitally bound to software artifacts as tested evidence.
I can't stand much of the way Drupal is coded and I can't stand a lot of the documentation, it drives me up the wall, and it wastes as much time sometimes as coding it from scratch would (which I would rather do in Java anyway, under UML-driven engineering, although I can do at least some reversing of "typeless" PHP into UML). I can't stand (am frankly now quite allergic too) certain aspects of the Drupal6 API and coding styles, and to the old hook system, and I am disappointed that so much of this culture is seemingly perpetuated in Drupal7.
PHP offers some very powerful object-oriented opportunities, and I feel they are not being embraced sufficiently by the Drupal.org community. PHP offers some powerful yet dangerous and often unnecessary opportunities to perform hacky tricks with functions passed as strings (names), and these I consider are being abused in Drupal core and contributed as a matter of bad habits that I would wish changed, and this includes the ancient, dare I say primitive, so-called hook system. For this UML+Java devotee, coding against the Drupal API is simply painful.
I have let my ongoing frustration with many aspects of Drupal code and API (core and contributed) and with Drupal.org and other Drupal docs show in many issue reports recently, and it has clearly upset some module maintainers and contributors (who never forget to remind me that they are unpaid and that the software is free, and I never forget to remind them that this all of course shows as bugs and documentation errors, and that it costs me lots of time and money fixing it or getting it fixed). After over 30 years of programming and working with software, I am truly fed up with the free Open Source "deal", and that includes Drupal™ (even though I use it for this site and many others).
So with this DrUML project I am taking that frustration off Drupal.org and channelling that energy into constructive demonstrations for those who are interested in strongly document-driven engineering and graphical Unified Modeling Language™ (UML™) and Systems Modeling Language (SysML), too.
This project can help fix many problems with Drupal, and it is currently entirely self-funded by Webel (UML-interested sponsors are most welcome). The scope is not yet very ambitious, I just want to map selected core and contributed Drupal docs to an analysis layer (with UML™ Parsing Analysis support) and to some live examples and tests. However, with an ongoing sponsor, which I hope this project attracts, I can very positively influence the future of Drupal™ CMS with this DrUML project.
I have been planning for years a major educational demonstration of Snippet-Driven Engineering and UML™ Parsing Analysis for Webel based on the Drupal CMS (precisely because it does not have graphical UML™ support), and the time to begin that demo is now.
If I get far enough into the analysis layer represented by the DrUML project, I want to then generate a consistent Java design/implementation layer, which I call the JUML project
(which is clearly much more ambitious). Please visit also:
[ANNOUNCEMENT]: the JUML project: a Java mapping of Drupal under UML Parsing Analysis of Drupal.org
And I encourage everbody who uses Drupal™ to also visit A Messy Breakup with Drupal (Least Worst, Part 1) by Sean Coates. I know just how Sean feels. It need not be so hard.
Yours Systematically,
Dr Darren Apr 2010 (for Webel IT Australia, Bondi, Sydney).
