Last weekend we in Square Mobile tech team had first technical meeting for our newest product. The first lesson I learned from our technical adviser is 4+1 view model in Software Architecture. Honestly I do not know about it earlier. It was the first time I heard about it.
Why is it and What is it?
In software world, project team may consist of different kind of stake holders. There are developers, project managers, business anaysts, marketing people, etc. So the purpose of having different kind of view models is to get understand about the system according to their interest. Let’s talk about those view models in details.
Logical View : This contains information about the various parts of the system. In UML the logical view is modeled using Class, Object, State machine and Interaction diagrams (e.g Sequence diagrams). It’s relevance is really to developers.
Process View : This describes the concurrent processes within the system. It encompasses some non-functional requirements such as performance and availability. In UML, Activity diagrams – which can be used to model concurrent behavior – are used to model the process view.
Development View : The development view focuses on software modules and subsystems. In UML, Package and Component diagrams are used to model the development view
Physical View : The physical view describes the physical deployment of the system. For example, how many nodes are used and what is deployed on what node. Thus, the physical view concerns some non-functional requirements such as scalability and availability. In UML,
Deployment diagrams are used to model the physical view.
Use case view/ Scenarios : This view describes the functionality of the system from the perspective from outside world. It contains diagrams describing what the system is supposed to do from a black box perspective. This view typically contains Use Case diagrams. All other views use this view to guide them.
Why is it called the 4 + 1 instead of just 5?
The obvious problem I too had was why it is called as 4+1 instead of 5. Because it gives specialty to the Use Case View(Above diagram it shows as Scenarios). All other views are based on those use cases. But it is no longer valid when all other views are finished. It details the high levels requirements of the system.
It’s good to follow these view models in your software project. Because it will help for a project team to get things captured easily.