Chapter: Software Architectures : Architectural Views

Rational Unified Process/Kruchten(RUP) 4+1

Rational Unified Process/Kruchten(RUP) 4+1 introduce 5 point view approach to documenting Software Architectures.

Tailoring the Model

Not all software architecture need the full “4+1” views. Views that are useless can be omitted from the architecture description, such as the physical view, if there is only one processor, and the process view if there is only process or program. For very small system, it is even possible that the logical view and the development view are so similar that they do not require separate descriptions. The scenarios are useful in all circumstances.

A scenario-driven approach

The most critical functionality of the system is captured in the form of scenarios (or use cases). By critical we mean: functions that are the most important, the raison d’être of the system, or that have the highest frequency of use, or that present some significant technical risk that must be mitigated.

Start:

• A small number of the scenarios are chosen for an iteration based on risk and criticality. Scenarios may be synthesized to abstract a number of user requirements.

• A strawman architecture is put in place. The scenarios are then “scripted” in order to identify major abstractions (classes, mechanisms, processes, subsystems) as indicated by Rubin and Goldberg — decomposed in sequences of pairs (object, operation).

• The architectural elements discovered are laid out on the 4 blueprints: logical, process, development, and physical.

• This architecture is then implemented, tested, measured, and this analysis may detect some flaws or potential enhancement.

• Lessons learned are captured.

Loop:

The next iteration can then start by:

• reassessing the risks,

• extending the palette of scenarios to consider

• selecting a few additional scenarios that will allow risk mitigation or greater architecture

coverage Then:

• Try to script those scenarios in the preliminary architecture

• discover additional architectural elements, or sometimes significant architectural changes that need to occur to accommodate these scenarios

• update the 4 main blueprints: logical, process, development, physical

• revise the existing scenarios based on the changes

• upgrade the implementation (the architectural prototype) to support the new extended set of scenario.

• Test. Measure under load, in real target environment if possible.

• All five blueprints are then reviewed to detect potential for simplification, reuse, commonality.

• Design guidelines and rationale are updated.

• Capture the lessons learned.

End loop

The initial architectural prototype evolves to become the real system. Hopefully after 2 or 3 iterations, the architecture itself become stable: no new major abstractions are found, no new subsystems or processes, no new interfaces. The rest of the story is in the realm of software design, where, by the way, development may continue using very similar methods and process.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

Software Architectures : Architectural Views : Rational Unified Process/Kruchten(RUP) 4+1 |