In Webel's recipe for modelling reverse engineered PHP the analysis is always, without exception, performed on «!wrapper» Components, which are a sub-stereotype of «!analysis».
The «!analysis» Packages "observe" the design(ed) reverse engineered PHP Classes and Interfaces.
Analysis @Interfaces must always «trace» to a reverse engineered PHP class.
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 included, it is prefixed with '?' (as in begs the question).
Analysis diagrams may pull in design(ed) elements (but not vice-versa).
Analysis «!wrapper» @Components may have Associations to other «!wrapper» @Components and «!analysis» @Interfaces. They must never have method return types or parameter types that refer to (preferrably) an @Interface, or (when dealing with factories) concrete implementation @Components.
A Webel «!wrapper» @Component for PHP mapping of OOE = Object Oriented Examples = One Of Each for Drupal MUST ALWAYS participate in a ComponentRealization with the matching reverse-engineering design class of the same name (without the @), which in MagicDraw UML can be generated by dragging the design Class into the @Component (don't worry, it won't steal ownership of the design Class, it makes a logical relationship). Direction: The arrow of the ComponentRealization MUST appear to "point" at the «!wrapper» @Component, and the ComponentRealization should (at least) be stereotyped by «!enapsulated by». The design(ed) PHP Class is «!enapsulated by» the «!wrapper» @Component in associative Unified Modeling Language (UML).