The Webel wrapper Component analysis and design modelling strategy is a Unified Modeling Language (UML) modelling recipe developed over many years by Dr Darren of Webel IT Australia. It is employed here to provide a clean separation and traceability between reverse-engineered "design(ed)" PHP Class elements (from the OOE = Object Oriented Examples = One Of Each tutorial module for Drupal7) quarantined in «!design» Packages and «!analysis» elements that may refer to them.
It leverages the graphical encapsulation and UML relationship capabilities of the UML2 Component, especially the ComponentRealization, to logically analyse the reverse-engineered PHP design(ed) elements without affecting ("stealing") the ownership (packaging) of those design(ed) elements.
The representation of reverse-engineered PHP elements in UML is limited both because of the weakly typed nature of PHP and because of the inability of tools like PEAR PHP UML to extract some of the type-hinting information from documentation (and in this case Drupal7 style documentation). The «!design» elements are therefore not able to participate directly in associative graphical UML modelling. Instead, in the Webel recipe, each reverse-engineered PHP «!design» Class is wrapped in (via an «!encapsulated by» ComponentRealization) a special UML2 Component called an analysis «!wrapper» Component, which may participate fully in associative graphical UML modeling, along with «!analysis» Interfaces that «Trace» to the reverse-engineered Interfaces.
- All Webel stereotypes for the OOE = Object Oriented Examples = One Of Each UML models are in a stereotype profile 'ooe' and are prefixed with an exclamation mark '!'. This enables easy identification of Webel stereotypes and easy selection through prompting on the '!'. Examples include: «!refactor», «!encapsulated by» , «!analysis», «!wrapper» (which BTW extends «!analysis»), «!drupal», «!hook», «!magicdraw», «!mixin», «!injected», etc.
- Every analysis element is under the special top-level '@' «!analysis» Package and every analysis element is prefixed with an '@'. As a convenient shorthand a «!wrapper» analysis Component is sometimes referred to as a @Component and an «!analysis» Interface is sometimes referred to as an @Interface.
- Interfaces always, without exception, and explicitly unlike the Drupal coding standard for OO coding, are prefixed with an 'I', instead of having 'Interface' as a suffix. This enables far more compact UML modelling, it enables prompting on the 'I' to find interfaces, it helps organise interfaces (alphabetically after the 'I' prefix), and it saves a lot of typing ! This interface notation naming convention for OOE = Object Oriented Examples = One Of Each will not under any circumstances be changed to the Drupal coding standard, which was never designed to be UML-friendly.
- Analysis interfaces are additionally prefixed with an '@', thus '@IBlock' is the «!analysis» Interface with a UML «Trace» to the reverse-engineered PHP 'IBlock' Interface.
- Methods/operations of analysis «!wrapper» @Components and «!analysis» @Interfaces may only refer to «!analysis» @Interfaces in parameter types and return types, reverse-engineered PHP «!design» Interfaces ! This is because the handling of types and multiplicity in reverse-engineered PHP is not safe for use in associative UML modeling.
As an interim description of the remainder of the policies and conventions of the Webel UML wrapping Component recipe (as applied to OOE = Object Oriented Examples = One Of Each for PHP-driven Drupal7) the view of dual-linked policy and convention notes serves quite well, and includes links to UML diagram pages for elements illustrating them:
Notes are reusable content pages that encapsulate a policy, recommendation, or tip. A Note knows what content pages it has been applied to (and vice-versa). Notes help promote the Don't Repeat Yourself (DRY Principle) principle.