Skip to main content

The 4+1 View Model


On today’s blog we are going to talk about the 4+1 view model, which all of this was taken from two videos. This model says that, when we are creating software we need to focus on 4 things:

  • The logical view: which is the logical design of the software
  • The development view: the way the program interacts between its components
  • The process view: the way the program functions
  • The physical view: the way the software and the hardware interact between each other
Now to explain more these 4 things, the logical view refers on what are we going to build, not the actual code, but the design and logic it will have, a good example of it is a class diagram.

 The development view refers on how the program is organized and how it communicates between its own parts, the component may be a good example of this because it shows exactly that, how is organized and how it communicates to work.

The one that refers on how the program works is the process view, it refers on the how is the program synchronized and its concurrency, for example an activity diagram.

Finally, we have the physical view, which refers on how the software and the hardware are related and communicate with each other.


Now for Six Blind Men video and the elephant and the blind article, both of them relates to the model. On both there is a story of blind people trying o describe an animal or elephant in a specific one (guess which one), and because they are blind, obviously they say different  things because they were guessing based on what they were feeling, now at first sight may be wrong, but to them no, because they were actually describing things good, they were just saying another animal with the same characteristics.



Comments

Popular posts from this blog

Is Design Dead?

On today’s entry we are going to talk about the article “Is design dead?”, which talks about how the design has been changing through the years and how the good practices were developed in order to create a good design. Is no lie that for all the people that develops software, is kind of difficult to come up with a good design because of the lack of and standards to create it, other areas may have standards or even a methodology, but not us. Because of these needs, developers have created a bunch of good practices, not to create, but to reach a good design probably in a 85% of success. For example, a good practice is a that the code we create has to be modular in order to make corrections or complete alterations in a easier, this changes may occur for many reasons, manteinance, update the information or just to simply chage the entire code to something more efficient, the same goes to the design, but the problem is that a design is more difficult to modify when is already d...

Microservices

On today’s blog entry we are going to talk about the Microservices architecture. This architecture has an approach where when we are developing a single app, we develop it as lots of small services, each of them running on its own process and communicating with each other with something that can bind them together. Now I have already used microservices without knowing I was actually using them, perhaps this architecture is quite intuitive for best practices or something like that, but anyway the author of the article gives some characteristics about this which are the following: ·          Componentization via Services: The components of the microservice need to be gather into libraries that will be used later on by the microservice to communicate with remote parts of the whole program. ·          Organized around Business Capabilities: This characteristic refers that we need to create divisions, e...

Understanding the SOLID principles

On today’s blog we are going to talk about the SOLID principles, which were discovered by Robert Martin, the famous Uncle Bob from the podcast of the previous entry. This principles are recommended to be used whenever someone wants to create an object oriented program. There are 5 principles where the acronym SOLID comes from which are the following S ingle Responsibility Principle (SRP) -> it says that any class should only have one responsibility. Yet, the author ends up saying that there might be some classes that have two responsibilities (the invoicing class that has some logging routines). In the end, I didn’t understand this principle well because I found the explanation confusing (as the author said, practice is much more difficult than theory).  O pen/Closed Principle (OPC) -> open extension but closed modification Although the author says that if you change a parent class method it might kill another part of the ...