To have a more formal definition of what I mean when talking about modelling an architecture (summarised from to
IEEE 1471):
An architectural description is organized into one or more views.
A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.
The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modelling methods or analysis techniques to be applied to these representations of the view.
I am not against using models to represent architectural views, but there are some fallacies that often seem to happen when using various modelling approaches in architecture descriptions.
- The purpose of the architecture model is unclear (in 1471-terminology: It is not obvious what concerns the model addresses). UML is especially problematic since it provides notation that can be used for so many purposes. Read John Daniels paper Modeling with a Sense of Purpose as an introduction.
- Everything is modelled to the same level of detail. Not everything is equally important to know. For some parts of the system it is important for the architecture (and realisation of qualities) to know the details, for other parts it is not.
- Every part of the system must be represented in the architecture, for example if every class must be traceable from some element in the architecture. This could even be a rule of the architecture, "if it is not explicitly allowed it is forbidden". This reeks very much of waterfall mindset with the architects doing much of the design before any developers get involved. I think it is presumptuous of the architects to claim to know everything that needs to be implemented.
- Modelling tools always demands a precision in notation, which is not always desirable when sketching an architecture. You cannot model "sort of a class", or "could be a function" when using a tool, which is possible on a whiteboard or a napkin. In a tool it has to be a class, a function or a package, not something in-between.
3 comments:
While agree that IEEE Std 1471 is not a standard that one can read and then create an architectural view, I do think there is value in modeling.
Even the 1471 states that each view is to address the concerns of the stakeholder, thus this help address to what degree a model is matured.
Now UML can sometimes be more focused on form as function, however, I do like the body of literature to draw upon in helping develop a working knowledge of building an architecture. In fact, I appreciated how Mr. Kruchten provides a reference number of views to "chase".
In my case, we have a distributed development team, and the RUP instantiation of the 1471 provides our team with a common language, a process, and some idea of determining when we are done.
However I do agree 100% that modeling tools are nearly useless and seem to serve as a vehicle to get a consultant some money.
If my post seemed to say I am against modelling I was very unclear. I am very much in favour of modelling.
What I am against is some modelling practices that I have seen in different organisations/teams.
I am just now reading Just Enough Software Architecture by George Fairbanks. Excellent book! Among other things it really delves into what to model (and how much).
I would like to introduce our site for WINDOWS PHONE 7 DEVELOPMENT and IPhone App Development just check it out.
Post a Comment