Monday, January 9, 2012

Extension to the 4+1 View Model of Software Architecture

Motivation

Often 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.


Context

Now 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.

Example:

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 from 60000 feet:-







System at Component Level at 30000 feet:-



Infrastructure Diagram:-



to be updated

DR Plan:-

to be updated

Capacity management:-

to be updated

Support:-

to be updated

Hosting:-



to be updated

Class diagram and ORM:-

to be updated

Data architecture:-



to be updated

* Note all diagram, content  are copyrighted to techies bytes.




No comments:

Recent Posts