MotivationOften people find struggling with the 4 most important Architecture Diagram on Architectural Blueprints of The “4+1” View Model of Software Architecture?
The reason behind this is the advancement and refinement in the way technology has evolved and the way we can interpret and map our thought to technology. The writeup will help you understand the advancement in 4+1 model and what should be its practical adoption to other areas than telecom and network where its originated initially.
ContextNow a days the power of Agile, TOGAF and mapping requirement to UML and OMT make's it easy to design artifacts which can be mapped from different levels of pertaining views that can be felt and inscribed as user stories through different view points.These artifacts can be made alive as code skeleton which can later become the core of technology framework.
Creating the Stack holder power grid help us to prioritize stories with perspective's that are more important for building the system.
The importance of view point help us to derive the use cases easily helping us to draw the functional view of the program. This would further help us to conclude to the 60,000 feet view of the program at its component level.Diving further below to the 30,000 feet help us to look at the program by mapping to the activities in the use cases to the major component of the system and how they will be mapped at component level which will help us in deriving the required infrastructure and capacity management of the system.Further comes the security view of the system which can be based on number of Human and System actors interacting between inside and outside of the system in term of switching and control, messaging and usage.The views can be laid out easily through structural diagram of UML2.0 and further standards. Once we clear out all the views including the infrastructure we can further dig deep to the Development view mapping the classes, objects and interfaces to the use cases, Activity diagram, Process flow diagram (Not limited to UML as flowchart are always the fastest to make and easiest to explain between the involved parties.)
However at this level UML structural diagrams works but we may have to break to sequence and state diagram which are a bit tricky and should be avoided if not much required.
The below example is still in the mode of refinement and lacks the user stories, I will try to update it as soon as I get out from my personal and professional commitments.
Building a computer based Air Traffic Controller and Simulator game.I have tried explaining through a work item for building the air traffic simulation game.With the time this documentation will try covering requirement and solution taking care of all the phases of requirement gathering estimation and design forming a well written documentation for the same.
Stack holder Grid:-
---To be updated
User Stories-- To be updated
Program and Budgeting (RFP, BRD, FSD ETC)---Not the part of current context
Project plan (WBS, PERT, Resource's and Budgeting)--- Not the part of current context
Mapping the user stories to use case.
Actors using the system and their hierarchies:-
System at Component Level at 30000 feet:-
to be updated
DR Plan:-to be updated
Capacity management:-to be updated
Support:-to be updated
to be updated
Class diagram and ORM:-to be updated
to be updated
* Note all diagram, content are copyrighted to techies bytes.