4+1 model

  •  Logical View
    • Se encarga de ver la funcionalidad. Por lo que entiendo, normalmente se representa con diagramas de UML tales como diagrama de clases y diagrama de estados.
    • Se enfoca en lo que le corresponde al usuario. 
  • Process View
    • Se encarga de ver como funciona el sistema al momento de ejecutarlo.
    • Explica las comunicaciones entre el sistema y los procesos.
    • Se usan diagramas tales como diagramas de flujo y diagramas de comunicación
  • Development View
    • Prioritiza la vista desde la perspectiva del programador.
    • Corresponde a la administración de software. 
    • Implementation view es otro nombre para esta vista. 
    • Utiliza el diagrama de componentes o paquete de UML
  • Physical view
    • Se enfoca de un ingiero de sistemas.
    • Topología de los componentes de sofware y las conexiones físicas entre estos.
    • Deployment view es otro nombre
    • Deployment diagram se usa del UML 
  • Use case view
    • Define los casos de usos. Este representa el +1 en el nombre del modelo.
    • Interacciones y procesos son descritos en los distintos esenarios.

Comments

Post a Comment

Popular posts from this blog

Who Needs an Architect?

 Al finalizar la lectura dos cosas me dejaron pensando. La primera siendo el contenido del articulo. El cual se puede resumir en las diferentes formas de definir arquitectura. Es muy cierto el hecho de que el termino arquitectura es algo tan vago pero que al mismo tiempo se utiliza en todos los lugares. Y lo peor es que en cada contexto se utiliza de manera distinta.  Como el autor menciona, la arquitectura cambia dependiendo la vista. Para el usuario no le importa los componentes o como esta el esquema de la base de datos. Al arquitecto le interesa la vista de las interfaces y las interacciones.  Y creo que llego al mejor resultado. La idea de que la arquitectura es un contrato social creo yo es una de las mejores definiciones que he escuchado. Y aun mas cuando se define que se incluyen los componentes que todos los involucrados en este contrato social entienden.  En mi experiencia laboral esa ultima parte es algo que completamente encaja. Cuando hablamos de arquite...
Read more

Code Craft

 I feel that architecture in most small projects is almost never seriously considered. And, to some extent, I can see why. Most time it takes a lot of effort, time and cost to set up an architecture when you are planning to do a small project with the intent to run it and forget about it.  Even in this situations the code is not excempt from bad techiniques, horrible and lengthy code or the need for extra effort to maintain, Maybe the impact will be lower or none at all, Simply because the fact that once you are donde, you are no longer going to add features, modify behaviour or else. And in this instances it can be considered okay to go with such naive aproach. That would be the case in a perfect world tho. As the text points out, rarely does the project avoid extra features, modification, or even the always present bug & glitch. And the irony of all is that even in those cases when you know for a fact that once the product is finished you wont ever touch it again, y...
Read more

SOLID

 Single responsability This helps a lot when tyring to define how a service, class, object should work. Not defining a single thing that the object is responsable makes it really easy to have overcharged classes that do everything all at once. Making the code completly unmaintainable. And do not confuse responsability with single thing to do or single action. It means the object is only responsable for this specific thing. Open/Closed  This, to me, means that when modification to add functionality. The best course of action is to add other inheritable classes insted of modifying base class. Liskov substitution This means that child and parent should behave as expected. This means that having a base class T and an S class that inherets from T, you cannot somehow change how T behaves, because you need to be able to usse S instead of T. Interface segregation Make modular simple interfaces rather than a huge oversized interfaces with all possible methods. Classses shouldnt need to...
Read more