Caminao aims to chart all worlds of system models, drawing maps with a kernel of the UML, based upon a reasoned conceptual framework.
Set from a comprehensive and objective survey of system functionalities and architectures, using standard notation applied to unambiguous concepts, those maps should provide all-weather guidance to system modellers, whatever their bearings or creed.
Models, Architectures, Perspectives (MAPs)
Of all industrial artifacts, software components are the only ones that can be fully built from models. As a consequence, charting comprehensive and reliable maps should not only be feasible but also highly beneficial.
Caminao maps are built from models, architectures, and perspectives:
- Models set the stages, where targeted artifacts are defined depending on concerns.
- Architectures deal with with the topography of objects depending on stakeholders situation: business objectives (enterprise), supporting systems (functionalities), implementation platforms (technology).
- Perspectives are set by stakeholders concerns and must be put into context as defined by enterprise, functional or technical architectures.
The aim of those maps is to provide reasoned tools for seasoned modellers, helping them in setting milestones, planning journeys, and appraising itineraries.
- Milestones are about sequences: they are necessary whenever expectations and commitments are set across different organizational units.
- Planning is about projects: once requirements are properly analyzed, maps can be used to sequence goals, set paths, and define tasks gauged according topography metrics.
- Appraising is about processes: given sound and objective metrics, tasks traceability to outcomes, and projects built alongside, roadmaps can be turned into development patterns depending on capabilities assessment.
Maps are to be drawn using a standard notation, and for that purpose Caminao uses a kernel of OMG’s Unified Modeling Language.
UML# (for “charpente”, supporting structure in French), is built on a core of UML syntactic constructs, using its stereotyping mechanism to define semantic qualifiers set along functional layers on one hand, OMG’s Model Driven Architecture on the other hand.
UML# objective is therefore not to be a substitute to UML but rather a complement dedicated to requirements and analysis, without affecting continuity with design and implementation models.
Neither maps nor languages are meant to convey any guidance about course or discourse. Hence, modeling languages have nothing to say about what is to be represented and how it should be done. For that purpose a reasoned understanding of system functionalities and architecture is required.
Curiously, while core concepts are already at hand, most of methodologies are either aimed at system design, or lean on fallacies about what analysis models should represent.
Caminao ultimate objective is therefore to bridge the conceptual gap between functional requirements and system analysis, bringing both semantics under a common roof. To that end, some principles are to be carried through:
- Comprehensive scope: concepts must deal with all and every configuration, without assuming any restriction about functional requirements.
- Closed paradigm: all descriptions of system functionalities and architectures must be upheld by a clearly circumscribed and self-contained number of concepts.
- Thorough and reasoned understanding: all stereotypes are to be unambiguously defined from the core concepts using a set of formal constructs applied uniformly.
- No expertise or best practices: maps must support all ventures and befit every methodological inclinations. As a consequence concepts and stereotypes must remain neutral and free of any preference or precedence.
Eventually, that should open a new perspective to model driven engineering by consolidating model layers around functional architectures.
What makes the Caminao Framework different ?
- Clearly defined scope: a bridge of shared concepts between enterprise and system architectures.
- Formal framework: logical constructs derived from a small set of unambiguous building blocs.
- Open approach: since it only deals with the description of architectures, it can support a wide range of methods according to purpose or organization.
- No string attached: the framework documentation is fully and freely available online.