[keyword] !policy

[note] Create "bridge" include files that mediate between the classic Drupal7 hooks of the .module file and OO Class libraries that progressively encapsulate define() data and functions as Class attributes, constants, and Interface/Class methods

Type:

Applies to

[note] PHP 'use' statements in a PHP include file or class/interface file are modelled using the UML Usage «use» relationship (from a «!wrapper» @Component corresponding to the file that has the 'use' statement to a «!wrapper» @Component for a Class/Interface).

Type:

Applies to

[note] UML PackageImport «import» relationships are used to model analysis dependencies between Packages/Models. They do not correspond to a PHP artefact, but do imply that a contained element has a matching PHP file with a PHP 'use' to a file in the target.

Type:

Applies to

[note] UML ElementImport «import» relationships are used to model Drupal7 'file' includes for hook_menu() and hook_theme()

Type:

Applies to

[note] An analysis @Component may replace weakly specific PHP 'object' parameter types with stronger placeholder analysis @Interfaces in its operation signatures.

Type:

Applies to

[note] OOE: a get() method always returns a Drupal array or string; it means you are leaving the purely object-oriented OOE world and entering the Drupal world of structured PHP arrays enforced only by convention and documentation.

Type:

By a get() method is not meant a property getter, it means literally 'get()' with no arguments and only 3 letters in the method name ! The get() methods are how OOE talks to Drupal core, they assemble everything to return a valid Drupal array (or string).

The UML signature is always one of:

«!drupal» get() : array
«!drupal» get() : string
«!drupal» get() : string|array

[note] OOE: The only class that is ever allowed to extend AbstractProject and implement IProject directly is the CurrentPosts demo, which uses an "old" non-OO style page callback to a function in the .module file ! It is a counter-demo !

Type:

Applies to

[note] OOE: If you want to use a project you should ALWAYS extend AbstractControlledProject (not AbstractProject) so that you have an OO page controller !

Type:

Applies to

The only exception is the CurrentPosts example, which deliberately extends only AbstractProject and uses an explicit page callback function in the .module file to show you the "old" non-OO way of doing it.

[note] Webel/OOE: delegate methods (such as hook and handler implementations) of an OOE bridge Class SHOULD use lower_case_underscore_separated() [not camelCase()]. All other Classes and Interfaces should use camelCase() for operations/methods (as per Drupal8).

Type:

Applies to

A Webel module bridge for Drupal consists of a special Drupal .module file (say 'ooe.module') and a Webel Drupal-PHP-bridge implementation Class such as OoeBridge for the main OOE = Object Oriented Examples = One Of Each tutorial module.

This enables one to (code modules for Drupal7 in a truly, purely object-oriented PHP and (best of all) one can then also model the module system in graphical Unified Modeling Language (UML) !

[note] In the UML-friendly Webel PHP Interface names are always prefixed with capital 'I' thus ICamelCase ! This has many advantages for graphical UML modelling and IDE based prompting (and saves typing) This is knowingly NOT the Drupal coding standard !

Type:

Applies to
This policy is immutable, to work with the OOE = Object Oriented Examples = One Of Each tutorial module and reap all the advantages one must use this naming convention. It is NOT a Drupal7 convention, it is a Webel OOE convention !

[note] In the Webel recipe for modelling PHP all associative UML modelling is performed with «!wrapper» @Components in special, completely separate «!analysis» packages

Type:

Applies to

[note] Analysis «!wrapper» @Components may extend (have Generalization relationships) to other «!wrapper» @Components (only, not to PHP design Classes); Similarly, «!analysis» @Interfaces may only extend other «!analysis» @Interfaces.

Type:

Applies to

[note] Webel: If any of the «!analysis» @Interfaces or «!wrapper» @Components have Association relationships to any design(ed) PHP Class or Interface elements, the analysis wrapper UML model is broken !

Type:

Applies to

[note] In the Webel UML analysis recipe for PHP, the ComponentRealization between a design(ed) PHP Class and its «!wrapper» @Component (pointing at the «!wrapper» @Component) should (at least) be stereotyped by «!encapsulated by» (even if it is not displayed).

Type:

Applies to

[note] Analysis @Interfaces and wrapper @Components must have operations/methods with method parameter types and return types that (preferrably) refer to an @Interfaces or concrete implementation @Components. They may also use 'void', PHP scalars, and array.

Type:

Applies to

[note] Webel: No modelling is ever performed directly on reverse-engineered design classes, and no design Package may ever by changed during analysis ! However, an analysis element may carry, for example, a Dependency or Usage to a design element.

Type:

This is necessary because the XMI generated by PEAR PHP UML does not integrate with the MagicDraw UML code engineering sets system, one can however import the XMI (into the design packages).

It is best not to put a single element, not a diagram, no relationships, nothing, that changes the design(ed) packages ! Instead, you use analysis diagrams, under the '@' analysis package root, to pull in design elements where appropriate.

[note] In Webel's recipe for UML modelling of reverse engineered PHP, the analysis is always, without exception, performed on «!analysis» @Interfaces and «!wrapper» @Components - where «!wrapper» is a sub-stereotype of «!analysis».

Type:

Applies to

[note] Analysis «!wrapper» @Components may have Associations to «!analysis» @Interfaces (preferrably injected or obtained from a factory) or other «!wrapper» @Components (if creating say default implementations).

Type:

Applies to

[note] The entire Webel «!wrapper» @Components analysis of the One Of Each (OOE) project is under a special top-level the «!analysis» @ Package.

Type:

Applies to

This simple policy is extremely important and effective for graphical Unified Modeling Language (UML) models of reverse engineered PHP using PEAR PHP UML. Advantages include:

- Clear separation of the analysis packages/models from reverse-engineered PHP design class representations (imported by MagicDraw UML from the reverse-engineered PHP UML XMI file).

- Clear indication that an Element is an analysis element (even when no stereotype applies).

[note] Analysis diagrams may pull in design(ed) elements (but not vice-versa).

Type:

Applies to

This is because in my current combination of MagicDraw UML with PEAR PHP UML the only way I have found to consistently include coding changes to the PHP classes in the MD UML model is to Import From > Another Project .. where the other project is the reverse engineered XMI2 file generated by PHP UML.

[note] Analysis «!wrapper» @Components and «!analysis» @Interfaces are always prefixed with '@' (in addition to the design class name), except: when a new refactoring ?Class or ?Interface is suggested it is prefixed with '?' (as in "begs the question").

Type:

Applies to

This simple policy is extremely important and effective for graphical Unified Modeling Language (UML) models of reverse engineered PHP using PEAR PHP UML. Advantages include: -

- Easy prompting for analysis elements in a UML tool without any risk of hitting reverse-engineered PHP design(ed) elements (Classes/Interfaces/Artifacts).

- Makes it clear in all diagrams which elements are analysis and which are reverse-engineered design(ed) elements, no matter whether the owner/context or stereotypes are shown.

[note] A «!wrapper» @Component MUST ALWAYS participate in a ComponentRealization with the matching reverse-engineered design(ed) PHP Class of the same name (without the @). The arrow of the ComponentRealization MUST appear to point at the «!wrapper» @Component.

Type:

Applies to

[note] OOE «analysis» @Interfaces (within the @ «analysis» Packages) must always «Trace» to a reverse engineered PHP design Interface (from within PHP UML "design(ed)" Packages) !

Type:

Applies to
Subscribe to RSS - !policy