Even though PHP is not a "strong typed language", PHP_UML relies a set of predefined types (integer, float, string, mixed, etc.) and tries to use them as much as it can guess. By inspecting the default values, the type hints in the functions parameters (when they are present), as well as the docblocks @param, PHP_UML can detect the types of the parameters, constants and properties. When it cannot guess, it assumes that it is the mixed type.

PHP_UML is also aware of a couple of internal PHP classifiers, such as Exception or Iterator (that's why you might see them appear in the API documentation).

What happens if the parser has not been able to resolve a type/class/interface? (for example, when a class implements an interface whose source code has not been provided)

• With the export formats xmi and html, the target type does not appear at all.
• With the export format htmlnew, the type is displayed, but is not clickable.

Even if packages don't exist by themselves in PHP, PHP_UML reconstitutes them by using the PHP namespaces (from PHP 5.3), or by using the docblock @package (if the source code has some). As for the "top package", it is nothing else than the "global namespace" of PHP.

Although this is not very UML style, PHP_UML can parse procedural code. The output format htmlnew is currently the only format to benefit from this new capability (the XMI format cannot, since it is a strict object-oriented XML vocabulary).

In the API documentation, the procedural functions will appear under Functions and the procedural constants under Properties, inside the package that matches the namespace that these elements belong to.

By default, the parser will ignore all the elements that have a docblock @internal. If you want to have them parsed anyway, use the switch --show-internal

Similarly, the switch --only-api forces PHP_UML to parse only the elements that are annotated with an @api.

With the switch --no-dollar, the parser removes the $ at the beginning of the property names (this character can cause problems with some UML tools).

Set the error reporting level to 2 with "--error-level 2" to display a list of the types/classes/interfaces that PHP_UML has not been able to resolve.

• A PHP class (or interface) maps to an UML Class (or Interface).
• A PHP function maps to an UML Operation.
• A PHP property, or class constant, maps to an UML Attribute.

Packages do not exist in PHP, like they do in Java. There are two possible ways to mimic them:

• by using the PHP namespace instruction
• by using the docblock @package in the comment of a class (or of a file)

Note that the namespace and use instructions will be parsed only if you run PHP_UML with PHP from version 5.3.

• A PHP file maps to an UML Artifact.
• A physical folder maps to an UML Package.

In UML 1.4:

• A class (or an interface) maps to an UML Component.
• A logical package maps to an UML Subpackage.

In UML 2.1:

• A class (or an interface) maps to an UML Component.
• A logical package maps to a nesting UML Component.