[keyword] TIP

[note] Graphical UML moral: if the focus/overview diagram of a Class or Package/Model is overly complex DO NOT be discouraged, it is a hint that your system needs refactoring ! Begin by creating "scenario" sub-diagrams that each identify a narrative.

Type:

Applies to

[note] A guiding principle is that a form-related include bridge file should use one and one only helper/builder class with delegation from each of the form _build(), _ajax(), _validate() and _submit() functions of the bridge include file.

Type:

Applies to

[note] UML Package/Model symbols can be useful for graphically organising the symbols of the elements they own but they are fragile against change of ownership. They are essential for Package/Model overview diagrams but not always advised in class diagrams.

Type:

Applies to

[note] Even in dedicated "focus" class diagrams showing too many Dependency arrow symbols between operations and/or attributes can lead to clutter; sometimes it is useful to create Dependency relationships in the UML model but not show them in all diagrams

Type:

Applies to

[note] In Package/Model overview diagrams it can sometimes be useful to show the operations compartment, as long as it does not lead to clutter; in MagicDraw UML one can choose to show operations without the full operation signature.

Type:

Applies to

[note] DIRTY TRICK for reverse-engineering "flat" Drupal7-style .module and .inc PHP files into methods of Webel-style wrapper @Components

Type:

Applies to

Because PEAR:PHP_UML can only reverse engineer PHP Class and Interface files (not "flat" Drupal7-style .module or

[note] In the best UML tools like MagicDraw UML one can show the structure compartment of Classes and Components and their composite structure as Property symbols in "hybrid" class or implementation diagrams.

Type:

Applies to

[note] UML: just because an operation or attribute is not shown in a compartment of a Class or Component symbol (in a given diagram) does not mean it is not present in the underlying UML model !

Type:

Applies to

[note] An «!analysis» @Interface in a class diagram may show a UML Usage (requires) to another referenced «!analysis» @Interface type. This can be displayed as a UML "Usage socket" symbol.

Type:

Applies to

[note] The arrow of a ComponentRealization points from a reverse-engineered PHP design(ed) Class to its Webel «!wrapper» (analysis) @Component. However, the analysis @Component owns the relationship ! The design Packages are not changed by the analysis !

Type:

Applies to

[note] MagicDraw UML: you can (you may) show Association end elements within a Component symbol (instead of outside); this can be very useful for graphically organising supplier elements to make the Component look like a self-contained machine. It is valid UML!

Type:

Applies to

[note] The «!analysis» Packages "observe" the reverse-engineered PHP design(ed) Interfaces and Classes

Type:

Applies to

[note] MagicDraw UML: you can drag a design Class symbol into a «!wrapper» @Component and create a suitable ComponentRealization without changing the ownership (packaging) of the design Class !

Type:

Applies to

[note] The wrapped design Classes are shown here for illustration only; usually it's the job of the «!wrapper» @Component's own linked implementation diagram to show which matching reverse engineered PHP design(ed) Class it wraps.

Type:

Applies to
Subscribe to RSS - TIP