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
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.