[keyword] «!analysis»

The entire Webel analysis map of OOE = Object Oriented Examples = One Of Each is under a special top-level the «!analysis» @ Package.

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).

No modelling is ever performed directly on reverse-engineered design classes, only @Interfaces may carry, for example, a Dependency or Usage to a design class.

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).

If any of the «!wrapper» @Components or «!analysis» @Interfaces have any other kinds of relationships to design elements of any kind, the Webel wrapper model is broken !

[uml] Helper

Webel module:

UML element type:

OOE stereotypes:

Helper base class with some common static utility methods.

Direct inheritance of this requires at least PHP5.3. Visit also (external tip): Inheritance of static members in PHP.

[uml] stdClass

Webel module:

UML element type:

OOE stereotypes:

Analysis wrapper placeholder for PHP stdClass.

[uml] Drupal\flagplus\banner

HOT TIP: this content is flagged as highly recommended !

Webel module:

UML element type:

OOE stereotypes:

This package collects everything to do with generation of Flag Plus banners for Flags. The default implementation is a rectangular strip banner with a text color, background color, border color and some style settings that apply across all banners (independent of flag state to type). But one could easily provide another implementation that uses a different geometry.

[uml] IFlagBannerStateData

Webel module:

UML element type:

OOE stereotypes:

Manages data specific to a Flag banner state.

[uml] FlagPlusFactory

Webel module:

UML element type:

OOE stereotypes:

implements [InterfaceRealization]: 
IFlagPlusFactory

Default simple factory for common products for this module.

[uml] IFlagPlusFactory

Webel module:

UML element type:

OOE stereotypes:

Simple factory for common products for this module.

[uml] IFlagBanner

Webel module:

UML element type:

OOE stereotypes:

Manages a banner specific to a Flag.

[uml] FlagBannerStateData

Webel module:

UML element type:

OOE stereotypes:

implements [InterfaceRealization]: 
IFlagBannerStateData

Implements management of data specific to a Flag banner state.

This version is suitable for use for a simple rectangular strip with a text color, background color, and border color. The same data could however be used for other banner designs.

[uml] FlagBanner

REFACTOR: this software engineering content is flagged as under consideration for refactoring.

Webel module:

UML element type:

OOE stereotypes:

implements [InterfaceRealization]: 
IFlagBanner

Default implementation of a banner specific to a Flag. This version uses a simple rectangular strip.

Note how it stores the data (text color, background color, border color, and style options) for the 2 separate states 'flagged' and 'not flagged' in dedicated state data holders !

[uml] BannerFlagHelper

Webel module:

UML element type:

OOE stereotypes:

Helper class for aspects of banners specific to a Flag. Includes some simple database interaction helper methods.

[uml] EntityFlagMapper

Webel module:

UML element type:

OOE stereotypes:

Manages information on flag applicability by entity type and bundle.

[uml] flagplus.forms.inc

STUB: this content is flagged as a placeholder only, with minimal content.

Webel module:

UML element type:

OOE stereotypes:

A placeholder for non-admin forms and their handlers (and supporting functions). Currently this module has no public-usable forms.

[uml] flagplus.theme.inc

STUB: this content is flagged as a placeholder only, with minimal content.

Webel module:

UML element type:

OOE stereotypes:

A placeholder for theme-related handlers. Currently this module has no theme specific code.

[uml] flagplus.pages.inc

STUB: this content is flagged as a placeholder only, with minimal content.

Webel module:

UML element type:

OOE stereotypes:

A placeholder for public-facing page builders. Currently this module has no public pages.

[uml] flagplus.info

STUB: this content is flagged as a placeholder only, with minimal content.

Webel module:

UML element type:

OOE stereotypes:

Placeholder for the module's .info file.

Extends Flag with some extra features such as the ability to set flag applicability by content type, and CSS styled flag state banners.

[uml] @flag

STUB: this content is flagged as a placeholder only, with minimal content.

Webel module:

UML element type:

OOE stereotypes:

Dummy analysis Model package for holding dummy analysis placeholder analysis elements for concepts in the Flag contributed module.

[uml] flagplus.install

Webel module:

UML element type:

OOE stereotypes:

[uml] BannerSchema

Webel module:

UML element type:

OOE stereotypes:

Constants common to the database schema of the banner aspects of the module.

So far just enough as an interim step to capture the column names of the DB table used for per-Flag banner settings.

Promotes robust Don't Repeat Yourself (DRY) code rather than error-prone Write Everything Twice (WET) code.

[uml] BybundleAjaxBuilder

REFACTOR: this software engineering content is flagged as under consideration for refactoring.

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 
BybundleAbstractBuilder

EXPERIMENTAL: AJAX version of a form for applicability of flags by bundle.

The form it builds has one or more embedded sub-forms for choosing applicability of flags by entity type and bundle (shown according to the entity-type filter choice).

[uml] BybundlePageBuilder

HOT TIP: this content is flagged as highly recommended !

Webel module:

UML element type:

OOE stereotypes:

For building readonly pages of flag applicability by bundle.

[uml] BybundleAbstractBuilder: child hierarchy (and logical grouping wrapper Component example)

HOT TIP: this content is flagged as highly recommended !

Webel module:

UML element type:

OOE stereotypes:

In MagicDraw UML, a Component does not "steal ownership" of a graphically contained child element if the child's SYMBOL is moved/dragged from WITHIN A DIAGRAM into the Component's SYMBOL; it only steals ownerhips if the child model element is moved into (under) the Component WITHIN THE MODEL BROWSER.

[uml] EntityFilter

Webel module:

UML element type:

OOE stereotypes:

A good example of how encapsulating related functions as static helper/builder class methods (that can be reverse engineered to UML) brings immediate advantage to both the code organisation and the UML diagramming, without even considering in detail yet how this might be handled as an object.

This helper/builder class can create both a non-AJAX and an AJAX-aware entity type filter form element, as well as offering some helper functions for the actual filtering against entity type.

Pages

Subscribe to RSS - «!analysis»