Posts Tagged ‘Architecture driven modelling’

Engineering Symbolic Representations

March 19, 2010

Engineering processes are meant to sequence activities along intrinsic factors, as opposed to operational processes whose aim is to adapt activities to contexts. Whereas factors governing manufacturing processes depend upon the physical contingencies of material flows, the rationale behind software engineering processes is first and foremost governed by constraints on development flows, whose nature is essentially symbolic.

issa-samb

Seats or Spades, Actual or Symbolic (Issa Samb).

Development processes usually follow one of two schools: procedural or acrobatic. Procedural processes impose one-fits-all development frameworks and significant overheads to compensate for the misfits; acrobatic ones bet on responsibility, expertise and best practices but don’t say much about development artefacts. The challenge is to take the best of each: shared understanding of model contents, lean developpment processes, sound anticipations, reliable commitments, and traceability.

Architecture Driven Modelling takes source from OMG’s Model Driven Architecture. More generally, it follows the well accepted distinction between requirements, analysis, and design, and can be implemented with OMG’s Unified Modeling Language.

Analysis models describe the symbolic representations of business objects and processes. They use requirement models, which describe business objects and processes. They are used by design models, which specify how symbolic representations will be implemented as system objects; implementation and deployment are not considered here.

Model Layers: Requirements, Analysis, Design.

Given those layers, system engineering has to manage objectives pertaining to a three-pronged perspective:

  • The business perspective is synchronic as it deals with the symbolic representation of context objects and processes. Since objectives, constraints, and risks change along their own time-frames, their symbolic representations must do the same; as a consequence system requirements must be continuously and consistently anchored to business  contexts.
  • The engineering perspective is diachronic as it deals with the implementation of system symbolic representation. Once rooted into requirements, the design and implementation of  symbolic representations are only concerned with the life cycle of development artefacts.
  • In between the architecture perspective is meant to be as invariant as core business concerns and corporate identities.

Given an architecture, both business and system models can be managed separately, each along its own timeframe, providing they don’t contradict architectural constraints.

sculptures_ad0

Descriptions and specifications look from different perspectives

Based upon the layered view of models,  engineering processes can be built bottom-up from work units directly defined from development flows. As a consequence, they can be better fitted to tasks, assessed, and improved.

Taking inspiration from the Capability Maturity Model Integration (CMMI), the benefits of architecture driven modelling can be identified for product, project, and process areas:

  • Traceability is obviously a starting point as it is a pre-requisite for streamlined engineering (product), portfolio and risk management (project), and application lifecycle management (process).
  • Measurement comes close, with built-in unbiased estimators, project workloads, and process assessment.
  • Quality management would clearly benefits from layered traceability and objective measurements, with built-in controls, non-regressive testing, and model-based validation.
  • Reuse provides another path to quality, with patterns (product), profiles (project) and development strategies (processes).
  • Finally, collaboration is to be facilitated between engineering processes targeting heterogeneous platforms, using different methodologies, across independent organizations.
Advertisements

Modeling Symbolic Representations

March 16, 2010

System modeling is all too often a flight for abstraction, when business analysts should instead look for the proper level of representation, ie the one with the best fit to business concerns.

Modeling is synchronic: contexts must be mapped to representations (Velazquez, “Las Meninas”).

Caminao’s blog (see Topics Guide) will try to set a path to Architecture Driven System Modelling. The guiding principle is to look at systems as sets of symbolic representations and identify the core archetypes defining how they must be coupled to their actual counterparts. That would provide for lean (need-to-know specs) and fit (architecture driven) models, architecture traceability, and built-in consistency checks.

This blog is meant to be a work in progress, with the basic concepts set open to suggestions or even refutation:

All examples are taken from ancient civilizations in order to put the focus on generic problems of symbolic architectures, disregarding technologies.

Symbolic representation: a primer

Original illustrations by Albert (http://www.albertdessinateur.com/) allow for concrete understanding of requirements, avoiding the biases associated with contrived textual descriptions.