Q: What is the gist of the Webel modelling recipe for UML as applied to PHP ?

There are 2 main types of elements in a Webel UML for PHP project:

- Design(ed)' software engineering elements (mostly Classes, Interfaces and their related PHP code Artifacts), which are always reverse engineered (in this case using PEAR:PHP_UML) from PHP code. Even with very precise and consistent coding and documentation patterns, PEAR:PHP_UML can't completely reverse engineer every aspect of the code into the UML model, so full-cycle UML modelling with PHP is NOT attempted.

- Analysis systems engineering elements (mostly «!wrapper» analysis @Components and «!analysis» @Interfaces). A «!wrapper» @Component is very closely related to a reverse-engineered Class, but it is not identical to it. A UML2 Component has some very special and powerful capabilities beyond a plain UML Class, and the Webel modelling recipes for UML make heavy use of these extra capabilities.

A «!wrapper» Component is free to use completely consistent or freestyle UML modelling - independent of any implementation language like PHP - and if desired, it can even be transformed to use the Systems Modeling Language (SysML) systems engineering dialect of UML (although the official OMG SysML only uses Class elements as SysML Blocks, in MagicDraw SysML you can also use Components as MD SysML Blocks in MagicDraw projects).

Each «!wrapper» @Component is hyperlinked to a dedicated Focus Class Diagram (if it is wrapping a helper class with only static helper methods) or a Focus Implementation Diagram (if it is wrapping a Class than implements an Interface). A @Component focus diagram shows the relationship of the focus element to its immediate neighbouring elements (which may come from different design(ed) Packages or analysis Model packages), as well as its focus design(ed) Class, which is related to it through a Component Realization relationship.

The wrapped "design(ed)" Class is denoted as «!encapsulated by» the analysis «!wrapper» @Component (or simply «!by» for shorthand). On reverse engineering the XMI model file from PEAR:PHP_UML into MagicDraw UML, a «manifest» relationship is generated from a 'source' Artifact representing a PHP file to the "design(ed)" Class. Thus ultimately every «!wrapper» @Component can be traced back to a PHP code file in the model !

An analysis @Interface Focus Diagram shows how an «!analysis» @Interface is related to a reverse-engineered "design(ed)" Interface. It may show the details of its operations (and any attributes if used). However, it is crucial that the signature of an «!analysis» @Interface operation does not contain any (that means none, zip, zero) parameters typed by "design(ed)" elements ! It must always reference either (ideally) other @Interface types, or if the system is under migration to full OOP it may under certain circumstances reference @Component analysis types. An @Interface Focus Diagram will usually show a default «!wrapper» @Component implementation, but it it should not usually show any operations or attributes of that «!wrapper» @Component , as those are implementation details subject to change (and may well change without any impact on the @Interface).

Package Overview class diagrams tend to show few or no attributes or operations, and if they do show operations at all they usually only show them without detailed operation signatures; to find out details of an analysis @Component and its underlying attributes and operations examine its dedicated Focus Class/Implementation Diagram.

Pure «!analysis» diagrams do not show ANY reverse-engineered elements, i.e. no "design(ed)" Classes or Interfaces, they only show «!analysis» elements. A Focus Class/Implementation Diagram for a «!wrapper» @Component is however a special hybrid analysis/design diagram, because it always contains at least one reverse-engineered Class (the focus Class of the focus «!wrapper» @Component).

Visit also