Modelado sistemas utilizando Puntos de Vista (Viewpoint-Based Modeling)

Debido a la gran densidad de componentes relacionados y distribuidos con los que se construye el software actual,  se generan escenarios donde es complejo visualizar el diseño de la solución y sus dependencias. Por lo tanto,  es difícil encontrar defectos,  aplicar cambios, reutilizar componentes y  escalar a nuevas versiones.

CH_b_oKWIAEbdNJ (1)

Nowadays, software is built using a high density of related and distributed components. In this context, complex scenarios are generated where the design solution and its dependencies are difficult to handle and understand. Therefore, it is not easy to find defects, apply changes, reuse components, and scale to newer versions.

Este problema se multiplica en la medida en la que una empresa incrementa sus sistemas automatizados con arquitecturas diversas donde es difícil medir el impacto que implica cambiar o quitar una pieza de software.

The problem gets bigger whenever a company increases its automated systems using different architecture styles. Then, it’s difficult to measure the impact of deleting or changing a software piece.

Algo curioso (y a la vez muy normal) que he podido ver es que muchas de las empresas utilizan procesadores de texto y Power Point como herramientas principales para diseñar sus sistemas. No digo que esté mal, pero el propósito de estas herramientas no es ser herramientas de diseño de software.

simplyexplained

Something that I consider curious (and at the same time very normal), is that many companies use office-suite applications such as word processors or PowerPoint® as their main software design tools. I’m not saying it’s wrong, but the purpose of those kind of applications is far from being software design tools.

El problema principal, es que se genera un enfoque abierto de diseño, donde las personas tienden a no utilizar lenguajes de modelado estándares, y aun si los utilizan,  no los utilizan adecuadamente, en un documento abierto de este tipo los conceptos se combinan en una ensalada de aspectos técnicos y funcionales, cuya simbología y contenido depende de la persona que genera el documento, entonces, la interpretación del diseño es susceptible a ser distinta por cada stakeholder (Sobre todo al pasar los años).

Este problema tal vez no se vea a simple vista, pero si combinamos esto con la problematica de la complejidad del softare actual. El no tener un buen diseño de sistemas implica una pérdida del control del conocimiento depositado en el software, por lo tanto, se convierte una bola de nieve que al cabo de muchos años puede traernos grandes dolores de cabeza, sobre todo si este hecho se convierte en nuestra debilidad al competir en un mercado donde la innovación tecnológica es una claves para competir en el mercado.

Uno de los paradigmas que colabora con el buen diseño de sistemas es Viewpoint Modeling (basado en la ISO 42010 ). Permite separar el diseño por puntos de interés, para  explicar mejor este tema, vamos a hacer una comparativa entre el diseño de la arquitectura software y el diseño de la arquitectura de una casa.

El diseño de la arquitectura de una casa comprende varios planos que describen varias  perspectivas de una misma construcción, por ejemplo, un plano de plomeria que describe la instalación de cañerías y tomas de agua necesarias, otro plano que describe la instalación eléctrica, el plano de construcción que describe la disposición de las habitaciones y los pilares, etc. Todos los planos corresponden a una misma casa, sin embargo, cada  plano muestra de manera aislada un aspecto distinto de interés de un actor determinado, es decir, el electricista necesita los planos eléctricos, el albañil necesita los planos de construcción, el plomero necesita el plano plomeria(fontaneria).

Por otro lado, el arquitecto necesita ver todo en conjunto para cerciorarse de que todos los aspectos encajen sin problema (si tiene el cliente solicita ampliar una puerta, cerciorarse de que el cambio no afecta al suministro eléctrico o una cañería), es decir, tiene interés en aspectos transversales.

The main problem is that the above described situations may yield careless design approaches, which in turn make people prone to deviate from standard modeling languages; and, even if they try to use standards, the languages may not be used properly. In these kind of careless open documents all technical and functional aspects are combined into a salad of concepts where the symbolism depends of the person who produced the document. Finally, the stakeholders may produce different interpretations of such documents, especially as time goes by.

This problem may not be seen at first glance, but lacking a good system design, given the complexity of modern software development processes, involves the loss of control of the knowledge deposited in the software. This situation can easily become a snowball, eventually bringing us huge headaches, particularly when this issue becomes our weakness in the market competition where technological innovation is the key.

One of the paradigms that collaborates with good systems design is Viewpoint Modeling (based on ISO 42010). It allows us to separate the design using points of interest; to be more clear, we are going to compare between the software architecture design and the house architecture design.

The house architecture design comprises the blueprints of the same construction describing several perspectives. In this context, a blueprint describing the plumbing installation, another blueprint that describes the electrical installation and, finally, the construction blueprint describing the layout of rooms and pillars, etc. All the blueprints correspond to the same house, however, each one shows in an isolated way a different aspect of interest of a determined actor. That is, the electrician needs the electric blueprints, the mason needs the construction blueprints, the plumber needs the plumbing blueprints, etc.

In the other hand, the architect needs to see everything together to make sure that all aspects fit neatly (if the client asks to extend a door, to make sure that the change does not affect the electrical supply or a pipe), in conclusion, he has an interest in Cross-cutting aspects. 

arquitectura

De la misma manera, en el diseño de software se pueden utilizar varios planos separando los aspectos de interés por cada actor mejorando su visualización del sistema, por ejemplo, un DBA necesita un modelo de datos sus relaciones, un analista funcional necesitara visualizar/diseñar el proceso que se necesita automatizar, un desarrollador necesita visualizar la arquitectura de software para desarrollar los módulos de sistema, el encargado de infraestructura necesitara visualizar la implementación de hardware necesaria para alojar al software desarrollado. Algunos roles como los Arquitectos o los Project Managers necesitan una perspectiva transversal para asegurarse que la implementación de software cumple con los requerimientos y que se dispone de la infraestructura adecuada.

En el diseño de un sistema utilizando varias perspectivas pueden distinguir tres dominios o capas principales (algunas aplicaciones del Viewpoint Modeling utilizan una separación distinta de dominios, pero esta definición base coincide):

In the same way, several blueprints could be used to improve the visualization of the system by separating the design using each actor interest. For example, a DBA needs a data model its relationships, a functional analyst will need to visualize/design the process to be automated, a developer needs to visualize the software architecture to develop the system modules, the infrastructure manager will need to visualize the hardware implementation to host the developed software. Some roles such as Architects or Project Managers need a cross-sectional perspective to ensure that software implementation meets requirements and the available infrastructure.

Three main domains or layers can distinguished in a system design methodology that uses multiple perspectives (some Viewpoint Modeling applications use a different separation of domains, but this base definition matches):

capas

Dominio de negocio: Comprende el conocimiento de la lógica del negocio del sistema que resuelve los requerimientos del cliente, es decir, la descripción de los procesos y actores/roles que intervine en la solución, la información utilizada en cada proceso, entre otras cosas. Por ejemplo: El sistema permitirá vender libros online a cualquier persona con una cuenta asociada a PayPal, a los usuarios anónimos se les permite buscar en la tienda sin autenticarse; Usualmente el contenido de este dominio puede ser validado por roles como el cliente final, el analista funcional.

Dominio de aplicación y datos: Comprende la descripción de como el software resuelve la lógica de negocio, es decir, el diseño de la arquitectura de software, diseño de clases, modelos de datos, diseño de la lógica de programación que debe tener cada componente, lógica de que orquesta  las dependencias, entre otras cosas. Siguiendo el ejemplo anterior, el sistema de venta de libros requiere una aplicación web con un sistema de autenticación propio que permita la autenticación anónima, un componente que permita hacer de manera segura la transacción vía PayPal, un componente que gestione el inventario de libros y las ventas, un modelo de datos que contemple al menos los tipos de dato “titulo libro”, “venta” e “inventario”.

Dominio de tecnología: Comprende todo el diseño de infraestructura necesario para que el software diseñado funcione y evolucione correctamente, es decir, el diseño de red, el diseño de la infraestructura de servidores, los servicios periféricos que son necesarios como correo electrónico, active directory, entre otros. Para el sistema de venta de libros, podríamos tener en este dominio: un servidor web Tomcat, una base de datos Oracle, el framework de Spring o también: Puede ser que la implementación utilice Django sobre un PaaS en Azure, una base de datos DocumentDB.

Los componentes de los dominios se entrelazan entre si mostrándonos los tres diferentes aspectos de un mismo sistema (como “tres” caras de una moneda), el discernir los conceptos funcionales, de los de aplicación, de los técnicos, permite visualizar mejor los problemas/soluciones dentro de un dominio y su impacto en el resto de dominios. Si en el ejemplo de la venta de libros, se incluyera el pago por una tarjeta de crédito en la capa de negocio, entonces, el componente que ejecuta la transacción vía PayPal tendría que evolucionar(crecer o dividirse) para además gestionar de manera segura el pago vía tarjeta de crédito.

Una vez que hemos descrito los dominios, ahora imaginemos que en nuestra empresa, tenemos varios sistemas,  una VISTA(VIEW) pertenece a un dominio que describe un aspecto de un sistema.  Todas las vistas se relacionan entre si, y el conjunto de vistas comprende la descripción de total del un sistema. 

En el conjunto de vistas del sistema de venta libros, una vista que describe el algoritmo de búsqueda de libros en el dominio de aplicación, una vista con el diseño de infraestructura que soporta el sistema en el dominio de tecnología, paralelamente un sistema de seguridad contiene su propio conjunto de vistas, una vista del dominio de aplicación que describe el proceso de autenticación y autorización, una vista del dominio de negocio que muestra el proceso de registro de un nuevo cliente.

Business Domain:  It includes the system business logic that solves the client’s requirements, like the description of the processes and actors/roles that intervened in the solution, the information used in each process. Usually the content of this domain can be validated by roles such as the end customer, the functional analyst. For instance, an online book store sells books to anyone with an associated PayPal account, and anonymous users can search books without authenticating.

Application & Data Domain: It involves the description of how the software solves business logic, i.e. the software architecture design, class design, data models, design of the programming logic from each component of a system must have. Following previous example, the online bookstore requires a web application with its own authentication system allowing anonymous authentication; also, a component that allows to securely make the transaction via PayPal, a component that manages the books inventory, a data model that includes at least the “book title”, and “sale” and “inventory” data types.

Technology Domain:  It includes the infrastructure design so the designed software could work and evolves correctly. That is, the network design, server’s infrastructure design, the peripheral services like email, active directory, among others. For our online bookstore, we might need a Tomcat web server, an Oracle database, the Spring framework, or perhaps, the implementation uses Django on a PaaS in Azure, a Document DB database.

The components on the domains are intertwined with each other showing three different aspects of the same system (such as “three” faces of a coin), Thus, we have a better visualization of the solutions by the discernment of functional, application, and technical concepts. It allows to measure the impact on the other domains when a change is made in one of them. In the online bookstore example, if we add the functionality of adding a credit card payment method in the business layer, then the component executing the transaction via PayPal would have to evolve (grow or divide) in order to securely manage the credit card Payment.

We have introduced the domains, now imagine several systems of a company, a VIEW belongs to a domain that describes an aspect of one system. All views are related to each other, and the set of views comprises the hole system description.

In the set of the online bookstore views, we could define, a view describing the book search algorithm in the application domain, a view describing the infrastructure design on the technology domain. In parallel, a security system contains its own set of views, first an business view describing the authentication and authorization process, a business domain view that shows the process of registering a new client.


vistas

Además los conjuntos de vistas de un sistema se pueden relacionar con otros conjuntos de vistas, para describir las dependencias entre ambos sistemas. Por ejemplo, el sistema de ventas necesita del sistema de seguridad para poder vender un libro, por lo tanto, en una vista de negocio se puede describir el proceso de venta de libros que llama al proceso de autenticación descrito en la vista del sistema de seguridad.


Ahora, bajamos un nivel más, un PUNTO DE VISTA (VIEWPOINT) se refiere a una vista que resuelve una necesidad de un stakeholder. Las necesidades de un stakeholder pueden ser de análisis, diseño, toma de decisiones, etc. Por ejemplo, un analista funcional necesita un diagrama BPMN de procesos que le permita visualizar los roles que intervienen en cada funcionalidad, un desarrollador necesita un diagrama de clases de UML que le ayude a diseñar la implementación de un componente, un DBA necesita un modelo de datos Entidad Relación del sistema que se va a desplegar.

Continuando con el ejemplo anterior si un arquitecto de software necesita medir el impacto de modificar el componente de software de venta de libros para incluir el pago por tarjeta de crédito, necesita un punto de vista  que describa las dependencias del componente de software de venta de libros cuando se ejecuta el pago.

Besides, the set of a system views could be related with a set of another system views describing the dependencies between them. As an example, the online bookstore needs a security system to sell a book, in this way, a business view from the online bookstore system is related with the authentication process described in a security system.

At these point, we are going to introduce a lower level in the definition. A VIEWPOINT is related to a certain view resolving a stakeholder concern. The stakeholder’s concerns could be analysis, designing, and decision making. For instance, a business analyst needs a BPMN diagram to describe each functionality process, a developer needs a UML class diagram to design a component implementation, a DBA needs an Entity Relationship diagram.

Following the online bookstore example, a Software Architect might need to measure the impact of changing a software component in order to include a payment method using credit card, the architect concern to visualize the affected dependencies by the change. 

puntosdevistas

Cada stakeholder puede tener más de una necesidad sobre más de un dominio, por ejemplo, un arquitecto de software puede necesitar un punto de vista que le describa el negocio a alto nivel, otro punto de vista que le describa la arquitectura de software, y otro punto de vista que le muestre a alto nivel los servicios de infraestructura que soportan la arquitectura, de esta manera puede tomar decisiones cruzadas y asegurarse que tanto el software, como la infraestructura cumplen con la funcionalidad solicitada en los requerimientos. Así como las vistas los puntos de vista se relacionan entre ellos los puntos de vista también se relacionan con puntos de vista del sistema, o de otros sistemas.

Por otro lado, como cada PUNTO DE VISTA se crea a partir una cada necesidad de un stakeholder  se pueden generar PUNTOS DE VISTA multidominio, que permitan a los stakeholders que necesitan hacer análisis/diseño cruzado de los sistemas para tomar decisiones o analizar la coherencia del diseño entre los dominios.  Pero es oportuno decir, que los puntos de vista multidominio deben regirse en patrones de diseño para no caer en el problema inicial.

Each stakeholder might have more than one concern in more than one domain. For instance, a software architect might need a business viewpoint describing a system in a high live, a software point of view describing the architecture and, finally, a high-level description of the infrastructure services, in this way, the architect could take cross decisions ensuring all the combining elements comply the requirements.

Besides, each VIEWPOINT is built to resolve a stakeholder concern, the concern might generate cross domain VIEWPOINTS. These kinds of viewpoints allow the stakeholders to take cross analysis to establish a coherence between domains. Although, the cross-domain viewpoints should be designed carefully using patterns correctly if you don’t want to reproduce the problems we introduce in the first part of the article.

puntosdevistasmultidominio

Hasta aquí, hemos descrito la teoría de Viewpoint Modelling y como se definen los puntos de vista, pero se puede añadir mas de complejidad al esquema anterior añadiendo dominios transversales a los tres dominios descritos, por ejemplo, se puede añadir dominio que nos describa los requerimientos y su relación con los elementos de negocio, aplicación y tecnología. Por ejemplo, que si tengo un requerimiento de adicionar un tipo de pago éste afectara a los elementos de negocio y  al componente de pagos de la aplicación, un requerimiento de gestión de alto nivel de concurrencia de usuarios afectara a los componentes de infraestructura que gestionan el balance de carga de llamadas a los servicios. 

At these point we have introduced the viewpoint modelling theory and definitions. We could add more complexity to the technique by adding cross-domains. For instance, we could add a domain to describe the system requirements related to the business, application, and infrastructure elements. In the online bookstore example, if have a requirement to add a new payment method it affects the business elements and the payment components in the application domain. On the other hand, a high user concurrency level requirement should have an impact in the infrastructure design to be ready to load balance the services calls.

extensioncapas

Viewpoint Modeling ha sido implementado por varias propuestas de arquitectura empresarial tales como TOGAF, Zachman Framework, RM-ODP, etc.  También es la base del lenguaje de modelado de arquitectura empresarial ARCHIMATE (cuyos dominios están relacionados con los dominios  de TOGAF).  La versión 3.0 de Archimate contempla las tres capas explicadas anteriormente, además, otras tres paralelas,  y cuatro transversales (La definición completa se puede leer aquí).

Archimate provee una un conjunto de artefactos diferenciados por dominio y una serie de patrones para cada uno de sus puntos de vista. Un ejemplo de punto de vista transversal, es el Layered Viewpoint de Archimate, en el que se describe a muy alto nivel, una funcionalidad principal, los componentes que solucionan una funcionalidad y la infraestructura necesaria, el propósito de este punto de vista es resolver la necesidad de cualquier stakeholder de entender el propósito de un sistema y su implementación en un vistazo.

The Viewpoint Modeling technique has been applied by many enterprise architecture proposals like TOGAF, Zachman Framework, RM-ODP. Besides, it has been applied by the enterprise architecture modeling framework called ARCHIMATE (their domains are related with the TOGAF domains). The Archimate 3.0 version applies the tree domains we exposed before and aggregates three parallels domains plus another four cross domains (the hole definition of these version is here).

Archimate provides a set of artefacts classified by domain and a set of patterns designed to describe each point of view. As a cross-domain example, Archimate Layered Viewpoint describes a high level the main system functionality, the software components design resolving the functionality, the infrastructure holding the software design. The main propose of Layered Viewpoint is to resolve the any kind of stakeholder concern of understanding the system at first sight.

Se debe tomar en cuenta que, para diseñar utilizando Viewpoint Modeling es importante entender la diferencia entre dominios y el propósito de cada punto de vista. Los puntos de vista deben estar descritos en un lenguaje de modelado estándar que no de opción a malentendidos; No es necesario que todos los puntos de vista se describan en el mismo lenguaje de modelado pero si es necesario que exista una trazabilidad entre los lenguajes utilizados, por ejemplo, a un desarrollador le es mas útil un diagrama de clases de UML de un componente,  por otro lado a un arquitecto le es mas útil un Layered Viewpoint de Archimate para analizar la coherencia de los elementos, sin embargo, el diagrama de clases de UML corresponde a uno de los componentes descrito en Layered Viewpoint. Mas adelante podemos hablar sobre la integración de lenguajes.

En este sentido, Viewpoint Modeling, nos ayudara a simplificar la visualización del sistema de cada stakeholder debido a que se centra en sus necesidades, nos ayuda a diferenciar los conceptos por dominios para tomar mejores decisiones sobre el sistema que desarrollamos, y nos ayuda a mantener una coherencia de diseño entre los diferentes sistemas de una empresa. Esto permite que el conocimiento del software de la empresa se encuentre en el diseño y sea perdurable en el tiempo en cada uno de sus dominios.

La siguiente vez que nos encontremos frente a una presentación de Power Point para diseñar un sistema pensemos si queremos que el diseño final se mantenga en una presentación y en los posibles futuros dolores de cabeza que podríamos evitarnos si tan solo decidimos utilizar lenguajes de modelado estándar y aplicar correctamente los dominios. Dejemos que el Power Point se utilice para lo que fue creado: !presentar ideas de manera simple y visualmente bonitas!.

To design using Viewpoint Modeling, it’s important to understand the difference between domains and the purpose of each viewpoint (what concern is solving). The viewpoint should be described using standard modeling language to be clear. It’s not necessary that all the viewpoints are described in the same modeling language but, their elements should be related. For instance, Layered Viewpoint describe the main components but, one component structure is described using an UML class diagram.

Viewpoint Modeling will help us to simplify each stakeholder visualization of a system because it focusses in the stakeholder’s concerns. It helps us to clarify the concepts by domain to take better decisions over the system under construction. Finally, it helps us to maintain the coherence between all enterprise systems. In conclusion, it allows us to keep the knowledge in the design and not in the software over the time.

The next time we found ourselves designing a system using Power Point, let’s think first in the future headaches we could save us if we just decided to use standard modeling languages and applying the domains correctly. So, allow PowerPoint to be used for its main purpose: present ideas in a simple and beauty way!.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s