Preamble
Views can take different meanings, from windows opening on specific data contexts (e.g DB relational theory), to assortments of diagrams dedicated to particular concerns (e.g UML).
Models for their part have also been understood as views, on DB contents as well as systems’ architecture and components, the difference being on the focus put on engineering. Due to their association with phased processes, models has been relegated to a back-burner by agile approaches; yet it may resurface in terms of granularity with model-based engineering frameworks.
Yet, whatever the terminology (layers vs levels), what is at stake is the alignment of two basic scales:
- Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
- Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).
Views & Architectures
As far as systems engineering is concerned, understandings of views usually refer to Philippe Kruchten’s “4+1” View Model of Software Architecture” :
- Logical view: design of software artifacts.
- Process view: captures the concurrency and synchronization aspects.
- Physical view: describes the mapping(s) of software artifacts onto hardware.
- Development view: describes the static organization of software artifacts in development environments.
A fifth is added for use cases describing the interactions between systems and business environments.
Whereas these views have been originally defined with regard to UML diagrams, they may stand on their own meanings and merits, and be assessed or amended as such.
Apart from labeling differences, there isn’t much to argue about use cases (for requirements), process (for operations), and physical (for deployment) views; each can be directly associated to well identified parts of systems engineering that are to be carried out independently of organizations, architectures or methods.
Logical and development views raise more questions because they imply a distinction between design and implementation. That implicit assumption induces two kinds of limitations:
- They introduce a strong bias toward phased approaches, in contrast to agile development models that combine requirements, development and acceptance into iterations.
- They classify development processes with regard to predefined activities, overlooking a more critical taxonomy based on objectives, architectures and life-cycles: user driven and short-term (applications ) vs data-based and long-term (business functions).
These flaws can be corrected if logical and development views are redefined respectively as functional and application views, the former targeting business objects and functions, the latter business logic and users’ interfaces.
That make views congruent with architecture levels and consequently with engineering workshops. More importantly, since workshops make possible the alignment of products with work units, they are a much better fit to model-based engineering and a shift from procedural to declarative paradigm.
Model-based Systems Engineering & Granularity
At least in theory, model-based systems engineering (MBSE) should free developers from one-fits-all procedural schemes and support iterative as well as declarative approaches. In practice that would require matching tasks with outcomes, which could be done if responsibilities on the former can be aligned with models granularity of the latter.
With coarse-grained phased schemes like MDA’s CIM/PIM/PSM (a), dependencies between tasks would have to be managed with regard to a significantly finer artifacts’ granularity.
For agile schemes, assuming conditions on shared ownership and continuous deliveries are met, projects would put locks on “models” at both ends (users’ stories and deliveries) of development cycles (b), with backlogs items defining engineering granularity.
From the enterprise perspective it would be possible to unify the management of changes in architectures across layers and responsibilities: business concepts and organization, functional architecture, and systems capabilities:
From the engineering perspective it would be possible to unify the management of changes in artifacts at the appropriate level of granularity: static and explicit using milestones (phased), dynamic and implicit using backlogs (agile).
Such a declarative repository would greatly enhance exchanges and integration across projects and help to align heterogeneous processes independently of the methodologies used.
Further Reading
- Thread: Project Management
- Products, Projects, Processes
- Work Units
- Caminao & UML
- UML and Users’ Concerns
- UML# Manifesto
- UML#: Core Artifacts
- Focus: UML Reenacted
- Focus: UML & MDA
- Projects Have to Liaise
Misses the point — Making a system Fit For Purpose, F4P. The agile development scheme doth not agile systems make. Smart architects 1. modularize for system agility and 2. orchestrate for system perpetual F4P even while evolving.
Isn’t that obvious ? Nothing to miss then.
Not much of an assumption since the backlog mechanism is part and parcel of agile, and its answer to the granularity question. As for the 4+1 it’s not only semantics because it can be used to organize the teams.
I think the key is the assumption that you are prepared to organize tehe backlog utilizingthe agile aproach. In short, it develops itself as the iterations provide increasing insight into the desired outcome This is process. As to alignment to the 4 + 1 architcture I get the feeling ( probably wrong) we’re discussing semantics. I would very much like an explanation why my last premisse isn’t correct.