The 4+1 model

It's been a while since I heard about the segmentation and points of view of the design of a piece of software. The very first video for this task brought me back to the days in professor Humberto's classroom drawing stick figures for our use case diagrams. I think the reading is very creative, it is true that for bigger pieces of software everybody look's at their own work as if it was most of what the software is. However I must say that in order to polarize a view on a team of programmers of how a product works (or even what it is), it must have been designed by using a solid model.For instance, my third semester video game project was only some chunks of code. The only level covered on a 4+1 model was the logical because we were asked to do so. It seems impossible how would a process or physical view of our game would look like. It is true that the game was no elephant and it wasn't meant to be an elephant as it only needed to fulfill a simple set of requirements perhaps that one of a mouse. Back in AstraZeneca I had to do a lot of maintenance to map services and found it quite interesting that when I had to do some work on cross-frame related problems of a web page developed by another division, none of the architects had a remote idea of how or where was this implemented.When I finally figured out how to mess with it, they said that they would never implement that service in that specific module. It is understandable that everyone can have their own perceptions of how things are to be implemented, as long as they see a blurry version of the picture and not sticking to believing that the elephant is much like a sword.