Patterns

Objectives

Reuse can be managed at component or model level. At model level patterns describe stable and safe engineering solutions both for business and engineering perspectives:

  • Business perspective, reuse targets services defined by the enterprise architecture.
  • Engineering perspective, reuse targets development artifacts as defined by the different model layers.

Patterns are especially effective when defined within the model driven engineering framework  and the objective is to build models from modules set along architectural concerns.

Patterns as seen by Nicholas de Stael in Parc des Princes

Levels

Representation patterns are archetypes of symbolic representations and should not be confused with business patterns, which are archetypes of business activities. Whereas both can overlap, their purpose is essentially different as, contrary to business (aka analysis) patterns, representation patterns target system functional architectures. As for design patterns, thanks to the Gang of Four, they are now well understood and accepted as archetypes of component implementations.

Functional patterns are archetypes of functional architectures as they deal with the organization of core system functionalities (persistency, authorization, communication, etc.) independently of the technical platform supporting them. That approach to reuse is best represented by Service Oriented Architectures (SOA)whose rationale is to map corporate business invariants, business entities or processes into services supported by unspecified systems.

Reuse & Patterns

Reusing well tested artifacts is arguably a win-win option, with benefits on costs as well as on quality. Yet, if design patterns are widely used for system components, that’s not the case for analysis patterns, which are kept within the silos of domain specific languages. As a consequence, the benefits of reuse remain local and contingent:

  • Local, because design patterns are limited to individual components while analysis patterns are mostly confined to attributes implemented through semantics domains.
  • Contingent, because whatever the maturity of design patterns, their benefits depends upon the soundness of the analysis models which support them.

In order to overcome those limitations, patterns and semantic domains must be seamlessly integrated from requirements to design while, at the same time, architectural patterns should be fenced off.

Analysis vs Design

Given that patterns are symbolic constructs meant to be reused, a clear understanding of purposes is a prerequisite. And purposes must, first and foremost, be set along the Analysis/Design divide:

  • Analysis deals with the problem under scrutiny. Its objective is to extract the relevant aspects.
  • Design deals with the solution. Its objective is to define the corresponding artifacts.
Analysis extract relevant features, Design define surrogates

Analysis extracts relevant features, Design defines corresponding artifacts.

The challenge is to build a bridge between patterns used for analysis to those used for design.

A Bird’s-eye view of software engineering approaches

Beyond and above the jungle of acronyms, things are much more stable and consistent than what it seems, and the different approaches can be set along shared perspectives, namely problems, solutions, processes.

Problem patterns should be examined according to requirements nature:

  • Business problems are set by contexts and objectives and should not be dependent of system functionalities or technical platforms. That is what MDA’s Computation Independent Models (CIMs) are meant to describe.
  • Functional problems examine how the system under consideration should support users dealing with business problems, whatever the technical platform. That is what MDA’s Platform Independent Models (PIMs) are meant to describe.
  • Technical problems examine how the functionalities under consideration should be implemented, given the way they will be accessed and the constraints on performances and resources. That is what MDA’s Platform Independent Models (PIMs) are meant to describe.

Solution patterns should be set according their architecture footprint:

  • At their simplest, solution patterns deal with standalone accesses.
  • Next, one should find patterns dealing with collaboration at application level, i.e functionalities encompassing simultaneous accesses to transient business objects.
  • Finally, one will find patterns dealing with collaboration at domain level, i.e functionalities encompassing simultaneous accesses to persistent business objects.

Patterns like Model-View-Controller (MVC), Presentation-Abstraction-Control (PAC), or Boundary-Entity-Control (EBC) are set along those principles at functional level; classic design patterns of the GoF take also into account implementation concerns.

Process patterns should be set according to the problems to be solved and their architecture footprint:

  • Agile-like development patterns are first candidates when problems and solutions can be examined within single loops with stakeholders, users, and developers.
  • Staged development patterns are necessary when solutions are to be consolidated across architecture layers.
  • Milestones and waterfall development processes cannot be avoided whenever stakeholders belong to different organizational units.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 305 other followers

%d bloggers like this: