Arquitectura Técnica y Patrones

Curso de Arquitectura Técnica y Patrones

1. Arquitectura Técnica y Patrones Eric Barceló Monroy - NobleProg
2. Cohesión de Sistema y Componente • Uno de los aspectos más complicados a la hora de desarrollar software es decidir cómo asignar las distintas responsabilidades de la aplicación, en qué componentes repartirlas y cómo agruparlas. • Cohesión se refiere a lo estrecha que es la relación entre los componentes de algo. • Por ejemplo, una clase tendrá una cohesión alta si sus métodos están relacionados entre sí. • En componentes de mayor tamaño, como paquetes o librerías, tendríamos una cohesión alta cuando las clases que lo forman están muy relacionadas entre sí.
3. Cohesión de Sistema y Componente • El acoplamiento es la manera como se relacionan varios componentes entre sí. Si existen muchas relaciones entre los componentes, con muchas dependencias entre ellos, tendremos un grado de acoplamiento alto. Si los componentes son independientes unos de otros, el acoplamiento será bajo. • Puede, entonces, existir acoplamiento entre los métodos de una misma clase (o las funciones de un módulo), entre distintas clases o entre distintos paquetes. • Además, existen varios tipos de acoplamiento, como acoplamiento a través de datos comunes, acoplamiento temporal (es necesario utilizar los componentes en un orden concreto), etc.
4. Cohesión vs. Acoplamiento • Está claro que lo ideal es situarnos en el cuadrante de alta cohesión y bajo acoplamiento, pero en la realidad no siempre podemos lograr una situación así.
5. Distintos niveles, distintas prioridades • Dentro de una funcionalidad concreta, prefiero primar la alta cohesión. • Cuando se trata de coordinar las distintas funcionalidades de una aplicación, le doy más importancia a conseguir un bajo acoplamiento. • A distintos niveles de Arquitectura Tecnológica, las prioridades sobre estas dos características de sus componentes van cambiando, además de ser también dependientes de las decisiones de cada proyecto (o de cada equipo de desarrollo.
6. Arquitectura de software • De acuerdo al Software Engineering Institute (SEI), la Arquitectura de Software se refiere a “las estructuras de un sistema, compuestas de elementos con propiedades visibles de forma externa y las relaciones que existen entre ellos.” Los elementos pueden ser entidades que existen en tiempo de ejecución (objetos, hilos), entidades lógicas que existen en tiempo de desarrollo (clases, componentes) y entidades físicas (nodos, directorios). • Por otro lado, las relaciones entre elementos dependen de propiedades visibles (o públicas) de los elementos, quedando ocultos los detalles de implementación. Finalmente, cada conjunto de elementos relacionados de un tipo particular corresponde a una estructura distinta, de ahí que la arquitectura esta compuesta por distintas estructuras.
7. ¿Por qué es importante la arquitectura de software? • La manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de éste para satisfacer lo que se conoce como los atributos de calidad del sistema: el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema, y que son parte de los requerimientos no funcionales del sistema y características que deben expresarse de forma cuantitativa.
8. ¿Por qué es importante la arquitectura de software? • La arquitectura de software juega un papel fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se enfoca en partir el sistema en componentes que serán desarrollados por individuos o grupos de individuos. La identificación de esta estructura de asignación de trabajo es esencial para apoyar las tareas de planeación del proyecto. • Finalmente, los diseños arquitectónicos que se crean en una organización pueden ser reutilizados para crear sistemas distintos. Esto permite reducir costos y aumentar la calidad, sobre todo si dichos diseños han resultado previamente en sistemas exitosos.
9. El ciclo de desarrollo de la arquitectura • El desarrollo de la arquitectura de un sistema (software), que precede a la construcción del sistema, esta dividido en las siguientes etapas: requerimientos, diseño, documentación y evaluación. • Requerimientos. La etapa de requerimientos se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura. Como se mencionó anteriormente, los atributos de calidad juegan un papel preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos. Otros requerimientos, sin embargo, son también relevantes para la arquitectura, estos son los requerimientos funcionales primarios y las restricciones.
10. El ciclo de desarrollo de la arquitectura • Diseño. La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura. La creación de estas estructuras se hace en base a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante todo satisfacer los requerimientos que influencian a la arquitectura, y no simplemente incorporar diversas tecnologías por que están “de moda”.
11. El ciclo de desarrollo de la arquitectura • Documentación. Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces depende de que dicho diseño sea documentado de forma apropiada. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de distintas vistas. Una vista generalmente contiene un diagrama, además de información adicional, que apoya en la comprensión de dicho diagrama.
12. El ciclo de desarrollo de la arquitectura • Evaluación. Dado que la arquitectura de software juega un papel crítico en el desarrollo, es conveniente evaluar el diseño una vez que este ha sido documentado con el fin de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una actividad que se puede realizar de manera temprana (aún antes de codificar), y que el costo de corrección de los defectos identificados a través de la evaluación es mucho menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido construido.
13. Actividades del arquitecto de software • Concepción del proyecto. Un proyecto de desarrollo de software inicia por una etapa de generar una propuesta técnica y económica. Aquí, el arquitecto juega un papel preponderante pues en él recae la responsabilidad de realizar una traducción de las necesidades que expresa el cliente hacia una solución técnica preliminar, que es una pieza clave para producir una estimación del esfuerzo necesario para realizar el desarrollo. El arquitecto puede también participar en el trabajo de estimación del sistema. Aquí, el arquitecto debe hacer uso de habilidades técnicas (“duras”) y no-técnicas (“suaves”). Como parte de las habilidades técnicas, debe poder identificar estilos arquitectónicos y tecnologías que sean apropiados para resolver el problema y proponer una solución preliminar. Como parte de las habilidades no-técnicas, debe ser capaz de realizar un análisis de las necesidades del cliente, especialmente desde una perspectiva de negocio y poder explicar la solución técnica que propone a los distintos involucrados del proyecto.
14. Actividades del arquitecto de software • Requerimientos. Durante la fase de requerimientos, el arquitecto de software se involucra con los requerimientos que influyen en la arquitectura y en los atributos de calidad del sistema. El arquitecto debe preocuparse por que se identifiquen atributos de calidad pertinentes para el sistema (alineados a los objetivos de negocio) y que las métricas asociadas estén justificadas y expresadas de manera cuantitativa y medible. En caso de que el cliente solicite atributos de calidad con métricas muy demandantes, debe ser capaz de entender la justificación de esas métricas y poder negociar con el cliente para establecer métricas adecuadas. Nuevamente, el arquitecto debe emplear aquí una combinación de habilidades “duras” y “suaves” con el fin de lograr una identificación adecuada de los requerimientos que influirán sobre el diseño arquitectónico.
15. Actividades del arquitecto de software • Diseño del sistema. La etapa de diseño del sistema es aquella donde el arquitecto de software juega el papel principal, particularmente al momento de diseñar la arquitectura. Aquí el arquitecto debe hacer uso de todas sus habilidades técnicas con el fin de establecer una solución técnica pertinente que satisfaga, en la medida de lo posible, los requerimientos que influyen en la arquitectura. La realización del diseño requiere de muchos conocimientos técnicos.
16. Actividades del arquitecto de software • Durante la etapa de diseño, el arquitecto debe también hacer uso de muchas habilidades no-técnicas. La comunicación durante esta etapa es fundamental, ya que el arquitecto debe ser capaz de comunicar el diseño, y las decisiones que lo llevaron al mismo, ya sea de forma escrita, como parte de la documentación de la arquitectura, o bien de forma oral al explicar el diseño de la arquitectura al equipo de desarrollo. Durante la evaluación del diseño de la arquitectura, el arquitecto debe ser capaz de presentar el contexto del problema y el diseño de la arquitectura al comité de evaluación, y debe ser capaz de responder a las preguntas de dicho comité, o bien de aceptar las observaciones que se hacen al diseño.
17. Actividades del arquitecto de software • Construcción y pruebas del sistema. Durante de la construcción del sistema, el esfuerzo técnico del arquitecto disminuye, aunque ésto no significa que ya no se realizan actividades técnicas. En esta etapa el arquitecto debe terminar de completar las partes faltantes del diseño de la arquitectura y corregir las decisiones previas que hayan resultado ser equivocadas. Desde un punto de vista no-técnico, el arquitecto debe enfocarse en cuidar que el sistema se desarrolle de acuerdo a la arquitectura que se definió para el mismo. Aquí el arquitecto juega un papel de mentor y muchas veces debe explicar cuestiones del diseño del sistema al equipo de desarrollo. El arquitecto puede también realizar actividades de aseguramiento de calidad, ya que su nivel técnico y conocimiento del dominio del problema le da una ventaja para identificar problemas que posiblemente podrían no ser identificados por desarrolladores. Al momento de realizar pruebas del sistema, la participación del arquitecto es importante, particularmente al momento de realizar pruebas relativas a los atributos de calidad del sistema.
18. Actividades del arquitecto de software • Liberación. Al momento de implantar el sistema en el ambiente productivo, muchas veces es necesario realizar ajustes finos sobre el sistema, en particular una vez que el sistema ya está operando en el ambiente de uso definitivo. La participación del arquitecto puede estar enfocada a realizar ajustes finos de la aplicación con el fin de lograr un funcionamiento óptimo de la misma. El rol de arquitecto de software es un rol complejo que requiere de una combinación equilibrada de habilidades técnicas y no-técnicas que son indispensables en las distintas etapas del desarrollo de un sistema.
19. Arquitectura técnica y empresarial Existen cuatro formas establecidas de arquitectura tecnológica, cada una con un alcance distinto: • Arquitectura de componentes • Arquitectura de aplicaciones • Arquitectura de integración • Arquitectura de tecnología empresarial
20. Arquitectura de componentes • En un entorno informático distribuido, una arquitectura de componentes representa la estructura física de un programa de software individual que existe como componente. • Lo que distingue a un componente de otros programas de software es que está diseñado deliberadamente para formar parte de un todo mayor. • Debido a que los componentes están diseñados para ser compuestos, generalmente dependen de otros programas de software (generalmente otros componentes).
21. Arquitectura de aplicaciones • Una arquitectura de aplicación es una arquitectura de tecnología con un límite físico limitado al entorno de implementación de una aplicación o sistema en particular. • En un entorno informático distribuido, una arquitectura de aplicación puede abarcar varias arquitecturas de componentes.
22. Arquitectura de integración • Una arquitectura de integración es la arquitectura tecnológica de dos o más aplicaciones o sistemas conectados. • Esto incluye todas las tecnologías, recursos o extensiones añadidas para permitir su integración. • Muchas arquitecturas de integración incluyen plataformas de middleware y extensiones de adaptador o puente asociadas.
23. Arquitectura de tecnología empresarial • Una arquitectura de tecnología empresarial es generalmente una documentación de lo que existe dentro de un entorno empresarial determinado. • Una especificación de arquitectura de tecnología empresarial abarcará (o referencia) arquitecturas de componentes, aplicaciones e integración. • Esta especificación también puede actuar como una documentación formal de la infraestructura empresarial.
24. Arquitectura tecnológica y empresarial Tipos de arquitectura y ámbito • Cada tipo de arquitectura establece un ámbito que está naturalmente abarcado por otro, especialmente en un entorno distribuido.
25. Arquitectura técnica y empresarial • “The Open Group Architecture Framework (TOGAF)” (o Esquema de Arquitectura del Open Group, en español), es una metodología de trabajo que propone un ciclo de desarrollo de arquitecturas (ADM) basado en fases e iteraciones para obtener arquitecturas empresariales específicas para la organización. • TOGAF está compuesto por cuatro arquitecturas: Arquitectura de Negocio, Arquitectura de Información, Arquitectura de Aplicaciones y Arquitectura Técnica.
26. Arquitectura técnica y empresarial • Arquitectura técnica: Las capacidades lógicas de software y hardware que se requieren para admitir la implementación de servicios empresariales, de datos y de aplicaciones. Esto incluye infraestructura de TI, middleware, redes, comunicaciones, procesamiento y estándares. • Arquitectura empresarial: La estrategia comercial, el gobierno, la organización y los procesos comerciales clave. • Están a los extremos de la propuesta de TOGAF.
27. Arquitectura técnica y empresarial • Al centro del marco TOGAF se encuentra la Metodología de Desarrollo de Arquitectura (ADM), documentado en la Parte II de la norma. La Capacidad de Arquitectura (documentada en la Parte VI de la norma) opera la metodología, que está respaldada por una serie de pautas y técnicas (documentadas en la Parte III de la norma y la Biblioteca TOGAF). Esto produce contenido para ser almacenado en el repositorio (documentado en la Parte IV de la norma), que se clasifica de acuerdo con el Enterprise Continuum (documentado en la Parte V de la norma). El repositorio se puede completar inicialmente con los Modelos de referencia TOGAF y otros materiales de referencia (documentados en la Biblioteca TOGAF).
28. Metodología de Desarrollo de la Arquitectura • Se muestra la estructura básica del ADM. • A lo largo del ciclo de ADM, debe haber una validación frecuente de los resultados con respecto a las expectativas originales, tanto para todo el ciclo de ADM como para la fase particular del proceso. • La fase de Gestión de requisitos es una fase continua que garantiza que cualquier cambio en los requisitos se maneje a través de procesos de gobierno apropiados y se refleje en todas las demás fases.
29. Entregables, artefactos y bloques de construcción • Un entregable es un trabajo que se especifica contractualmente y es revisado formalmente, acordado y firmado por las partes interesadas. • Un artefacto es un trabajo arquitectónico que describe un aspecto de la arquitectura. • Un bloque de construcción representa un componente (potencialmente reutilizable) de la capacidad empresarial que se puede combinar con otros bloques de construcción para proporcionar arquitecturas y soluciones.
30. Arquitectura Orientada a Servicios La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es un estilo de arquitectura de TI que se apoya en la orientación a servicios. La orientación a servicios es una forma de pensar en servicios, su construcción y sus resultados. Un servicio es una representación lógica de una actividad de negocio que tiene un resultado de negocio específico (ejemplo: comprobar el crédito de un cliente, obtener datos de clima, consolidar reportes de perforación) El estilo de arquitectura SOA se caracteriza por: • Estar basado en el diseño de servicios que reflejan las actividades del negocio en el mundo real, estas actividades hacen parte de los procesos de negocio de la compañía. • Representar los servicios utilizando descripciones de negocio para asignarles un contexto de negocio. • Tener requerimientos de infraestructura específicos y únicos para este tipo de arquitectura, en general se recomienda el uso de estándares abiertos para la interoperabilidad y transparencia en la ubicación de servicios. • Estar implementada de acuerdo con las condiciones específicas de la arquitectura de TI en cada compañía. • Requerir un gobierno fuerte sobre las representación e implementación de servicios. • Requerir un conjunto de pruebas que determinen que es un buen servicio.
31. Arquitectura Orientada a Servicios El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos en el manifiesto SOA. Por otra parte la aplicación de la orientación a servicios se divide en dos grandes etapas: 1. Análisis orientado a servicios (Modelado de servicios) 2. Diseño orientado a servicios, con ocho principios de diseño que se aplican sobre cada uno de los servicios: • Contrato de servicio estandarizado: Los contratos de servicio cumplen con los mismos estándares de diseño. • Bajo acoplamiento: Los servicios evitan acoplarse a la tecnología que los implementa y a su vez reducen el acoplamiento impuesto a los consumidores. • Abstracción: Los contratos presentan la información mínima requerida y la información de los servicios se limita a los expuesto en el contrato. • Reusabilidad: Los servicios expresan y contienen lógica de negocio independiente del consumidor y su entorno, por lo tanto se convierten en activos de la empresa. • Autonomía: Los servicios deben tener un gran control de los recursos tecnológicos sobre los cuales están implementados. • Sin estado: El servicio reduce el consumo de servicios al delegar el manejo de estados (sesiones) cuando se requiera. • Garantizar su descubrimiento: Lo servicios cuentan con metadata que permite descubrirlos e interpretar el servicio en términos de negocio. • Preparado para ser usado en composiciones: Los servicios pueden hacer parte de una composición sin importar el tamaño y complejidad de la misma.
32. Beneficios de SOA Los principales beneficios que puede obtener una organización que adopte SOA son: • Mejora en los tiempos de realización de cambios en procesos • Facilidad para evolucionar a modelos de negocios basados en tercerización • Facilidad para abordar modelos de negocios basados en la interoperabilidad entre sistemas y aplicaciones diferentes, lo cual mejora la comunicación y la capacidad de respuesta con sistemas externos • Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio • Facilidad para la integración de tecnologías disímiles • Mejora en la toma de decisiones: la organización dispone de mayor información y más actualizada, lo que le permite una respuesta rápida y eficaz cuando surgen problemas o cambios • Aplicaciones flexibles: la orientación a servicios permite desarrollar aplicaciones con independencia de las plataformas y lenguajes de programación que realizan los procesos • Aplicaciones reutilizables y adaptables: permite que las aplicaciones existentes puedan ser reutilizadas y adaptadas a nuevos entornos con facilidad, optimizando los recursos empleados en su desarrollo • Reducción de costos: el costo de ampliar o crear nuevos servicios se reduce considerablemente tanto en aplicaciones nuevas como ya existentes
33. Arquitectura SOA y Microservicios • La forma más sencilla de entender qué es SOA es imaginando un patrón de arquitectura de software, cuyos componentes de aplicación proporcionan servicios a otros componentes, a través de un protocolo de comunicaciones que emplea una red. Estas comunicaciones pueden variar en complejidad e ir, desde la simple transferencia de datos a la coordinación de varios servicios para establecer su conexión. • Por su parte, los microservicios son también un patrón de arquitectura de software oriantada a servicios, construido en base a aplicaciones de alto desempeño, escalabilidad y confiabilidad y los pequeños procesos independientes que las componen, comunicándose entre sí mediante APIs agnósticas del lenguaje.
34. Arquitectura de Microservicios • Se considera a la arquitectura de microservicios como una forma complementaria de extender una arquitectura orientada a servicios. • La arquitectura de microservicios es una aproximación para el desarrollo de software que consiste en construir ciertas partes una aplicación SOA como un conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican con mecanismos ligeros. • Cada microservicio se encarga de implementar una funcionalidad altamente focalizada, que tiene requerimientos muy demandantes en cuanto a desempeño, confiabilidad o disponibilidad. • Cada microservicio es desplegado de forma independiente y puede estar programado en distintos lenguajes y usar diferentes tecnologías de almacenamiento de datos. • En esta arquitectura normalmente se sigue la idea de que un equipo debe estar a cargo de un microservicio durante todo el ciclo de vida del mismo, desde la etapa de diseño y construcción, la fase de producción y hasta la de mantenimiento. • Suele acompañarse de tecnologías que complementan sus capacidades, como DevOps y contenedores.
35. Arquitectura de software • El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo. • El no crear este diseño desde etapas tempranas del desarrollo puede limitar severamente el que el producto final satisfaga las necesidades de los clientes. Además, el costo de las correcciones relacionadas con problemas en la arquitectura es muy elevado. Es así que la arquitectura de software juega un papel fundamental dentro del desarrollo.
36. Diseño de software • Este término se refiere más bien al diseño de cada uno de los distintos componente que, en conjunto, conforman la arquitectura de un sistema. Ya sea que el sistema esté dividido en módulos, componentes, servicios o como quiera que se denominen sus distintas partes, el diseño de cada una de ellas, de acuerdo con sus requerimientos específicos, es lo que llamamos diseño de software. • Por ejemplo, en las partes de un sistema que presentan su funcionalidad al usuario final a través de una interfaz de usuario (que ahora acostumbra a ser gráfica), el diseño gráfico o de la interacción con el usuario forma parte de este diseño de software.
37. Modelado de software • El término “modelado de software” se refiere a la representación de un diseño, ya sea de una parte o de toda la arquitectura completa, mediante artefactos que permiten la visualización del producto como si estuviera terminado, ya sea simplemente en papel, como cuando usamos diagramas de UML, o en su destino final, como cuando creamos prototipos que simulan el funcionamiento que tendrá el sistema una vez terminado de desarrollar (como las maquetas que hace un arquitecto tradicional de su proyecto, para presentarlo a los interesados). • Existen diversas herramientas para hacer este tipo de modelado, dependiendo de el tipo de modelo que deseamos presentar, de acuerdo con el auditorio al que habrá de presentarse.
38. Ortogonalidad • La ortogonalidad es un concepto crítico a la hora de crear sistemas fáciles de diseñar, probar, compilar y extender. • En geometría, la ortogonalidad existe cuando dos líneas se encuentran en un ángulo recto, ortogonalidad = perpendicularidad, ambas líneas son independientes. Muévete en cualquiera de los ejes y tu proyección en el otro eje no cambia. • En computación el término ha venido significando un tipo de independencia o disociación. Dos o más cosas son ortogonales si cambios en una no afectan a ninguna de las otras. En un sistema bien diseñado, el código de la base de datos será ortogonal a la interfaz de usuario, puedes cambiar la interfaz sin afectar la base de datos, y cambiar bases de datos sin cambiar la interfaz.
39. Beneficios de la Ortogonalidad Los sistemas no ortogonales son inherentemente difíciles de cambiar y de controlar. Cuando los componentes de cualquier sistema son altamente interdependientes, no hay tal cosa como un pequeño cambio local. 1. Elimina los efectos negativos de que existan componentes no relacionados: Queremos diseñar componentes que sean autocontenidos, independientes y con un propósito bien definido (lo que se conoce tambiéncomo cohesión). Cuando estos componentes son aislados unos del resto, sabes que puedes cambiar uno sin tener que preocuparte por los otros. Siempre y cuando no cambies las interfaces externas para utilizar estos componentes, puedes estar cómodo de que no causarás problemas que dañen el resto del sistema.
40. Beneficios de la Ortogonalidad Los dos beneficios más importantes que obtienes de escribir sistemas ortogonales son: Mayor Productividad y Disminución de Riesgo. 2. Mayor Productividad Los cambios son localizados, el tiempo de desarrollo y pruebas se reducen. Es más fácil escribir código relativamente corto, componentes auto-contenidos, que un bloque grande de código. Esto promueve el reuso. Si los componentes tienen propósitos específicos con responsabilidades bien definidas, estos componentes pueden ser combinados con nuevos componentes en formas que en principio no fueron imaginados por el programador original. Mientras más disasociado tu sistema, más fácil de reconfigurar, extender o rediseñar será. La combinación de componentes ortogonales resulta en más funcionalidad por unidad de esfuerzo.
41. Beneficios de la Ortogonalidad 3. Disminución de Riesgo Si hay porciones de código que ya no nos sirven, si un módulo está enfermo, es más fácil de aislarlo y de evitar causar daños al resto del sistema. También es más fácil hacer un transplante de ese componente por un nuevo componente similar, pero nuevo y saludable. Los sistemas se hacen menos frágiles, si haces cambios en una parte de un sistema ortogonal cualquier posible problema que puedas introducir se verá restringido a sólo esa área. No atas tu sistema a un proveedor específico, a un producto o a una plataforma, pues las interfaces que interactúan con estos sistemas o componentes de terceros pueden ser aisladas y remplazadas por otras opciones. Es más fácil de probar cuando las piezas no dependen del todo, un sistema probado es mucho más robusto y confiable.
42. Ley de Conway La Ley de Conway es un enunciado formulado por el informático estadounidense Melvin Conway en 1967, que dice lo siguiente: “Las organizaciones dedicadas al diseño de sistemas [...] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones.” 1 La afirmación se basa en que dos módulos o subsistemas no pueden interactuar correctamente a menos que los diseñadores de ambos subsistemas se comuniquen entre sí. Por lo tanto, la estructura de las interfaces del sistema será congruente con las estructuras sociales de la organización que produce el sistema. [1] Conway, Melvin E. (abril de 1968). «How Do Committees Invent?»
43. Descomposición Modular • Los módulos son estructuras del sistema que tienen algoritmos de evaluación de confiabilidad bien establecidos. La técnica de descomposición modular identifica estos módulos en sistemas complejos y utiliza sus algoritmos de evaluación de confiabilidad eficientes para la evaluación de la fiabilidad de todo el sistema. En este artículo, proporcionamos las definiciones formales de módulos y descomposición modular para el análisis de confiabilidad del sistema, ilustramos la técnica de descomposición modular y describen algoritmos de evaluación de confiabilidad para varios módulos bien estudiados.
44. Arquitectura Monolítica • Monolítico es un término utilizado principalmente en la arquitectura de software que significa que un sistema está estrechamente acoplado en lugar de tener sus componentes como servidor back-end, base de datos, servidor de mensajería, etc. que se ejecutan por separado. • Las aplicaciones monolíticas son más fáciles de escribir y administrar sin mucho alboroto, siempre y cuando el tráfico en la aplicación llegara hasta cierto límite. Uno o un par de back-end, servidores de bases de datos, etc. hicieron la tarea. • Una arquitectura monolítica puede ser modular, pero sigue siendo monolítica porque todos sus módulos o componentes comparten un mismo ciclo de vida, no gozan de independencia entre sí.
45. Arquitectura Jerárquica • La arquitectura jerárquica ve todo el sistema como una estructura jerárquica, en la que el sistema de software se descompone en módulos lógicos o subsistemas en diferentes niveles de la jerarquía. Este enfoque se utiliza normalmente en el diseño de software del sistema, como protocolos de red y sistemas operativos. • En el diseño de jerarquía de software del sistema, un subsistema de bajo nivel proporciona servicios a sus subsistemas de nivel superior adyacentes, que invocan los métodos en el nivel inferior. La capa inferior proporciona funciones más específicas, como servicios de E/S, transacciones, programación, servicios de seguridad, etc. La capa intermedia proporciona más funciones dependientes del dominio, como la lógica de negocios y los servicios de procesamiento de núcleos. Además, la capa superior proporciona una funcionalidad más abstracta en forma de interfaz de usuario como GUI, instalaciones de programación de shell, etc.
46. Arquitectura Jerárquica • También se usa en la organización de las bibliotecas de clases, como la biblioteca de clases .NET en la jerarquía de espacios de nombres. Todos los tipos de diseño pueden implementar esta arquitectura jerárquica y a menudo se combinan con otros estilos de arquitectura. • Los estilos arquitectónicos jerárquicos se dividen en: • Subrutina principal • Maestro-esclavo
47. Arquitectura Jerárquica – Subrutina principal • El objetivo de este estilo es reutilizar los módulos y desarrollar libremente módulos individuales o subrutinas. En este estilo, un sistema de software se divide en subrutinas mediante el uso de refinamiento de arriba hacia abajo de acuerdo con la funcionalidad deseada del sistema. Estos refinamientos conducen verticalmente hasta que los módulos descompuestos son lo suficientemente simples como para tener su exclusiva responsabilidad independiente. La funcionalidad puede ser reutilizada y compartida por varios llamadores en las capas superiores. • Hay dos maneras en que los datos se pasan como parámetros a las subrutinas: • Pasar por valor: las subrutinas solo usan los datos anteriores, pero no pueden modificarlos. • Pasar por referencia: las subrutinas utilizan, así como cambian el valor de los datos a los que hace referencia el parámetro.
48. Subrutina principal – ventajas y desventajas Ventajas • Fácil de descomponer el sistema basado en el refinamiento de la jerarquía. • Se puede utilizar en un subsistema de diseño orientado a objetos. Desventajas • Vulnerable ya que contiene datos compartidos globalmente. • El acoplamiento estrecho puede causar más efectos de ondulación de los cambios.
49. Arquitectura Jerárquica – Maestro-esclavo • Este enfoque aplica el principio de "dividir y conquistar" y admite el cálculo de fallas y la precisión computacional. Es una modificación de la arquitectura de la subrutina principal que proporciona fiabilidad del sistema y tolerancia a fallos. • En esta arquitectura, los esclavos proporcionan servicios duplicados al maestro, y el maestro elige un resultado particular entre los esclavos por una cierta estrategia de selección. Los esclavos pueden realizar la misma tarea funcional por diferentes algoritmos y métodos o una funcionalidad totalmente diferente. Incluye computación paralela en la que todos los esclavos se pueden ejecutar en paralelo. La implementación del patrón Master-Slave sigue cinco pasos. 1. Especifique cómo se puede dividir el cálculo de la tarea en un conjunto de subtareas iguales e identifique los subservicios necesarios para procesar una subtarea. 2. Especifique cómo se puede calcular el resultado final de todo el servicio con la ayuda de los resultados obtenidos del procesamiento de subtareas individuales. 3. Defina una interfaz para el subservicio identificado en el paso 1. Será implementado por el esclavo y utilizado por el maestro para delegar el procesamiento de subtareas individuales. 4. Implemente los componentes esclavos de acuerdo con las especificaciones desarrolladas en el paso anterior. 5. Implemente el maestro de acuerdo con las especificaciones desarrolladas en los pasos 1 a 3.
50. Maestro-esclavo – ventajas y desventajas Ventajas • Cálculo más rápido y fácil escalabilidad. • Proporciona robustez ya que los esclavos se pueden duplicar. • El esclavo se puede implementar de manera diferente para minimizar los errores semánticos. Desventajas • Sobrecarga de comunicación. • No todos los problemas se pueden dividir. • Difícil de implementar y problema de portabilidad. Aplicaciones • Adecuado para aplicaciones donde la fiabilidad del software es un problema crítico. • Ampliamente aplicado en las áreas de computación paralela y distribuida.
51. Arquitectura centralizada (Mediador) • Un sistema centralizado es un sistema en el que un individuo, un grupo de personas o una entidad corporativa tiene todo el control sobre la funcionalidad del sistema, los usuarios finales no tienen voz en el diseño arquitectónico, la disponibilidad de características o la funcionalidad de las aplicaciones, no deciden cómo deben funcionar los sistemas y no tienen control sobre los datos. El término centralizado se utiliza cuando hablamos de control. • Las entidades corporativas tienen los derechos de modificar o eliminar nuestros datos sin ningún permiso. • Un sistema centralizado tiene sus riesgos, por ejemplo, un único punto de falla. Si la compañía deja de funcionar todos sus datos se han ido, para siempre. Y esto ha sucedido en el pasado.
52. Arquitectura Manejada por Eventos • La arquitectura manejada por eventos es un paradigma de arquitectura de software que promueve la producción, detección, consumo y reacción a eventos. • Un evento se define como un cambio significativo en el estado. Desde una perspectiva formal, lo que se produce, publica, propaga, detecta o consume es un mensaje (normalmente asincrónico) llamado notificación de evento, y no el evento en sí, que es el cambio de estado que desencadenó la emisión del mensaje. Los eventos no viajan, simplemente ocurren. Sin embargo, el término evento se utiliza a menudo para denotar el propio mensaje de notificación, lo que puede llevar a cierta confusión. Esto se debe a que las arquitecturas controladas por eventos a menudo se diseñan sobre arquitecturas controladas por mensajes, donde dicho patrón de comunicación requiere que una de las entradas sea solo de texto, el mensaje, para diferenciar cómo se debe controlar cada comunicación.
53. Arquitectura Manejada por Eventos • Patrón arquitectónico que se aplica mediante el diseño de sistemas que transmiten eventos entre componentes y servicios de software libres de acoplamiento. Consta de emisores de eventos (o agentes), consumidores de eventos (o receptores) y canales de eventos. Los emisores detectan, recopilan y transfieren eventos. Un emisor no conoce a los consumidores de los eventos que transfieren, ni siquiera sabe si existe un consumidor, y en caso de que exista, no sabe cómo se utilizará o procesará el evento. Los consumidores reaccionan tan pronto como se presenta un evento. La reacción podría o no ser proporcionada completamente por el propio consumidor. Los canales de eventos son conductos por los que los eventos se transmiten de los emisores a sus consumidores. El conocimiento de la correcta distribución de los eventos está presente exclusivamente dentro del canal de eventos. La implementación física middleware orientado a mensajes o en comunicación punto a punto, que podría requerir un marco transaccional más adecuado.
54. Arquitectura basada en interrupciones • Una interrupción consiste en un mecanismo que provoca la alteración del orden lógico de ejecución de las instrucciones como respuesta a un evento externo, generado por hardware o software, en forma asincrónica al programa que está siendo ejecutado y fuera de su control. • Esta arquitectura se refiere a una forma de diseño que implica que un programa esté en un “loop” esperando por la aparición de algún tipo de interrupción. Cuando ésta aparece, el programa la procesa y vuelve al bucle de espera por una nueva interrupción. • Cuando ocurre una interrupción la próxima instrucción a ser ejecutada no es la que corresponde a la secuencia instrucciones del programa que se está ejecutando, sino que dicha secuencia se modifica y se pasa a ejecutar otra instrucción (la primera de la rutina de servicio de la interrupción correspondiente). Además, no es el programa mismo el que la genera, sino otro programa, o incluso algún dispositivo de hardware. Y finalmente, el programa que está siendo ejecutado no tiene control sobre el momento en que este mecanismo se dispara, ni sobre la propia ocurrencia del fenómeno. Es decir que no hay sincronía entre la ejecución del programa y la invocación a esa rutina "especial" disparada por la interrupción.
55. Modelo de referencia OSI La mayoría de los conjuntos de protocolos de red se estructuran en capas. La Organización Internacional para la Estandarización (ISO) ha diseñado el modelo de referencia de Interconexión de Sistemas Abiertos (OSI) que utiliza capas estructuradas. El modelo OSI describe una estructura con siete capas para las actividades de red. Cada capa tiene asociados uno o más protocolos. Las capas representan las operaciones de transferencia de datos comunes a todos los tipos de transferencias de datos entre las redes de cooperación. Este modelo define operaciones conceptuales que no son exclusivas de un conjunto de protocolos de red particular. Capa Nombre Descripción 7 Aplicación Se compone de los servicios y aplicaciones de comunicación estándar que puede utilizar todo el mundo. 6 Presentación Se asegura de que la información se transfiera al sistema receptor de un modo comprensible para el sistema. 5 Sesión Administra las conexiones y terminaciones entre los sistemas que cooperan. 4 Transporte Administra la transferencia de datos. Asimismo, garantiza que los datos recibidos sean idénticos a los transmitidos. 3 Red Administra las direcciones de datos y la transferencia entre redes. 2 Vínculo de datos Administra la transferencia de datos en el medio de red. 1 Física Define las características del hardware de red.
56. Arquitectura por capas • El patrón de arquitectura más común es el patrón de arquitectura en capas, también conocido como patrón de arquitectura de n niveles. Este patrón es el estándar de facto para la mayoría de las aplicaciones Java EE y por lo tanto es ampliamente conocido por la mayoría de los arquitectos, diseñadores y desarrolladores. El patrón de arquitectura en capas coincide estrechamente con las estructuras organizativas y de comunicación de TI tradicionales que se encuentran en la mayoría de las empresas, lo que lo convierte en una opción natural para la mayoría de los esfuerzos de desarrollo de aplicaciones empresariales. • Los componentes dentro del patrón de arquitectura en capas se organizan en capas horizontales, cada capa que realiza un rol específico dentro de la aplicación (por ejemplo, lógica de presentación o lógica de negocios). Aunque el patrón de arquitectura en capas no especifica el número y los tipos de capas que deben existir en el patrón, la mayoría de las arquitecturas en capas constan de cuatro capas estándar: presentación, negocio, persistencia y base de datos .
57. Arquitectura por capas
58. Arquitectura por capas • En algunos casos, la capa de negocio y la capa de persistencia se combinan en una única capa de negocio, especialmente cuando la lógica de persistencia (por ejemplo, SQL o HSQL) está incrustada en los componentes de la capa de negocio. Por lo tanto, las aplicaciones más pequeñas pueden tener solo tres capas, mientras que las aplicaciones empresariales más grandes y complejas pueden contener cinco o más capas. • Cada capa del patrón de arquitectura en capas tiene un rol y una responsabilidad específicos dentro de la aplicación. Por ejemplo, una capa de presentación sería responsable de controlar toda la interfaz de usuario y la lógica de comunicación del explorador, mientras que una capa de negocio sería responsable de ejecutar reglas de negocio específicas asociadas a la solicitud. Cada capa de la arquitectura forma una abstracción en torno al trabajo que debe realizarse para satisfacer una solicitud empresarial determinada.
59. Arquitectura por capas • Una de las características poderosas del patrón de arquitectura en capas es la separación de preocupaciones entre los componentes. Los componentes dentro de una capa específica solo tratan con la lógica que pertenece a esa capa. Por ejemplo, los componentes de la capa de presentación solo tratan con lógica de presentación, mientras que los componentes que residen en la capa de negocio solo se ocupan de la lógica de negocios. Este tipo de clasificación de componentes facilita la construcción de roles y modelos de responsabilidad eficaces en su arquitectura, y también facilita el desarrollo, la prueba, el gobierno y el mantenimiento de aplicaciones mediante este patrón de arquitectura debido a interfaces de componentes bien definidas y un ámbito limitado de componentes. • El concepto de capas de aislamiento significa que los cambios realizados en una capa de la arquitectura generalmente no afectan o afectan a los componentes de otras capas: el cambio se aísla a los componentes dentro de esa capa, y posiblemente a otra capa asociada.
60. Principios de Diseño Orientado a Objetos • La programación orientada a objetos es un paradigma de programación basado en el concepto de "objetos", que pueden contener datos, en forma de campos, y código, en forma de rutinas. Una característica importante de los objetos es la de que los procedimientos de un objeto pueden acceder y modificar los campos de datos del objeto con el que están asociados. Tiene 4 principios: • Encapsulamiento: cada objeto mantiene su estado privado, dentro de una clase. Otros objetos no tienen acceso directo a ese estado. Solo pueden llamar a una lista de funciones públicas, llamadas métodos. Por tanto, el objeto administra su propio estado a través de métodos, y ninguna otra clase puede tocarlo a menos que se permita explícitamente. Si desea comunicarse con el objeto, debe utilizar sus métodos. • Abstracción: el código suele ser muy largo, y los objetos separados se comunican mucho entre sí. Mantener una gran cantidad de código como esta durante años con cambios evolutivos es difícil. La abstracción viene a aliviar este problema, pues cada objeto solo debe exponer un mecanismo de alto nivel para usarlo. Este mecanismo debe ocultar los detalles de implementación interna. Sólo debe revelar operaciones relevantes para los otros objetos. • Herencia: principio que indica cómo reutilizar una lógica común para separar la utilidad de la clase. Esto significa que se crea una clase (secundaria) derivando de otra clase (principal), y de esta manera, formamos una jerarquía. • Polimorfismo: representa la capacidad de tomar más de una forma. Una operación puede mostrar comportamientos diferentes en diferentes instancias. Las instancias dependen del tipo de datos utilizados en la operación.
61. Principios de Diseño Orientado a Objetos Principio de responsabilidad única (SRP) - Una clase sólo debe tener una responsabilidad o una razón para cambiar • Básicamente, determina cómo debemos modular el código en la programación orientada a objetos. El SRP es una justificación ampliamente citada para la refactorización, porque SRP limitará el impacto del cambio que podría ocurrir cuando estamos tratando de refactorizar o agregar nueva característica. Cualquier cambio requerido de un sistema de código naturalmente necesitará cambios en el cuerpo del código en un número de puntos diferentes. Si el sistema está estructurado siguiendo el principio de "reunir aquellas cosas que cambian por las mismas razones", minimizará el número de módulos (clases) que necesitan cambiar. Esto le permite ocultar el cambio tanto como sea posible detrás de los límites de encapsulación, deteniendo así el cambio en cascada en el resto del sistema, y reduciendo lo que necesita volver a probarse porque podría estar dañado.
62. Principios de Diseño Orientado a Objetos No te repitas (DRY) - Cada elemento de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema • Se deben evitar al máximo, mediante una disciplina efectiva, las siguientes situaciones: • Duplicación impuesta: Los desarrolladores sienten que no tienen otra opción: el entorno parece requerir duplicación. • Duplicación involuntaria: Los desarrolladores no se dan cuenta de que están duplicando información. • Duplicación impaciente: Los desarrolladores se vuelven perezosos y duplicados porque parece más fácil. • Duplicación de interdesarrolladores: Varias personas en un equipo (o en diferentes equipos) duplican una información.
63. Principios de Diseño Orientado a Objetos Principio de sustitución de Liskov Sea ϕ(x) una propiedad comprobable acerca de los objetos x de tipo T. Entonces ϕ(y) debe ser verdad para los objetos y del tipo S donde S, es un subtipo de T. Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas: “Si S es un subtipo de T, entonces los objetos de tipo T de un programa pueden ser sustituidos por objetos de tipo S sin alterar ninguna de sus propiedades deseables.” es una definición particular de una relación de subtipificación, llamada tipificación (fuerte) del comportamiento que se refiere más a una relación semántica que a una relación sintáctica, ya que sólo tiene la intención de garantizar la interoperabilidad semántica de tipos en una jerarquía, los tipos de objeto en particular.
64. Principios de Diseño Orientado a Objetos Ley de Demeter o Principio del Menor Conocimiento Es un caso específico de “loose coupling” que puede ser sustancialmente resumida como: • Cada unidad debe tener un limitado conocimiento sobre otras unidades y solo conocer aquellas unidades estrechamente relacionadas a la unidad actual. • Cada unidad debe hablar solo a sus amigos y no hablar con extraños. • Solo hablar con sus amigos inmediatos. En otras palabras, dado un objeto, este debería asumir tan poco como sea posible sobre la estructura o propiedades de cualquier otro (incluyendo sus subcomponentes).
65. Patrones de Diseño • Un patrón de diseño es la forma reutilizable de una solución a un problema de diseño. La idea fue introducida por el arquitecto Christopher Alexander y ha sido adaptada para varias otras disciplinas, en particular la ingeniería de software. • Una colección organizada de patrones de diseño que se relacionan con un campo determinado se denomina lenguaje de patrón. Este lenguaje da una terminología común para discutir las situaciones a las que se enfrentan los diseñadores. • Un patrón arquitectónico es una solución general y reutilizable a un problema que ocurre comúnmente en la arquitectura de software dentro de un contexto determinado. Los patrones arquitectónicos abordan diversos problemas en la ingeniería de software, como las limitaciones de rendimiento del hardware informático, la alta disponibilidad y la minimización de un riesgo empresarial. Algunos patrones arquitectónicos se han implementado dentro de marcos de software.
66. Tipos de Patrones de Diseño En arquitectura de sistemas existen tres tipos principales de patrones de diseño: 1. De creación: son los que crean objetos, en lugar de tener que crear instancias directamente de objetos. Esto le da al programa más flexibilidad a la hora de decidir qué objetos deben crearse para un caso determinado. 2. De estructura: Estos se refieren a la composición de clases y objetos. Utilizan la herencia para componer interfaces y definir formas de componer objetos para obtener nueva funcionalidad. 3. De comportamiento: La mayoría de estos patrones de diseño se refieren específicamente a la comunicación entre objetos.
67. Patrones de creación • Fábrica abstracta: agrupa objetos que tienen un tema común. • Constructor: construye objetos complejos separando la construcción y la representación. • Método Fábrica: crea objetos sin especificar la clase exacta que se creará. • Prototipo: crea objetos clonando un objeto existente. • Singleton: restringe la creación de objetos para una clase a una sola instancia.
68. Patrones de estructura • Adaptador: permite que las clases con interfaces incompatibles trabajen juntas ajustando su propia interfaz alrededor de la de una clase ya existente. • Puente: desacopla una abstracción de su implementación para que las dos puedan variar de forma independiente. • Compuesto: compone cero o más objetos similares para que se puedan manipular como uno. • Decorador: agrega o reemplaza dinámicamente el comportamiento en un método existente de un objeto. • Fachada: proporciona una interfaz simplificada a un gran cuerpo de código. • Flyweight: reduce el costo de crear y manipular un gran número de objetos similares. • Proxy: proporciona un marcador de posición para otro objeto para controlar el acceso, reducir el costo y reducir la complejidad.
69. Patrones de comportamiento • Cadena de responsabilidad: delega comandos a una cadena de objetos de procesamiento. • Comando: crea objetos que encapsulan acciones y parámetros. • Intérprete: implementa un lenguaje especializado. • Iterador: tiene acceso a los elementos de un objeto secuencialmente sin exponer su representación subyacente. • Mediador: permite el acoplamiento flexible entre clases por ser la única clase que tiene un conocimiento detallado de sus métodos. • Recuerdo: proporciona la capacidad de restaurar un objeto a su estado anterior (deshacer). • Observador: es un patrón de publicación/suscripción que permite que varios objetos de observador vean un evento.
70. Patrones de comportamiento • Estado: permite que un objeto modifique su comportamiento cuando cambia su estado interno. • Estrategia: permite seleccionar uno de una familia de algoritmos sobre la marcha en tiempo de ejecución. • Método Plantilla: define el esqueleto de un algoritmo como una clase abstracta, lo que permite que sus subclases proporcionen un comportamiento concreto. • Visitante: separa un algoritmo de una estructura de objetos moviendo la jerarquía de métodos en un objeto.
71. Modelo-vista-controlador • Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de su representación y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. • Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.
72. Modelo-vista-controlador Algunos aspectos del patrón MVC han evolucionado dando lugar a ciertas variantes del concepto original, ya que «las partes del MVC clásico realmente no tienen sentido para los clientes actuales. • HMVC (MVC Jerárquico) • MVA (Modelo-Vista-Adaptador) • MVP (Modelo-Vista-Presentador) • MVVM (Modelo-Vista Vista-Modelo) • ... y otros que han adaptado MVC a diferentes contextos. El patrón MVC fue una de las primeras ideas en el campo de las interfaces gráficas de usuario y uno de los primeros trabajos en describir e implementar aplicaciones software en términos de sus diferentes funciones.
73. Modelo-vista-controlador Los componentes de MVC se podrían definir como sigue: • El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al 'modelo' a través del 'controlador'. • El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta el 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo’ (ej. Middleware). • La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario), por tanto requiere de dicho 'modelo' la información que debe representar como salida.
74. Modelo-vista-controlador Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control que se sigue generalmente es el siguiente: 1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.) 2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. 3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
75. Modelo-vista-controlador 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. Este uso del patrón Observador no es posible en las aplicaciones Web puesto que las clases de la vista están desconectadas del modelo y del controlador. En general el controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. 5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente...
76. Lenguaje específico de dominio • Un lenguaje específico de dominio (en inglés domain-specific language, DSL) es un lenguaje de programación o de especificación dedicado a resolver un problema en particular, representar un problema específico y proveer una técnica para solucionar una situación en particular. • Ejemplos de lenguajes específicos del dominio incluyen: Logo para niños, R y S para estadísticas, Mata para programación matricial, Mathematica para matemáticas, fórmulas de hojas de cálculo y macros, SQL para consultas a bases de datos relacionales, expresiones regulares para crear análisis léxico, Generic Eclipse Modeling System para crear lenguajes con el objetivo de diagramar, y Csound, un lenguaje para síntesis digital. • Lo opuesto sería: • un lenguaje de programación de propósito general, como por ejemplo C o Java. • o un lenguaje de modelaje de propósito general como UML.
77. Análisis lexicográfico • Un analizador léxico o analizador lexicográfico es la primera fase de un compilador, consistente en un programa que recibe como entrada el código fuente de otro programa y produce una salida compuesta de tokens o símbolos. • Las técnicas utilizadas para construir analizadores léxicos también se pueden aplicar a otras áreas, como, por ejemplo, a lenguajes de consulta y sistemas de recuperación de información.
78. Análisis lexicográfico • En la programación dirigida por patrones es de mucha utilidad, pues en ella se introduce un lenguaje de patrónacción, llamado LEX, para especificar los analizadores léxicos. • En este lenguaje, los patrones se especifican por medio de expresiones regulares, y un compilador de LEX puede generar un reconocedor de las expresiones regulares mediante una autómata finito eficiente.
79. Tarjetas CRC • Las tarjetas CRC (Clase-Responsabilidad-Colaboración) son una herramienta de brainstorming usada como metodología para el diseño de software orientado a objetos. • La técnica consiste en dibujar una tarjeta por cada clase u objeto, y dividirla en tres zonas: • En la parte superior, el nombre de la clase. • Debajo, en la parte izquierda, las responsabilidades de dicha clase. Son sus objetivos, a alto nivel. • A la derecha, los colaboradores, que son otras clases que ayudan a conseguir cumplir a ésta con sus responsabilidades.
80. Tarjetas CRC • Es una técnica para la representación de sistemas OO, para pensar en objetos. • Son un puente de comunicación entre diferentes participantes. • Principales desventajas: lentitud y roces. • Se recomienda un grupo de trabajo con representantes de las distintas partes. • Tamaño recomendable de cinco a seis personas: variedad de estilos y no demasiadas divagaciones.
81. Tarjetas CRC • Recomendación de equipo: 1 o 2 usuarios, 2 analistas, 1 diseñador y 1 moderador. • Permite ver las clases como algo más que repositorio de datos, y conocer el comportamiento de cada una a alto nivel. • La lluvia de ideas es una buena práctica para sugerir cómo rellenar las tarjetas CRC: • Todas las ideas son buenas, no censura. • Pensar rápido, la meditación después. • Cada miembro debe tener un turno, sin presiones. • Aligerar la situación, pausas para los roces.
82. Escenarios • Un escenario es una escena que ilustra alguna interacción con un sistema propuesto. • Un escenario es una herramienta utilizada durante el análisis de necesidades para describir un uso específico de un sistema propuesto. Los escenarios capturan el sistema, visto desde el exterior, por ejemplo, por un usuario, utilizando ejemplos específicos. • Algunos autores restringen la palabra "escenario" para hacer referencia a la interacción total de un usuario con el sistema. • Otros autores usan la palabra "escenario" para hacer referencia a partes de la interacción. • En este curso, el término se utiliza con ambos significados.
83. Escenarios • Algunas organizaciones tienen estándares de documentación complejos para describir un escenario. • Como mínimo, la descripción debe incluir: • Una declaración del propósito del escenario • El usuario o transacción individual que se está siguiendo a través del escenario • Suposiciones sobre equipos o software • Los pasos del escenario
84. Escenarios • El desarrollo de un escenario con un cliente aclara muchos requisitos funcionales que deben acordarse antes de que se pueda construir un sistema, por ejemplo, políticas, procedimientos, etc. • El escenario a menudo aclarará los requisitos para la interfaz de usuario, pero el diseño de la interfaz de usuario no debe formar parte del escenario. • Los escenarios son muy útiles para analizar requisitos especiales.
85. Modelos y casos de uso • Los escenarios son útiles para discutir un sistema propuesto con un cliente, pero los requisitos deben ser más precisos antes de que un sistema se entienda completamente. • Este es el propósito del modelado de requisitos. • Un caso de uso proporciona un modelo de este tipo. • Un caso de uso es una tarea que un actor debe realizar como beneficiario del sistema. • Un actor es un usuario de un sistema en un rol determinado. • Un actor puede ser humano o un sistema externo.
86. Caso de uso Algunas organizaciones tienen estándares de documentación complejos para describir un caso de uso. Como mínimo, la descripción debe incluir: • El nombre del caso de uso, que debe resumir su propósito • El actor o actores • El flujo de eventos • Suposiciones sobre las condiciones de entrada
87. Escenario y casos de uso en acción Los escenarios y los casos de uso deben de ser intuitivos, es decir, que ayuden a que resulte fácil discutir con los clientes. Los escenarios son una herramienta para el análisis de requisitos. • Son útiles para validar casos de uso y para comprobar el diseño de un sistema. • Se pueden utilizar como casos de prueba para las pruebas de aceptación.
88. Escenario y casos de uso en acción Los casos de uso son una herramienta para llevar a cabo el modelado de requisitos. • Un conjunto de casos de uso puede proporcionar un marco para la especificación de requisitos. • Los casos de uso son la base para el diseño del sistema y del programa, pero a menudo son difíciles de traducir en modelos de clase.
89. Diagrama casos de uso Un diagrama de casos de uso muestra las relaciones entre los actores y sus interacciones con un sistema. No muestra la lógica de esas interacciones.
90. Lenguaje unificado de modelado (UML) Una imagen vale más que mil palabras. Es por eso que se creó la generación de diagramas con el Lenguaje Unificado de Modelado (UML): para forjar un lenguaje visual común en el complejo mundo del desarrollo de software que también fuera comprensible por los usuarios de negocios y quienquiera que desee entender un sistema. Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema y los objetos que contiene.
91. Lenguaje unificado de modelado (UML) Hay cuatro categorías de modelos para la resolución de problemas: 1. Lenguajes imperativos, 2. Lenguajes funcionales, 3. Lenguajes declarativos y 4. Lenguajes orientados a objetos. En los lenguajes orientados a objetos, los algoritmos se expresan definiendo 'objetos' y haciendo que los objetos interactúen entre sí. Esos objetos son cosas que deben ser manipuladas y existen en el mundo real. Pueden ser edificios, artefactos sobre un escritorio o seres humanos.
92. Lenguaje unificado de modelado (UML) Los lenguajes orientados a objetos dominan el mundo de la programación porque modelan los objetos del mundo real. UML es una combinación de varias notaciones orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos. UML usa las fortalezas de estos tres enfoques para presentar una metodología más uniforme que sea más sencilla de usar. UML representa buenas prácticas para la construcción y documentación de diferentes aspectos del modelado de sistemas de software y de negocios.
93. Lenguaje unificado de modelado (UML) El OMG define los propósitos de UML de la siguiente manera: • Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software las herramientas para el análisis, el diseño y la implementación de sistemas basados en software, así como para el modelado de procesos de negocios y similares. • Hacer progresar el estado de la industria permitiendo la interoperabilidad de herramientas de modelado visual de objetos. No obstante, para habilitar un intercambio significativo de información de modelos entre herramientas, se requiere de un acuerdo con respecto a la semántica y notación.
94. UML cumple los siguientes requerimientos: • Establecer una definición formal de un metamodelo común basado en el estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del UML. La sintaxis abstracta define el conjunto de conceptos de modelado UML, sus atributos y sus relaciones, así como las reglas de combinación de estos conceptos para construir modelos UML parciales o completos. • Brindar una explicación detallada de la semántica de cada concepto de modelado UML. La semántica define, de manera independiente a la tecnología, cómo los conceptos UML se habrán de desarrollar por las computadoras.
95. UML cumple los siguientes requerimientos: • Especificar los elementos de notación de lectura humana para representar los conceptos individuales de modelado UML, así como las reglas para combinarlos en una variedad de diferentes tipos de diagramas que corresponden a diferentes aspectos de los sistemas modelados. • Definir formas que permitan hacer que las herramientas UML cumplan con esta especificación. Esto se apoya (en una especificación independiente) con una especificación basada en XML de formatos de intercambio de modelos correspondientes (XMI) que deben ser concretados por herramientas compatibles.
96. Actualizaciones en UML 2.0 UML se perfecciona continuamente. UML 2.0 extiende las especificaciones de UML para cubrir más aspectos de desarrollo, incluido Agile. La meta era reestructurar y perfeccionar UML de forma que la facilidad de uso, la implementación y la adaptación se simplificaran. Estas son algunas de las actualizaciones de los diagramas UML: • Mayor integración entre modelos estructurales y de comportamiento. • Capacidad de definir jerarquía y desglosar un sistema de software en componentes y subcomponentes. • UML 2.0 eleva el número de diagramas de 9 a 13.
97. Modelado con UML El desarrollo de sistemas se centra en tres modelos generales de sistemas diferentes: • Funcionales: Se trata de diagramas de casos de uso que describen la funcionalidad del sistema desde el punto de vista del usuario. • De objetos: Se trata de diagramas de clases que describen la estructura del sistema en términos de objetos, atributos, asociaciones y operaciones. • Dinámicos: Los diagramas de interacción, los diagramas de máquina de estados y los diagramas de actividades se usan para describir el comportamiento interno del sistema. Estos modelos de sistemas se visualizan a través de dos tipos diferentes de diagramas: estructurales y de comportamiento.
98. Diagramas UML estructurales • Diagrama de clases: El diagrama UML más comúnmente usado, y la base principal de toda solución orientada a objetos. Las clases dentro de un sistema, atributos y operaciones, y la relación entre cada clase. Las clases se agrupan para crear diagramas de clases al crear diagramas de sistemas grandes. • Diagrama de componentes: Muestra la relación estructural de los elementos del sistema de software, muy frecuentemente empleados al trabajar con sistemas complejos con componentes múltiples. Los componentes se comunican por medio de interfaces. • Diagrama de estructura compuesta: Los diagramas de estructura compuesta se usan para mostrar la estructura interna de una clase. • Diagrama de implementación: Ilustra el hardware del sistema y su software. Útil cuando se implementa una solución de software en múltiples máquinas con configuraciones únicas.
99. Diagramas UML estructurales • Diagrama de objetos: Muestra la relación entre objetos por medio de ejemplos del mundo real e ilustra cómo se verá un sistema en un momento dado. Dado que los datos están disponibles dentro de los objetos, estos pueden usarse para clarificar relaciones entre objetos. • Diagrama de paquetes: Hay dos tipos especiales de dependencias que se definen entre paquetes: la importación de paquetes y la fusión de paquetes. Los paquetes pueden representar los diferentes niveles de un sistema para revelar la arquitectura. Se pueden marcar las dependencias de paquetes para mostrar el mecanismo de comunicación entre niveles.
100. Diagramas UML de comportamiento • Diagramas de actividades: Flujos de trabajo de negocios u operativos representados gráficamente para mostrar la actividad de alguna parte o componente del sistema. Los diagramas de actividades se usan como una alternativa a los diagramas de máquina de estados. • Diagrama de comunicación: Similar a los diagramas de secuencia, pero el enfoque está en los mensajes que se pasan entre objetos. La misma información se puede representar usando un diagrama de secuencia y objetos diferentes. • Diagrama de panorama de interacciones: Hay siete tipos de diagramas de interacciones. Este diagrama muestra la secuencia en la cual actúan.
101. Diagramas UML de comportamiento • Diagrama de secuencia: Muestra cómo los objetos interactúan entre sí y el orden de la ocurrencia. Representan interacciones para un escenario concreto. • Diagrama de máquina de estados: Similar a los diagramas de actividades, describen el comportamiento de objetos que se comportan de diversas formas en su estado actual. • Diagrama de temporización: Al igual que en los diagramas de secuencia, se representa el comportamiento de los objetos en un período de tiempo dado. Si hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las interacciones de los objetos se muestran durante ese período de tiempo particular. • Diagrama de caso de uso: Representa una funcionalidad particular de un sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus controladores (actores) internos/externos.
102. Diagramas de clases Los diagramas de clases representan las estructuras estáticas de un sistema, incluidas sus clases, atributos, operaciones y objetos. Un diagrama de clases puede mostrar datos computacionales u organizacionales en la forma de clases de implementación y clases lógicas, respectivamente. Puede haber superposición entre estos dos grupos. Las clases se representan con una forma rectangular dividida en tercios. La sección superior muestra el nombre de la clase, mientras que la sección central contiene los atributos de la clase. La sección inferior muestra las operaciones de la clase (también conocidas como métodos).
103. Diagramas de clases
104. Diagramas de componentes Los diagramas de componentes muestran cómo se combinan los componentes para formar componentes más grandes o sistemas de software. Estos diagramas están diseñados para modelar las dependencias de cada componente en el sistema. Un componente es algo necesario para ejecutar una función de estereotipo. Un estereotipo de componente puede constar de ejecutables, documentos, tablas de bases de datos, archivos o archivos de bibliotecas. Se representa un componente con una forma rectangular. Debe tener dos rectángulos pequeños en un lado o mostrar un icono con esa forma.
105. Diagramas de componentes
106. Diagramas de implementación Un diagrama de implementación modela la implementación física y la estructura de los componentes de hardware. Los diagramas de implementación muestran dónde y cómo operarán los componentes de un sistema en conjunto con los demás. • Al trazar un diagrama de implementación, se usa la misma notación que se usa para un diagrama de componentes. • Se usa un cubo 3D para modelar un nodo (lo cual representa una máquina física o máquina virtual). • Se etiqueta el nodo con el mismo estilo que se usa para los diagramas de secuencia. Se agregan otros nodos según sea necesario, luego se conectan con líneas.
107. Diagramas de implementación
108. Diagramas de actividades Los diagramas de actividades muestran el flujo de control de procedimiento entre objetos de clases, junto con procesos organizacionales, como los flujos de trabajo de negocios. Estos diagramas se integran con formas especializadas que luego se conectan con flechas. La notación establecida para los diagramas de actividades es similar a la de los diagramas de estados. • Empieza con un círculo negro. • Se conecta el círculo a la primera actividad, que se modela con un rectángulo redondeado. • Se conecta cada actividad a otras actividades con líneas que muestren el flujo paso a paso de todo el proceso.
109. Diagramas de caso de uso Un caso de uso es una lista de pasos que definen la interacción entre un actor (un humano que interactúa con el sistema o un sistema externo) y el sistema propiamente dicho. Los diagramas de casos de uso representan las especificaciones de un caso de uso y modelan las unidades funcionales de un sistema. Estos diagramas ayudan a los equipos de desarrollo a comprender los requisitos de su sistema, incluida la función de la interacción humana en el mismo y las diferencias entre diversos casos de uso. Un diagrama de caso de uso podría mostrar todos los casos de uso del sistema o solo un grupo de casos de uso con una funcionalidad similar. 1. Para iniciar un diagrama de casos de uso, agrega una forma ovalada en el centro del dibujo. 2. Escribe el nombre del caso de uso dentro del óvalo. 3. Representa a los actores con una figura humana cerca del diagrama, luego usa líneas para modelar las relaciones entre los actores y los casos de uso.
110. Diagramas de caso de uso
111. Diagramas de secuencia Los diagramas de secuencia, también conocidos como diagramas de eventos o escenarios de eventos, ilustran cómo los procesos interactúan entre sí mostrando llamadas entre diferentes objetos en una secuencia. Estos diagramas tienen dos dimensiones: vertical y horizontal. Las líneas verticales muestran la secuencia de mensajes y llamadas en orden cronológico y los elementos horizontales muestran instancias de objetos en las que se transmiten los mensajes. 1. Para crear un diagrama de secuencia, escribe el nombre de la instancia de clase y el nombre de la clase en un cuadro rectangular. 2. Dibuja líneas entre las instancias de clases para representar al emisor y receptor de los mensajes. 3. Usa puntas de flecha oscuras para simbolizar mensajes sincrónicos, puntas de flecha abiertas para mensajes asincrónicos y líneas discontinuas para mensajes de respuesta.
112. Diagramas de secuencia
113. Diagramas de agregación Una de las fuentes más frecuentes de confusión en la UML es la agregación y la composición. Es fácil de explicar con delicadeza: la agregación es la parte de la relación. Es como decir que un coche tiene un motor y ruedas como piezas. Esto suena bien, pero lo difícil es considerar cuál es la diferencia entre la agregación y la asociación. En los días anteriores a UML, las personas eran generalmente bastante vagas en lo que era la agregación y lo que era asociación. Ya fueran vagos o no, siempre eran incompatibles con todos los demás. Como resultado, muchos modeladores piensan que la agregación es importante, aunque por diferentes razones. Así que la UML incluyó la agregación pero casi sin semántica. Como dice Jim Rumbaugh, "Piensa en ello como un placebo de modelado" [Rumbaugh, UML Reference].
114. Diagramas de agregación
115. Herramientas UML Algunos ejemplos de herramientas UML son los siguientes: ArgoUML, StarUML, BOUML, EclipseUML, Dia, GenMyModel, UML Modeller, Papyrus, Nclass, UMLet, NetBeans IDE, Platuml, Open ModelSphere, gModeler, RISE, Violet, Oracle Jdeveloper, Oracle SQL Developer (todas estas Open Source y gratuitas). yEd, Visio, Modeio, MagicDraw, Sparx Enterprise Architect, Creately, IBM Rational Rose, Visual Paradigm, Micro Focus Together, Gliffy, Trace Modeler, yUML, Altova Umodel Astah Poseidon, IBM Rational, Pacestar UML, PragmaDev, etc.
116. Modelo Entidad-Relación (ER) Describe cosas interrelacionadas de interés en un dominio específico del conocimiento. Un modelo básico de ER se compone de tipos de entidad (que clasifican las cosas de interés) y especifica las relaciones que pueden existir entre entidades (instancias de esos tipos de entidad). En ingeniería de software, un modelo de ER se forma comúnmente para representar cosas que un negocio necesita recordar para realizar procesos de negocio. Por consiguiente, el modelo de ER se convierte en un modelo de datos abstracto, que define una estructura de datos o información que se puede implementar en una base de datos, normalmente una base de datos relacional.
117. Modelo Entidad-Relación (ER)
118. Modelo Entidad-Relación (ER) Un modelo E-R suele ser el resultado de un análisis sistemático para definir y describir lo que es importante para los procesos en un área de un negocio. No define los procesos empresariales; sólo presenta un esquema de datos empresariales en forma gráfica. Normalmente se dibuja en forma gráfica como cuadros (entidades) que están conectados por líneas (relaciones) que expresan las asociaciones y dependencias entre entidades. Las entidades pueden caracterizarse no sólo por las relaciones, sino también por propiedades adicionales (atributos), que incluyen identificadores denominados "claves principales". Los diagramas creados para representar atributos, así como entidades y relaciones, se pueden denominar diagramas de relación de atributo de entidad, en lugar de modelos de relación entidad.
119. Modelo Entidad-Relación (ER) Un modelo de ER se implementa normalmente como una base de datos. En una implementación de base de datos relacional simple, cada fila de una tabla representa una instancia de un tipo de entidad y cada campo de una tabla representa un tipo de atributo. En una base de datos relacional, una relación entre entidades se implementa almacenando la clave principal de una entidad como un puntero o "clave externa" en la tabla de otra entidad. Existe una tradición para que los modelos de ER/datos se construyan en dos o tres niveles de abstracción. Tenga en cuenta que la jerarquía conceptual-lógica-física siguiente se utiliza en otros tipos de especificación y es diferente del enfoque de tres esquemas para la ingeniería de software.
120. Modelo conceptual de datos Este es el modelo de ER de nivel más alto en que contiene el detalle menos granular, pero establece el alcance general de lo que se debe incluir dentro del conjunto de modelos. El modelo de ER conceptual normalmente define entidades de datos de referencia maestras que suelen utilizar la organización. El desarrollo de un modelo de ER conceptual para toda la empresa es útil para admitir la documentación de la arquitectura de datos para una organización. Un modelo de ER conceptual se puede utilizar como base para uno o más modelos de datos lógicos (que definiremos más adelante). El propósito del modelo de ER conceptual es establecer la uniformidad de metadatos estructurales para las entidades de datos maestros entre el conjunto de modelos lógicos de ER. El modelo de datos conceptuales se puede utilizar para formar relaciones comunes entre modelos de ER como base para la integración del modelo de datos.
121. Modelo lógico de datos Un modelo lógico de ER no requiere un modelo de ER conceptual, especialmente si el ámbito del modelo lógico de ER incluye solo el desarrollo de un sistema de información distinto. El modelo lógico de ER contiene más detalles que el modelo de ER conceptual. Además de las entidades de datos maestros, ahora se definen las entidades de datos operacionales y transaccionales. Se desarrollan los detalles de cada entidad de datos y se establecen las relaciones entre estas entidades de datos. Sin embargo, el modelo lógico de ER se desarrolla independientemente del sistema de gestión de bases de datos específico en el que se puede implementar.
122. Modelo físico de datos Se pueden desarrollar uno o más modelos físicos de ER a partir de cada modelo lógico de ER. El modelo de ER físico se desarrolla normalmente para crear instancias como una base de datos. Por lo tanto, cada modelo de ER físico debe contener suficientes detalles para producir una base de datos y cada modelo de ER físico depende de la tecnología, ya que cada sistema de administración de bases de datos es algo diferente. Normalmente, el modelo físico se crea una instancia en los metadatos estructurales de un sistema de administración de bases de datos como objetos de base de datos relacionales, como tablas de base de datos, índices de base de datos como índices de clave únicos y restricciones de base de datos, como una restricción de clave externa o una restricción de compatibilidad. El modelo de ER también se utiliza normalmente para diseñar modificaciones en los objetos de base de datos relacional y para mantener los metadatos estructurales de la base de datos.
123. Modelo Entidad-Relación (ER) La primera etapa del diseño del sistema de información utiliza estos modelos durante el análisis de requisitos para describir las necesidades de información o el tipo de información que se va a almacenar en una base de datos. La técnica de modelado de datos se puede utilizar para describir cualquier ontología (es decir, una visión general y clasificaciones de términos usados y sus relaciones) para un área determinada de interés. En el caso del diseño de un sistema de información basado en una base de datos, el modelo de datos conceptual es, en una etapa posterior (normalmente denominado diseño lógico), asignado a un modelo de datos lógico, como el modelo relacional; esto a su vez se asigna a un modelo físico durante el diseño físico. Tenga en cuenta que, a veces, ambas fases se conocen como "diseño físico".
124. Máquinas de estados Una máquina de estados es una abstracción matemática utilizada para diseñar algoritmos. En términos simples, una máquina de estados leerá una serie de entradas. Cuando lee una entrada cambiará a un estado diferente. Cada estado especifica qué estado cambiar para una entrada determinada.
125. Diagramas de Flujo El diagrama de flujo o flujograma o diagrama de actividades es la representación gráfica de un algoritmo o proceso. Se utiliza en disciplinas como programación, economía, procesos industriales y psicología cognitiva. En Lenguaje Unificado de Modelado (UML), es un diagrama de actividades que representa los flujos de trabajo paso a paso. Un diagrama de actividades muestra el flujo de control general. En SysML el diagrama ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (p. ej., gasolina) o energía (p. ej., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos. Estos diagramas utilizan símbolos con significados definidos que representan los pasos del algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio y de fin del proceso.
126. Diagramas de Flujo
127. Diagramas de Flujo Las siguientes son acciones previas a la realización del diagrama de flujo: • Definir qué se espera obtener del diagrama de flujo. • Identificar quién lo empleará y cómo. • Establecer el nivel de detalle requerido. • Determinar los límites del proceso a describir. Los pasos a seguir para construir el diagrama de flujo son: 1. Fijar el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente. 2. Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso y su orden cronológico. 3. Si el nivel de detalle definido incluye actividades menores, listarlas también. 4. Identificar y listar los puntos de decisión. 5. Construir el diagrama respetando la secuencia cronológica y asignando los símbolos.
128. Tipos de Diagramas de Flujo Formato vertical: el flujo o la secuencia de las operaciones va de arriba hacia abajo. Es una lista ordenada de las operaciones de un proceso con toda la información necesaria, según su propósito. Formato horizontal: el flujo o la secuencia de las operaciones va de izquierda a derecha. Formato panorámico: el proceso entero está representado en una sola hoja y puede apreciarse de una sola mirada mucho más rápido que leyendo el texto, lo que facilita su comprensión, aún para personas no familiarizadas. Registra, no solo en línea vertical, sino también horizontal, distintas acciones simultáneas y la participación de más de un puesto o departamento que el formato vertical no registra. Formato arquitectónico: describe el itinerario de ruta de una forma o persona sobre el plano arquitectónico del área de trabajo. Diagrama de bloques de modelo matemático: es utilizado para representar sistemas físicos (reales). Cada uno de los bloques que componen el sistema físico es generalmente una simplificación de la realidad, lo que permite un tratamiento matemático razonable. Diagrama de bloques de procesos de producción: es un diagrama utilizado para indicar la manera en la que se elabora un producto, especificando la materia prima, la cantidad de procesos que se llevan a cabo y la forma en la que se representa el producto terminado.
129. Diagramas de flujo de datos Un diagrama de flujo de datos (DFD) asigna el flujo de información para cualquier proceso o sistema. Utiliza símbolos definidos como rectángulos, círculos y flechas, además de etiquetas de texto cortas, para mostrar entradas de datos, salidas, puntos de almacenamiento y las rutas entre cada destino. Los diagramas de flujo de datos pueden abarcar desde gráficos de procesos simples, incluso dibujados a mano, hasta DFD en profundidad de varios niveles que profundizan progresivamente en la forma en que se manejan los datos. Se pueden utilizar para analizar un sistema existente o modelar uno nuevo. Al igual que todos los mejores diagramas y gráficos, un DFD a menudo puede "decir" visualmente cosas que serían difíciles de explicar con palabras, y funcionan tanto para audiencias técnicas como no técnicas, desde desarrollador hasta CEO. Es por eso que los DFD siguen siendo tan populares después de todos estos años. Si bien funcionan bien para el software y los sistemas de flujo de datos, son menos aplicables hoy en día a la visualización de software o sistemas interactivos, en tiempo real o orientados a bases de datos.
130. Diagramas de flujo de datos
131. Diagramas de flujo de datos • Cada proceso debe tener al menos una entrada y una salida. • Cada almacén de datos debe tener al menos un flujo de datos entrante y un flujo de datos saliente. • Los datos almacenados en un sistema deben pasar por un proceso. • Todos los procesos van a otro proceso o a un almacén de datos. Flujo de datos Entidad externa Proceso Almacén de datos
132. Diagramas de flujo de datos • Entidad externa: un sistema externo que envía o recibe datos, comunicándose con el sistema que se está elaborando el diagrama. Son las fuentes y destinos de información que entran o salen del sistema. Pueden ser una organización o persona externa, un sistema informático o un sistema empresarial. También se conocen como terminadores, fuentes y sumideros o actores. Normalmente se dibujan en los bordes del diagrama. • Proceso: cualquier proceso que cambie los datos, produciendo una salida. Puede realizar cálculos u ordenar datos en función de la lógica o dirigir el flujo de datos en función de las reglas de negocio. Se utiliza una etiqueta corta para describir el proceso, como "Enviar pago."
133. Diagramas de flujo de datos • Almacén de datos: archivos o repositorios que contienen información para su uso posterior, como una tabla de base de datos o un formulario de pertenencia. Cada almacén de datos recibe una etiqueta simple, como "Pedidos". • Flujo de datos: la ruta que toma los datos entre las entidades externas, los procesos y los almacenes de datos. Representa la interfaz entre los otros componentes y se muestra con flechas, normalmente etiquetadas con un nombre de datos corto, como "Detalles de facturación".
134. Modelo arquitectónico Un modelo arquitectónico (en software) es un diagrama rico y riguroso, creado utilizando los estándares disponibles, en el que la preocupación principal es ilustrar un conjunto específico de compromisos inherentes a la estructura y el diseño de un sistema o ecosistema. Los arquitectos de software utilizan modelos arquitectónicos para comunicarse con otros y buscar comentarios entre pares. Un modelo arquitectónico es una expresión de un punto de vista en la arquitectura de software. Algunos elementos clave en el modelo arquitectónico de software son:
135. Modelo arquitectónico rico: debe haber suficiente información para describir el área en detalle. La información no debe faltar ni ser vaga. El objetivo es minimizar los malentendidos, no perpetuarlos. (Vease "preocupación principal”). riguroso: el arquitecto ha aplicado una metodología específica para crear este modelo en particular, y el modelo resultante tiene un “aspecto” particular. Prueba de rigor: Si dos arquitectos, en diferentes ciudades, estuvieran describiendo lo mismo, los diagramas resultantes serían casi idénticos (con la posible excepción del diseño visual).
136. Modelo arquitectónico diagrama: en general, un modelo puede referirse a cualquier abstracción que simplifique algo en aras de abordar un punto de vista particular. Esta definición subclases específicamente 'modelos arquitectónicos' al subconjunto de descripciones de modelos que se representan como diagramas. normas: las normas funcionan cuando todo el mundo los conoce y todos los utilizan. Esto permite un nivel de comunicación que no se puede lograr cuando cada diagrama es sustancialmente diferente de otro. UML es el estándar más citado.
137. Modelo arquitectónico preocupación principal: evite ser demasiado detallado mediante la inclusión de muchas necesidades diferentes en un solo diagrama. Es mejor dibujar varios diagramas, uno para cada punto de vista, que un solo 'mega diagrama' que sea tan complejo que requiera un curso de dos años para entenderlo. Recuerde : al construir casas, el arquitecto entrega diferentes diagramas. Cada uno se utiliza de manera diferente. Con frecuencia, el paquete final de planos incluirá diagramas con el plano de planta repetido: plan de encuadre, plan eléctrico, plan de calefacción, plomería, etc. El subcontratista de plomería no necesita los detalles que le importan al electricista, etc.
138. Modelo arquitectónico ilustrar: la idea detrás de la creación de un modelo es comunicarse y buscar comentarios valiosos. El objetivo del diagrama debe ser responder a una pregunta específica y compartir esa respuesta con otros para (a) ver si están de acuerdo, y (b) guiar su trabajo. Regla general: saber lo que quieres decir, y cuyo trabajo tienes la intención de influir en él. conjunto específico de compromisos: la metodología de análisis de compromisos de arquitectura (ATAM) describe un proceso mediante el que la arquitectura de software puede ser revisada por pares para su idoneidad.
139. Modelo arquitectónico ATAM hace esto comenzando con una noción básica: no existe tal cosa como un diseño "único-para-todo". Podemos crear un diseño genérico, pero luego tenemos que modificarlo a situaciones específicas basadas en los requisitos del negocio. En efecto, hacemos compensaciones. El diagrama debe hacer visibles esas compensaciones específicas. Por lo tanto, antes de que un arquitecto cree un diagrama, debe estar preparado para describir, en palabras, qué compensaciones están intentando ilustrar en este modelo.
140. Modelo arquitectónico compromisos inherentes a la estructura y el diseño: un componente no es una compromiso. Los compromisos rara vez se traducen en una imagen en el diagrama. Los compromisos son los primeros principios que produjeron los modelos de diseño. Cuando un arquitecto desea describir o defender un compromiso particular, el diagrama se puede utilizar para defenderlo. sistema o ecosistema: el modelado en general se puede hacer a diferentes niveles de abstracción. Es útil modelar la arquitectura de una aplicación específica, con componentes e interacciones. También es razonable modelar los sistemas de aplicaciones necesarios para entregar un proceso empresarial completo (como pedido a efectivo).
141. Leyes de Lehman (evolución del software) • En ingeniería de software, las Leyes de evolución del software, o simplemente leyes de Lehman se refieren a una serie de leyes empíricas que Lehman y Belady formularon, basados en trabajos que comenzaron en 1974, con respecto a la evolución del software. • Las leyes describen el balance entre las fuerzas que impulsan nuevos desarrollos, y las fuerzas que ralentizan el proceso. • Las ocho leyes de la evolución del software son:
142. Leyes de Lehman (evolución del software) 1. Ley del cambio continuo: ØUn programa que se usa en un entorno real necesariamente debe cambiar o se volverá progresivamente menos útil y menos satisfactorio para el usuario.
143. Leyes de Lehman (evolución del software) 2. Ley de la complejidad creciente: ØA medida que un programa en evolución cambia, su estructura tiende a ser cada vez más compleja. Se deben dedicar recursos extras para preservar y simplificar su estructura.
144. Leyes de Lehman (evolución del software) 3. Ley de la autorregulación: ØLa evolución de los programas es un proceso autorregulado. Los atributos de los sistemas, tales como tamaño, tiempo entre entregas y la cantidad de errores documentados son aproximadamente invariantes para cada entrega del sistema.
145. Leyes de Lehman (evolución del software) 4. Ley de la estabilidad organizacional: ØDurante el tiempo de vida de un programa, su velocidad de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema.
146. Leyes de Lehman (evolución del software) 5. Ley de la conservación de la familiaridad: ØA medida que un sistema evoluciona también todo lo que está asociado a ello, como los desarrolladores, personal de ventas, y usuarios por ejemplo, deben mantener un conocimiento total de su contenido y su comportamiento para lograr una evolución satisfactoria. Un crecimiento exagerado disminuye esta capacidad. Por tanto este incremento promedio debe mantenerse.
147. Leyes de Lehman (evolución del software) 6. Ley del crecimiento continuo: ØLa funcionalidad ofrecida por los sistemas tiene que crecer continuamente para mantener la satisfacción de los usuarios.
148. Leyes de Lehman (evolución del software) 7. Ley del decremento de la calidad: ØLa calidad de los sistemas software comenzará a disminuir a menos que dichos sistemas se adapten a los cambios de su entorno de funcionamiento.
149. Leyes de Lehman (evolución del software) 8. Ley de la retroalimentación del sistema: ØLos procesos de evolución incorporan sistemas de retroalimentación multiagente y multiciclo y estos deben ser tratados como sistemas de retroalimentación para lograr una mejora significativa del producto.
150. Anti-patrones • Los anti-patrones, también llamados trampas, son ejemplos bien documentados de malas soluciones para problemas. Se estudian a fin de poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser reconocida fácilmente al investigar sistemas disfuncionales durante una auditoria. • El término anti-patrón se origina como una contra parte al término patrón, acuñado en arquitectura de software, para definir las buenas prácticas de programación, diseño o gestión de sistemas. De tal manera podríamos hablar de que un sistema “bien hecho” está lleno de patrones, y debería carecer de anti-patrones; al menos ese sería un sistema ideal.
151. Anti-patrones de Arquitectura de Sistemas • Reinventar la rueda.- Se refiere a reimplementar componentes que se pueden conseguir prefabricados de antemano, y hacer poco reuso en el código. En breves palabras: querer hacer todo uno mismo. Y hablaríamos de: 1. Poco nivel de reuso en el código, reuso de un proyecto a otro, con lo cual cada proyecto está comenzando desde cero. 2. Constantemente se reescriben fragmentos de código con la misma funcionalidad. 3. Con el consecuente gasto inútil de mano de obra y tiempo en reimplementar cosas, que ya estaban hechas. 4. El software se vuelve innecesariamente más denso. Lo anterior, por lo regular, a causa de poco conocimiento del trabajo ya existente por parte del arquitecto, lo que conlleva a buscar soluciones para problemas ya solucionados.
152. Anti-patrones de Arquitectura de Sistemas • Casarse con el diablo.- Crear una dependencia hacia un fabricante que nos provee de alguna solución (componentes). El problema es inminente: 1. Se depende completamente de lo que el vendedor haga. 2. La calidad de los productos del proveedor nos comprometen. 3. El vendedor nos tiene agarrados. Cito como ejemplo, el caso de una de las universidades más importantes del país, cuyo desarrollo casi completo del sistema de administración escolar, está realizado sobre PL/SQL en Oracle. Ellos necesitan seguir pagando las licencias de Oracle para mantenerse operando. Aún cuando los nuevos desarrollos los estén elaborando ya en otras plataformas Java y PhP, entre otras. Tienen cinco años de desarrollos en PL/SQL, que no los dejan dejar de pagar licencias. No es que Oracle sea malo. Sin embargo, puede ser caro en extremo para una universidad pública.
153. Anti-patrones de Arquitectura de Sistemas • Stovepipe.- Cocinado en “caliente”. Es la forma breve de referirse a la creación de islas automatizadas dentro de la misma empresa (cada departamento crea su propio subdepartamento de sistemas). “Islas” independientes, y en conflicto unas con otras. Cada isla desarrolla la parte del sistema que necesita para satisfacer sus requerimientos, sin preocuparse por el resto (no existe un plan o eje guía), el escenario resultante implica una pobre o nula interoperabilidad, obviamente, no existe el reuso y, consecuentemente se incrementan costos. Contrario a lo que se podría suponer, cada vez es más común este tipo de acciones, dada la premura de departamentos específicos dentro de una macroempresa, por contar con acceso a Tecnologías de Información.
154. Estrategias de refactorización Los desarrolladores pueden obtener algunas horas de refactorización de su código hacia el final del año, y así rediseñar secciones que se implementaron con prisa, escribir pruebas para secciones que no fueron probadas y redimir el tiempo perdido en apuros para cumplir las fechas. Las siguientes son algunas estrategias que se pueden adoptar durante este proceso, con el fin de hacerlo más productivo y eficaz: 1. Prueba TODO antes que nada, de lo contrario, sin hacer pruebas, mover el código podría romper fundamentalmente una aplicación sin saber por dónde surgió el nuevo defecto.
155. Estrategias de refactorización 2. Un método, un trabajo (también una clase, un trabajo), aplicando el principio de responsabilidad única, no solo en la abstracción de clases, sino en la abstracción de métodos. Los métodos que tienen más de un trabajo son menos reutilizables que los métodos que tienen un único rol. Es más difícil identificar errores cuando un método o una función tiene más de un rol. Las áreas comunes de mejora implican métodos que contienen código de manipulación de cadenas o código que valida los datos. Estos son los principales candidatos para la refactorización. Las operaciones matemáticas también son los principales candidatos para una operación de refactorización.
156. Estrategias de refactorización 3. No tener miedo a incorporar más objetos y clases, El principio de responsabilidad única significa que inevitablemente terminarás con más objetos y clases. ¡Esto está bien! De hecho, esto es preferible a tener una clase grande que contiene muchos comportamientos. Los objetos no son intrínsecamente malos. No destruyen el equipo ni hacen que la aplicación sea más lenta en el número utilizado por la mayoría de los desarrolladores. Si tiene una razón para que exista un objeto, créelo por todos los medios.
157. Estrategias de refactorización 4. Eliminar código muerto, no utilizado, innecesario o antiguo, la mayoría de las bases de código tienen código que no se utiliza, no es necesario o es antiguo. Este código se puede quitar y debe eliminarse periódicamente. Este es un buen momento para aprovechar y quitar este código. Lea el código detenidamente y ejecute el detector de código muerto sobre él para ver qué partes ya no se utilizan. Un candidato principal para la eliminación son variables que ya no se utilizan, pero que todavía se definen. No micro optimizar el código, pero darle un ojo crítico para mejorarlo y limpiarlo. También se puede ajustar la lógica de negocios y mejorar el flujo del código, pero proceder con precaución y asegúrese de que tiene cómo probar todo.
158. Estrategias de refactorización 5. Documenta tu código, ya que nadie tiene tiempo suficiente para escribir la documentación que desea, en línea o de otra manera. Aprovecha el tiempo de inactividad como una oportunidad para volver atrás, escribir docblocks y documentar el código que se escribió durante el año pasado. Aunque esto es a menudo un proceso tedioso, tiene sus beneficios, especialmente cuando te encuentras con una función que escribiste esta vez el próximo año, y no tienes idea de lo que hace (la documentación resuelve este problema). Considere la posibilidad de utilizar un formato estandarizado para los bloques de documentos. No sólo facilita la compilación en documentación legible más adelante, al tener un formato estándar que todo el mundo sigue, permite utilizar los documentos en el IDE u otras herramientas de codificación.
159. Computación orientada a servicios Antes de comenzar a explorar los detalles de la informática orientada a servicios, primero necesitamos establecer una terminología de diseño básica. Utilizaremos un vocabulario común con por los siguientes términos relacionados con el diseño: • Característica del diseño • Principio de diseño • Paradigma de diseño • Patrón de diseño • Estándar de diseño • Mejores prácticas
160. Característica del diseño Una característica de algo es simplemente un atributo o calidad. Una solución empresarial automatizada tendrá numerosas características únicas que se establecieron durante su diseño inicial. Por lo tanto, el tipo de característica de diseño que nos interesa es un atributo específico o la calidad de un cuerpo de lógica de solución que documentamos en una especificación de diseño y planeamos realizar en desarrollo. La orientación a servicios hace hincapié en la creación de características de diseño muy específicas, al tiempo que deshace otras. Es importante tener en cuenta que casi todas las características de diseño que exploramos son alcanzables a una determinada medida. Esto significa que generalmente no se trata de si la lógica de la solución tiene o no una característica determinada; casi siempre se trata de la medida en que una característica puede o debe realizarse.
161. Característica del diseño Aunque cada sistema puede tener sus propias características únicas, estamos principalmente interesados en establecer características comunes de diseño. El aumento de la uniformidad garantiza un mayor grado de coherencia, lo que hace que los diferentes tipos de lógica de la solución sean más parecidos. Cuando las cosas son más parecidas se vuelven más predecibles. En el mundo de la lógica distribuida y compartible, la previsibilidad es algo bueno. Las características de diseño predecibles conducen a un comportamiento predecible. Esto, a su vez, conduce a una mayor confiabilidad y la oportunidad de aprovechar la lógica de la solución de muchas maneras diferentes. Gran parte de la orientación a servicios se dedica a proporcionar un medio para establecer una colección específica de características de diseño que difundan la consistencia, previsibilidad y fiabilidad en muchos niveles y para diferentes propósitos.
162. Principio de diseño Un principio es una práctica industrial generalizada y aceptada. En otras palabras, es algo que otros están haciendo o promoviendo en asociación con un objetivo común. Puede comparar un principio con una práctica recomendada, en el sentido de que ambos proponen un medio para lograr algo basado en la experiencia pasada o la aceptación en toda la industria. Cuando se trata de crear soluciones, un principio de diseño representa una guía muy recomendada para dar forma a la lógica de la solución de cierta manera y con ciertos objetivos en mente. Estos objetivos se asocian generalmente con el establecimiento de una o más características de diseño específicas (como resultado de la aplicación del principio).
163. Principio de diseño Por ejemplo, podemos tener un principio tan fundamental como uno que establece que la lógica de la solución debe ser distribuible. La aplicación de este principio da como resultado que la lógica de la solución se particione en unidades distribuibles individualmente. Los ocho principios de diseño que veremos más adelante, proporcionan reglas y directrices que ayudan a determinar exactamente cómo se debe descomponer y dar forma a la lógica de la solución en unidades distribuibles. Un estudio de estos principios revela además qué características de diseño deben tener estas unidades para ser clasificadas como servicios de "calidad" capaces de cumplir la visión y los objetivos asociados con SOA y la informática orientada a servicios.
164. Paradigma de diseño Hay muchos significados asociados con el término "paradigma". Puede ser un enfoque de algo, una escuela de pensamiento con respecto a algo, o un conjunto combinado de reglas que se aplican dentro de un límite predefinido. Un paradigma de diseño en el contexto de la automatización empresarial se considera generalmente un enfoque de gobierno para diseñar la lógica de la solución. Normalmente consiste en un conjunto de reglas o principios complementarios que definen colectivamente el enfoque general representado por el paradigma. La orientación a objetos (o el diseño orientado a objetos) es un ejemplo clásico de un paradigma de diseño aceptado. Proporciona un conjunto de principios que dan forma a la lógica de la solución componente de ciertas maneras para cumplir un conjunto específico de objetivos.
165. Paradigma de diseño A lo largo de esas mismas líneas, la orientación a servicios representa su propio paradigma de diseño distinto. Al igual que la orientación a objetos, es un paradigma que se aplica a la lógica de la solución distribuida. Sin embargo, sus principios difieren de los asociados con la orientación a objetos, lo que da como resultado la creación de diferentes tipos de características de diseño. Nótese que el paradigma de diseño de orientación a servicios se documenta por separado en los Principios de orientación a servicios.
166. Patrón de diseño Hemos establecido que la orientación al servicio es un paradigma de diseño compuesto por un conjunto de principios de diseño, cada uno de los cuales proporciona una regla generalizada o directriz para realizar ciertas características de diseño. El paradigma en sí suena bastante completo, y en realidad lo es. Sin embargo, aplicarlo con éxito en el mundo real requiere algo más que una comprensión teórica de sus principios. Los diseñadores de servicios se enfrentarán regularmente a obstáculos y desafíos al intentar aplicar un paradigma de diseño en el mundo real. Esto se debe a que la realización de las características de diseño deseadas con frecuencia se complica por varios factores, incluyendo: • Restricciones impuestas por la tecnología que se utiliza para construir y/o hospedar las unidades de lógica de solución.
167. Patrón de diseño • Restricciones impuestas por la tecnología o los sistemas que residen junto a las unidades implementadas de la lógica de la solución. • Restricciones impuestas por los requisitos y prioridades del proyecto que entregan las unidades de lógica de solución Un patrón de diseño describe un problema común y proporciona una solución correspondiente. Básicamente documenta la solución en un formato de plantilla genérico para que se pueda aplicar repetidamente. El conocimiento de los patrones de diseño no sólo le arma con una comprensión de los posibles problemas a los que los diseños pueden ser sometidos, proporciona respuestas en cuanto a cómo se tratan mejor estos problemas.
168. Patrón de diseño Los patrones de diseño nacen de la experiencia. Los pioneros en cualquier campo tuvieron que someterse a ciclos de prueba y error y al aprender de lo que no funcionó, se desarrollaron enfoques que finalmente lograron sus objetivos. Cuando un problema y su solución correspondiente se identificaron como suficientemente comunes, se formó la base de un patrón de diseño. Los patrones de diseño se pueden combinar aún más en patrones compuestos que resuelven problemas más grandes y una serie de patrones pueden formar la base de un lenguaje de patrones, como se explica a continuación.
169. Estándar de diseño Para que una organización aplique con éxito un paradigma de diseño, requerirá algo más que una adhesión a los principios de diseño asociados y un conocimiento de los patrones de diseño de soporte. Cada organización tendrá objetivos estratégicos únicos y entornos empresariales únicos. Estos forman un conjunto distinto de requisitos y restricciones que deben adaptarse dentro de los diseños de la solución. Los estándares de diseño son convenciones de diseño (normalmente obligatorias) personalizadas para predeterminar constantemente las características de diseño de la solución en apoyo de los objetivos de la organización y optimizadas para entornos empresariales específicos. Es a través del uso de estándares de diseño internos que las organizaciones pueden ofrecer consistentemente soluciones adaptadas a sus entornos, recursos, objetivos y prioridades.
170. Estándar de diseño Al igual que con los principios de diseño, la aplicación de estándares de diseño da como resultado la creación de características de diseño específicas. Al igual que con los patrones de diseño, los estándares de diseño fomentan y refinan estas características para evitar problemas potenciales y fortalecer el diseño general de la solución. De hecho, se recomienda que las normas de diseño se basen o incluso se deriven de los principios y patrones de diseño de la industria.
171. ¿Se pueden tener estándares de diseño sin principios de diseño? Sí, en realidad es común tener muchos estándares de diseño. Sólo algunos pueden necesitar relacionarse con los principios para ver a través de la aplicación del paradigma de diseño general. También se pueden crear diferentes normas de diseño para apoyar simplemente otros objetivos o compensar las restricciones impuestas por factores específicos relacionados con el medio ambiente, la cultura o la tecnología. Aunque algunas normas pueden no tener una asociación directa con los principios de diseño aceptados, siempre debe haber un esfuerzo para mantener todas las normas en alineación relativa.
172. ¿Se pueden tener principios de diseño sin estándares de diseño? Por lo general, depende de lo comprometida que esté una organización con el paradigma de diseño que gobierna. Si ve potencial en el uso de sólo un subconjunto de los principios del paradigma, entonces algunos principios pueden no estar respaldados por los estándares de diseño correspondientes. Sin embargo, este enfoque no es común. Esencialmente, al igual que con los principios de diseño, a través de la estandarización queremos construir consistencia en características de diseño específicas – consistencia en la calidad de las características y en la frecuencia con que se implementan.
173. Estándares de diseño Algo que vale la pena mencionar al discutir estándares es la diferencia entre estándares de diseño y estándares industriales. Los primeros, como acabamos de describir, se refieren a los estándares internos o personalizados que se aplican al diseño de lógica de solución y sistemas para una empresa en particular. Los últimos generalmente representa estándares de tecnología abierta, como los que componen las plataformas de servicios XML y Web. A veces, las organizaciones asumen que si utilizan estándares de la industria terminarán con una empresa de TI estandarizada. Si bien las especificaciones de servicios XML y Web que se han ratificado y aceptado los estándares de la industria establecen un nivel de estandarización de la tecnología, todavía depende de una organización posicionar y aplicar estas tecnologías de manera coherente. Sin estándares de diseño, los estándares de la industria pueden fallar fácilmente en el logro de su potencial.
174. Mejores prácticas Una práctica recomendada (a veces mal llamada “mejor práctica”) generalmente se considera una técnica o enfoque para resolver o prevenir ciertos problemas. Por lo general, es una práctica que tiene reconocimiento en la industria y ha surgido de la experiencia pasada de la industria. Entonces, ¿cómo se diferencia una mejor práctica de un principio de diseño? Haremos una clara distinción en el sentido de que un principio de diseño se limita únicamente al diseño. Una práctica recomendada puede relacionarse con cualquier cosa, desde la entrega del proyecto hasta los problemas organizativos, la gobernanza o el proceso. Un principio de diseño podría considerarse una práctica recomendada asociada únicamente con el diseño de soluciones.
175. Diseño de aplicaciones en silo Un diseño en silo normalmente da como resultado una proporción de una aplicación para cada nuevo conjunto de requisitos de automatización empresarial. Ha sido un enfoque probado para lograr beneficios empresariales tangibles con un retorno de la inversión relativamente predecible. Sin embargo, da lugar a aplicaciones desechables. Los beneficios de crear aplicaciones independientes repetidamente incluyen: • Los requisitos específicos permiten una entrega de soluciones simplificada y predecible. • El análisis y el diseño se centran tácticamente y, por tanto, son claros y directos. • Los últimos avances tecnológicos se pueden aprovechar construyendo repetidamente nuevos sistemas desde cero.
176. Diseño de aplicaciones en silo Sin embargo, los problemas con la creación repetida de aplicaciones independientes incluyen: • Cantidades significativas de residuos y redundancia • La entrega de aplicaciones es realmente ineficiente • Entornos técnicos hinchados y sobredimensionados • Infraestructura compleja y arquitectura empresarial enrevesada • Integración compleja y costosa • Costos operativos de TI cada vez mayores Una empresa compuesta por soluciones distribuidas en silos.
177. Integración de aplicaciones empresariales También conocida por las siglas EAI (del inglés enterprise application integration) o EII (enterprise information integration, integración de la información de la empresa), se define como el uso de software y principios de arquitectura de sistemas para integrar un conjunto de aplicaciones en silos, dentro de cualquier empresa. Cuando dichos sistemas no pueden compartir su información efectivamente, se crean cuellos de botella que requieren de la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la información. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor, en lugar de enfocarse en la coordinación de labores operativas. Se trata de un proceso sumamente complejo y altamente costoso.
178. Integración de aplicaciones empresariales Uno de los retos que encaran las organizaciones modernas es darles a sus empleados información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de mover esta información entre las aplicaciones. La EAI, como disciplina, busca solventar muchos de esos problemas, así como crear nuevos paradigmas para, mejorar a las organizaciones tratando de trascender en el objetivo de conectar aplicaciones individuales, separadas en sus propios silos, para crear un mecanismo que incremente el conocimiento dentro de la organización, buscando ventajas competitivas futuras para la empresa.
179. Integración de aplicaciones empresariales EAI puede ser usado con diferentes fines: • Integración de datos (información): asegurando que la información en varios sistemas sea consistente. Esto también se conoce como EII (Enterprise Information Integration). • Integración de procesos: enlace de los procesos de negocios entre diferentes aplicaciones. • Independencia de proveedor: extrayendo las políticas o reglas del negocio de las aplicaciones e implementándolas en un sistema EAI, de forma que cualquiera de las aplicaciones usadas pueda ser cambiada sin que dichas reglas de negocio deban ser reimplementadas. • Fachada común: Un sistema EAI puede actuar como el front-end de un cúmulo de aplicaciones, proporcionando una interfaz de acceso única y consistente a esas aplicaciones y aislando a los usuarios sobre la interacción con distintas aplicaciones.
180. Patrones de integración Hay dos patrones que implementan los sistemas de EAI: 1. Mediación: aquí, los sistemas de EAI actúan como el vínculo de los enrutadores entre varias aplicaciones. En el lugar en el cual ocurre un evento interesante en alguna aplicación (ejemplo: se crea una nueva información, se completa una nueva transacción, etc.) se notifica a un módulo de integración del sistema EAI. El módulo entonces propaga esos cambios a las otras aplicaciones relevantes. 2. Federación: en este caso, el sistema EAI actúa como un consolidador de información entre varias aplicaciones. Todos los accesos del exterior a cualquiera de las aplicaciones son recibidos por el sistema EAI y este está configurado para exponer solo la información relevante, conectándose a las aplicaciones del mundo exterior y efectuar todas las interacciones con las aplicaciones internas sin intervención del agente externo.
181. Patrones de integración Los dos patrones son usados en conjunto frecuentemente. El mismo sistema EAI puede tener varias aplicaciones en sync (mediación), mientras sirve requerimientos de agentes externos contra esas aplicaciones (federación). EAI soporta patrones de acceso tanto asíncronos como síncronos, el primero es el habitual en el caso del patrón de mediación y el segundo en el caso de federación. Existen dos topologías de EAI principales: hub-and-spoke, y bus: En hub-and-spoke, el sistema EAI actúa como el centro (concentrador), que interactúa con las aplicaciones a través de conversaciones (spokes). En el modelo de bus, el sistema EAI es el bus (un módulo residente en un bus de mensajes existente o un middleware orientado a mensajes).
182. Tecnologías de integración Bus/hub: este se implementa frecuentemente al ampliar la funcionalidad de productos middleware existentes (servidores de aplicaciones, buses de mensajes) o se implementa como un programa monolítico (ej., sin usar ningún middleware), que actúa como su propio middleware. Conectividad de aplicaciones: el bus/hub se conecta a las aplicaciones mediante un conjunto de adaptadores (también conocidos como conectores). Esos son programas que conocen como interactuar con la aplicación específica. El adaptador efectúa una comunicación en dos vías, enviando requerimientos del hub hacia la aplicación, y notificando al hub cuando un evento de interés ocurren en la aplicación (un nuevo registro es insertado, una transacción es completada, etc.).
183. Tecnologías de integración Los adaptadores pueden ser tanto específicos a la aplicación o a un conjunto de aplicación. El adaptador puede residir en el mismo espacio de procesos que el bus/hub o ejecutarse en una localización remota e interactuar con el hub/bus a través de protocolos estándares de industria como colas de mensajes, servicios web, o protocolos propietarios. Formateo de datos y transformación: para prevenir que cada adaptador tenga que convertir los datos que van o vienen de otras aplicaciones, los sistemas EAI usualmente emplean un formato de datos común, al cual y desde el cual se convierten los formatos de las aplicaciones mediante servicios de transformación.
184. Tecnologías de integración Esto se hace en dos pasos: el adaptador convierte la información del formato de aplicación al formato común del bus; y entonces se pueden aplicar transformaciones semánticas a esto (ejemplo: convirtiendo códigos postales a nombres de ciudades, separando/fusionando objetos de una aplicación en objetos de otras aplicaciones, y así sucesivamente). Módulos de integración: un sistema EAI puede participar en operaciones de integración concurrentes en un momento dado, cada tipo de integración es procesada por un módulo de integración diferente. Los módulos de integración se suscriben a eventos de tipos específicos y ellos reciben las notificaciones de procesos en el momento en que esos eventos ocurren.
185. Tecnologías de integración Soporte a transacciones: cuando se emplean para integración de procesos, el sistema EAI provee consistencia transaccional entre las aplicaciones al ejecutar todas las operaciones que involucran una sola transacción distribuida (usando el protocolo de commit de dos fases o transacciones de compensación (operaciones que deshacen las acciones sobre un sistema dado).
186. Problemas de la implementación de EAI Los 7 principales retos que afrontan las compañías que usan EAI: 1. Cambio constante: La propia naturaleza de EAI es dinámica y requiere directores de proyecto dinámicos para su aplicación. 2. Falta de experiencia en EAI: La EAI requiere conocimiento de muchas problemáticas y aspectos técnicos. 3. Estándares en competencia: Dentro del campo de EAI, la paradoja es que los estándares de EAI no son por sí mismos universales, ya que cada proveedor particular trata de imponer los propios. 4. EAI es un paradigma de herramientas: EAI no es una herramienta, si no es un sistema y debe ser implementado como tal.
187. Problemas de la implementación de EAI 5. Construir interfaces es un arte: Realizar el proceso de ingeniería de la solución puede no ser suficiente. Las soluciones requieren ser negociadas con departamentos de usuarios para lograr un consenso común sobre el producto final. La falta de consenso en los diseños de las interfaces tiende a acarrear un esfuerzo excesivo para mapear los requerimientos de datos de varios sistemas. 6. Falta de detalle: La información que al principio parece poco importante, con el tiempo se puede volver crucial. 7. Rendición de cuentas: Puesto que varios departamentos pueden tener requerimientos contradictorios entre sí, debe asegurarse la rendición de cuentas para la estructura final del sistema.
188. Problemas de la implementación de EAI Otros problemas potenciales pueden abarcar las siguientes áreas: • Falta de coordinación centralizada del trabajo de la EAI.3 • Requerimientos nuevos: Las implementaciones de EAI deben ser extensibles y modulares para permitir cambios futuros. • Proteccionismo: Las aplicaciones cuyos datos son integrados, frecuentemente pertenecen a departamentos diferentes los cuales tienen razones técnicas, culturales y políticas para no querer compartir su información con otros departamentos.
189. Computación orientada a servicios La informática orientada a servicios representa una plataforma informática distribuida de nueva generación. Como tal, abarca muchas cosas, incluyendo su propio paradigma de diseño y principios de diseño, catálogos de patrones de diseño, lenguajes de patrones, un modelo arquitectónico distinto y conceptos, tecnologías y marcos relacionados. Suena como un paraguas bastante grande, y lo es. La informática orientada a servicios se basa en plataformas informáticas distribuidas anteriores y agrega nuevas capas de diseño, consideraciones de gobernanza y un amplio conjunto de tecnologías de implementación preferidas. Es por eso que tomarse el tiempo para entender sus mecánicas subyacentes antes de proceder a las fases reales de diseño y construcción de un proyecto de entrega es tiempo bien gastado.
190. Computación orientada a servicios Para comprender mejor la tez fundamental de una plataforma informática típica orientada a servicios, necesitamos describir cada una de sus partes principales, a las que nos referiremos como elementos: • Arquitectura orientada a servicios (SOA) • Servicios y Orientación a Servicios • Composiciones de servicios • Inventario de servicios • Una visión conceptual de la informática orientada a servicios • Una visión física de la informática orientada a servicios
191. Arquitectura orientada a servicios (SOA) SOA establece un modelo arquitectónico que tiene como objetivo mejorar la eficiencia, agilidad y productividad de una empresa mediante el posicionamiento de los servicios como el medio principal a través del cual se representa la lógica de las soluciones que apoyan la realización de los objetivos estratégicos asociados con la informática orientada a los servicios. Una plataforma orientada a servicios gira en torno al paradigma de diseño orientado al servicio y su relación con la arquitectura orientada a servicios. El término "arquitectura orientada a servicios" y su acrónimo asociado han sido utilizados tan ampliamente por los medios de comunicación y dentro de la literatura de marketing de proveedores que casi se ha convertido en sinónimo de computación orientada a servicios. Por tanto, es muy importante hacer una distinción clara entre lo que SOA es realmente y cómo se relaciona con otros elementos informáticos orientados a servicios.
192. Arquitectura orientada a servicios (SOA) Como arquitectura tecnológica, una implementación de SOA puede consistir en una combinación de tecnologías, productos, APIs, extensiones de infraestructura de soporte y varias otras partes. La cara real de una arquitectura orientada a servicios implementada es única dentro de cada empresa; sin embargo, se caracteriza por la introducción de nuevas tecnologías y plataformas que apoyan específicamente la creación, ejecución y evolución de soluciones orientadas a servicios. Como resultado, la construcción de una arquitectura tecnológica en torno al modelo arquitectónico orientado a servicios establece un entorno adecuado para la lógica de la solución que se ha diseñado de acuerdo con los principios de diseño de orientación a servicios.
193. Servicios y Orientación a Servicios La orientación a servicios es un paradigma de diseño compuesto por un conjunto específico de principios de diseño. La aplicación de estos principios al diseño de la lógica de la solución da como resultado una lógica de solución orientada a servicios. La unidad más fundamental de la lógica de la solución orientada a servicios es el servicio. Los servicios son programas de software físicamente independientes con características de diseño específicas que apoyan el logro de los objetivos estratégicos asociados a la informática orientada a servicios. La siguiente figura presenta los símbolos utilizados para representar un servicio desde una perspectiva de punto final.
194. Servicios y Orientación a Servicios A cada servicio se le asigna su propio contexto funcional distinto y se compone de un conjunto de capacidades relacionadas con este contexto. Esas capacidades adecuadas para la invocación por programas de consumidores externos se expresan comúnmente a través de un contrato de servicio publicado (al igual que una API tradicional).
195. Composiciones de servicios Una composición de servicios es un agregado coordinado de servicios. Es comparable a una aplicación tradicional, ya que su ámbito funcional suele estar asociado con la automatización de un proceso empresarial principal. La aplicación coherente de los principios de diseño para orientación a servicios conduce a la creación de servicios con contextos funcionales que son agnósticos a cualquier proceso empresarial. Por tanto, estos servicios agnósticos pueden participar en múltiples composiciones de servicios. La capacidad de que un servicio sea natural y repetidamente componible es fundamental para alcanzar varios de los objetivos estratégicos de la informática orientada al servicio. Por tanto, muchas de las características de diseño que distinguen un servicio le permiten participar eficazmente en composiciones de servicio.
196. Inventario de servicios Un inventario de servicios es una colección estandarizada y gobernada de forma independiente de servicios complementarios dentro de un límite que representa una empresa o un segmento significativo de una empresa. Una empresa puede incluir un inventario de servicios que represente la medida en que se ha adoptado SOA. Las iniciativas más grandes pueden incluso dar lugar a que la empresa en su totalidad esté compuesta por un inventario de servicios para toda la empresa. Alternativamente, un entorno empresarial puede contener varios inventarios de servicios, cada uno de los cuales puede estandarizarse, gobernarse y apoyarse individualmente mediante su propia arquitectura de tecnología orientada a servicios.
197. Inventario de servicios Los inventarios de servicios se crean normalmente a través de procesos de entrega descendentes que dan como resultado la definición de blueprints de inventario de servicio. La aplicación posterior de principios de diseño de orientación de servicio y estándares de diseño personalizados en todo un inventario de servicios es de suma importancia para establecer un alto grado de interoperabilidad entre servicios nativos. Esto apoya la creación repetida de composiciones de servicio eficaces. El inventario de servicios crece a medida que los proyectos ofrecen nuevos servicios. Además, las oportunidades de reutilizar los servicios existentes aumentan con cada proyecto posterior.
198. Visión conceptual de la informática orientada a servicios Haremos referencia a los elementos previamente definidos. Entenderlos individualmente es tan importante como entender cómo pueden relacionarse entre sí porque estas relaciones establecen algunas de las dinámicas más fundamentales de la informática orientada a Por lo tanto, revisemos estos elementos con un énfasis en cómo cada uno se vincula con los demás: • La arquitectura orientada a servicios representa una forma distinta de arquitectura tecnológica diseñada en apoyo de lógica de solución orientada a servicios, que se compone de servicios y composiciones de servicios formados y diseñados de acuerdo con la orientación a servicios. • La orientación a servicios es un paradigma de diseño compuesto por principios de diseño de orientación a servicios. Cuando se aplican a unidades de lógica de solución, estos principios crean servicios con características de diseño distintas que respaldan los objetivos generales y la visión de la informática orientada a servicios. • La informática orientada a servicios representa una plataforma informática de nueva generación que abarca el paradigma de orientación a servicios y la arquitectura orientada a servicios con el objetivo final de crear y ensamblar uno o más inventarios de servicios.
199. Visión física de la informática orientada a servicios Para apreciar plenamente cómo se utilizan en última instancia los elementos informáticos orientados a servicios, necesitamos explorar cómo se traducen en el mundo real. Para ello, debemos distinguir claramente el papel y la posición de cada elemento dentro de una perspectiva de implementación física, de la siguiente manera: • La lógica de solución orientada a servicios se implementa como servicios y composiciones de servicios diseñadas de acuerdo con los principios de diseño de orientación de servicio. • Una composición de servicio se compone de servicios que se han ensamblado para proporcionar la funcionalidad necesaria para automatizar una tarea o proceso empresarial específico. • Dado que la orientación al servicio da forma a muchos servicios como recursos empresariales independientes, varios programas de consumidor pueden invocar un servicio, cada uno de los cuales puede implicar ese mismo servicio en una composición de servicio diferente. • Una colección de servicios estandarizados puede formar la base de un inventario de servicios que se puede administrar de forma independiente dentro de su propio entorno de implementación física.
200. Visión física de la informática orientada a servicios • Múltiples procesos empresariales se pueden automatizar mediante la creación de composiciones de servicio que se extraen de un grupo de servicios agnósticos existentes que residen dentro de un inventario de servicios. • La arquitectura orientada a servicios es una forma de arquitectura tecnológica optimizada en soporte de servicios, composiciones de servicios e inventarios de servicios. Esta vista centrada en la implementación saca a la luz cómo la informática orientada a servicios puede cambiar la complejidad general de una empresa. Debido a que la mayoría de los servicios prestados se posicionan como recursos reutilizables agnósticos de los procesos empresariales, no pertenecen a ningún silo de aplicación. Al disolver los límites entre aplicaciones, la empresa está cada vez más representada por un creciente conjunto de servicios que existen dentro de un inventario de servicios en expansión.
201. Objetivos y beneficios de la informática orientada a servicios Es muy importante establecer por qué las comunidades de proveedores y usuarios finales dentro de la industria de TI están pasando por el problema de adoptar la plataforma informática orientada a servicios y abrazar todo el cambio que viene con él. La visión detrás de la informática orientada a servicios es extremadamente ambiciosa y, por lo tanto, también muy atractiva para cualquier organización interesada en mejorar realmente la eficacia de su empresa de TI. Para formar esta visión ha surgido un conjunto de metas y beneficios comunes. Estos establecen un estado de destino para una empresa que adopta correctamente la orientación al servicio.
202. Objetivos y beneficios de la informática orientada a servicios El próximo conjunto de secciones describe cada uno de estos objetivos y beneficios estratégicos: • Aumento de la interoperabilidad intrínseca • Aumento de la Federación • Mayores opciones de diversificación de proveedores • Mayor alineación de negocios y tecnología • Aumento del ROI • Mayor agilidad organizacional • Reducción de la carga de TI Vale la pena entender la importancia de estos objetivos y beneficios antes de estudiar y aplicar la orientación al servicio para que los principios de diseño se vean constantemente dentro de un contexto estratégico. Existe un vínculo concreto entre la aplicación exitosa de los principios de diseño de orientación de servicio y su consecución exitosa.
203. Aumento de la interoperabilidad intrínseca La interoperabilidad se refiere al intercambio de datos. Cuantos más programas de software interoperables sean, más fácil será para ellos intercambiar información. Los programas de software que no son interoperables deben integrarse. Por lo tanto, la integración se puede ver como un proceso que habilita la interoperabilidad. Un objetivo de la orientación del servicio es establecer la interoperabilidad nativa dentro de los servicios con el fin de reducir la necesidad de integración. De hecho, la integración como concepto comienza a desvanecerse dentro de entornos orientados a servicios (como se explicará más detalladamente en la lámina sobre Orientación a servicios y el concepto de "Integración"). Los servicios se diseñan para ser intrínsecamente interoperables independientemente de cuándo y para qué propósito se entreguen.
204. Aumento de la interoperabilidad intrínseca La interoperabilidad se fomenta específicamente mediante la aplicación coherente de los principios y estándares de diseño. Esto establece un entorno en el que los servicios producidos por diferentes proyectos en diferentes momentos se pueden ensamblar repetidamente en una enorme variedad de configuraciones de composición para automatizar tareas empresariales. La interoperabilidad intrínseca representa un objetivo fundamental de orientación a servicios que establece una base para la realización de otros objetivos y beneficios estratégicos. La estandarización de APIs, la escalabilidad, la previsibilidad del comportamiento y la fiabilidad son solo algunas de las características de diseño necesarias para facilitar la interoperabilidad, todas se abordan mediante los principios de orientación a servicios.
205. Aumento de la Federación Un entorno de TI federado es aquel en el que los recursos y las aplicaciones están unidos mientras mantienen su autonomía individual y su autogobierno. SOA tiene como objetivo aumentar una perspectiva federada de una empresa en cualquier medida en que se aplique. Esto lo logra a través de la amplia implementación de servicios estandarizados y compostables cada uno de los cuales encapsula un segmento de la empresa y lo expresa de manera coherente. En apoyo del aumento de la federación, la estandarización pasa a formar parte de la atención adicional inicial que recibe cada servicio en tiempo de diseño. En última instancia, esto conduce a un entorno en el que la lógica de la solución de toda la empresa se armoniza naturalmente, independientemente de la naturaleza de su implementación subyacente.
206. Mayores opciones de diversificación de proveedores La diversificación de proveedores se refiere a la capacidad que una organización tiene para elegir los productos de proveedores "mejores de su clase" y las innovaciones tecnológicas y usarlas juntas dentro de una empresa. No es necesariamente beneficioso para una organización tener un entorno diverso del proveedor; sin embargo, es beneficioso tener la opción de diversificar cuando sea necesario. Para tener y conservar esta opción se requiere que su arquitectura tecnológica no esté vinculada o bloqueada en ninguna plataforma de proveedor específica. Esto representa un estado importante para una empresa en el que proporciona la libertad constante para que una organización cambie, amplíe e incluso reemplace las implementaciones de soluciones y los recursos tecnológicos sin interrumpir la arquitectura de servicio federada general. Esta medida de autonomía de gobernanza es atractiva porque prolonga la vida útil y aumenta el retorno financiero de las soluciones de automatización.
207. Mayores opciones de diversificación de proveedores Al diseñar de una arquitectura orientada a servicios en consonancia con las principales plataformas SOA de proveedores, pero neutrales a ellas, y al posicionar los contratos de servicio como puntos de conexión estandarizados en toda una empresa federada, los detalles de implementación de servicios propietarios se pueden abstraer para establecer un marco de comunicaciones coherente entre servicios. Esto proporciona a las organizaciones opciones constantes, permitiéndoles diversificar su empresa según sea necesario. La diversificación de proveedores se apoya aún más en un marco de servicios web basado en estándares y neutral a proveedores. Dado que no impone requisitos de comunicación propietarios, los servicios web disminuyen aún más la dependencia de las plataformas de proveedores. Y como con cualquier otro medio de implementación, los servicios web deben ser moldeados y estandarizados a través de la orientación de servicios para convertirse en una parte federada de una SOA.
208. Mayor alineación de negocios y tecnología La medida en que se cumplen los requisitos empresariales de TI se asocia con la precisión con la que la lógica de negocios se expresa y automatiza mediante la lógica de las soluciones. Tradicionalmente las aplicaciones se han diseñado para abordar requisitos inmediatos o tácticos, lo que históricamente ha generado un desafío permanente por mantener las aplicaciones alineadas con las necesidades del negocio cuando cambia su naturaleza o su dirección. La informática orientada a servicios introduce un paradigma de diseño que promueve la abstracción en muchos niveles. Uno de los medios más eficaces por los que se aplica la abstracción funcional es el establecimiento de capas de servicio que encapsulan y representan con precisión los modelos de negocio. Al hacerlo, pueden existir representaciones comunes y preexistentes de lógica empresarial (entidades empresariales, procesos empresariales) implementada como servicios físicos.
209. Mayor alineación de negocios y tecnología Esto se logra mediante la incorporación de un proceso estructurado de análisis y modelado que requiere la participación práctica de expertos en la materia de negocio en la definición real de los servicios (como se explica en la página Análisis orientado a servicios). Los diseños de servicio resultantes son capaces de alinear la tecnología de automatización con la inteligencia empresarial a un nivel sin precedentes. Además, el hecho de que los servicios estén diseñados para ser intrínsecamente interoperables facilita directamente el cambio empresarial. A medida que los procesos de negocio se incrementan en respuesta a diversos factores (cambios en el clima empresarial, nuevos competidores, nuevas políticas, nuevas prioridades, etc.) los servicios se pueden reconfigurar en nuevas composiciones que reflejen la lógica de negocios cambiada. Esto permite que una arquitectura tecnológica orientada a servicios evolucione en conjunto con el propio negocio.
210. Aumento del ROI Medir el retorno de la inversión (ROI) de las soluciones automatizadas es un factor crítico para determinar cuán rentable es realmente una aplicación o sistema determinado. Cuanto mayor sea el retorno, más se beneficia una organización de la solución. Sin embargo, cuanto menor sea el retorno, más se come el costo de las soluciones automatizadas en los presupuestos y beneficios de una organización. Debido a que la naturaleza de la lógica de aplicación requerida ha aumentado en complejidad y debido a arquitecturas de integración no federadas en constante crecimiento que son difíciles de mantener y evolucionar, el departamento de TI promedio representa una cantidad significativa del presupuesto operativo general de una organización. Para muchas organizaciones, la sobrecarga financiera requerida por TI es una preocupación principal porque a menudo sigue aumentando sin demostrar ningún aumento correspondiente en el valor del negocio.
211. Aumento del ROI La informática orientada a servicios aboga por la creación de lógica de solución agnóstica, lógica que es agnóstica para cualquier propósito y, por lo tanto, útil para múltiples propósitos. Esta lógica multipropósito o reutilizable aprovecha plenamente la naturaleza intrínsecamente interoperable de los servicios. Los servicios agnósticos han aumentado el potencial de reutilización que se puede realizar al permitir que se ensamblen repetidamente en diferentes composiciones. Por lo tanto, cualquier servicio agnóstico puede verse reutilizado en numerosas ocasiones para automatizar diferentes procesos de negocio como parte de diferentes soluciones orientadas a servicios. Teniendo en cuenta este beneficio, se invierten gastos y esfuerzos iniciales adicionales en cada pieza de lógica de la solución para posicionarla como un activo de TI con el propósito de obtener rendimientos financieros repetibles y a largo plazo.
212. Aumento del ROI El énfasis en aumentar el ROI normalmente va más allá de los rendimientos tradicionalmente buscados como parte de las iniciativas de reutilización anteriores. Esto tiene mucho que ver con el hecho de que la orientación al servicio tiene como objetivo establecer la reutilización como una característica común y secundaria dentro de la mayoría de los servicios. Es importante reconocer que este objetivo no está vinculado simplemente a los beneficios tradicionalmente asociados con la reutilización del software. Las técnicas probadas de diseño de productos comerciales se incorporan y combinan con los enfoques existentes de entrega de aplicaciones empresariales para formar la base de un conjunto distinto de procesos de análisis y diseño orientados a servicios (como se describe más adelante en las páginas Análisis orientado a servicios y Diseño orientado a servicios).
213. Mayor agilidad organizacional La agilidad, a nivel organizativo, se refiere a la eficiencia con la que una organización puede responder al cambio. Aumentar la agilidad organizativa es muy atractivo para las corporaciones, especialmente las del sector privado. Ser capaz de adaptarse más rápidamente a los cambios de la industria y superar a los competidores tiene una enorme importancia estratégica. Un departamento de TI a veces puede ser percibido como un cuello de botella, lo que dificulta la capacidad de respuesta deseada al requerir demasiado tiempo o recursos para satisfacer los requisitos empresariales nuevos o cambiantes. Esta es una de las razones por las que los métodos de desarrollo ágiles han ganado popularidad, ya que proporcionan un medio para abordar las preocupaciones tácticas inmediatas más rápidamente.
214. Mayor agilidad organizacional La informática orientada a servicios está muy orientada a establecer una agilidad organizativa amplia. Cuando la orientación al servicio se aplica en toda una empresa, da como resultado la creación de servicios altamente estandarizados y reutilizables y, por lo tanto, agnósticos para los procesos empresariales principales y entornos de aplicaciones específicos. A medida que un inventario de servicios se compone de más y más de estos servicios agnósticos, un porcentaje creciente de su lógica de solución general no pertenece a ningún entorno de aplicación. En su lugar, dado que estos servicios se han posicionado como activos de TI reutilizables, se pueden componer repetidamente en diferentes configuraciones. Como resultado, el tiempo y el esfuerzo necesarios para automatizar procesos empresariales nuevos o modificados se reduce de forma correspondiente porque los proyectos de desarrollo ahora se pueden completar con un esfuerzo de desarrollo significativamente menos personalizado.
215. Mayor agilidad organizacional El resultado neto de este cambio fundamental en la ejecución de proyectos es una mayor capacidad de respuesta y un menor tiempo de comercialización, lo que se traduce en una mayor agilidad organizativa. Tenga en cuenta que la agilidad organizativa representa un estado de destino en el que las organizaciones trabajan a medida que ofrecen servicios y rellenan inventarios de servicios. La organización se beneficia de una mayor capacidad de respuesta después de que haya una cantidad significativa de servicios. Los procesos necesarios para modelar y diseñar esos servicios requieren más costo y esfuerzo iniciales que la creación de la cantidad correspondiente de lógica de solución mediante enfoques tradicionales de entrega de proyectos.
216. Mayor agilidad organizacional Por tanto, es importante reconocer que la orientación al servicio tiene un enfoque estratégico que pretende establecer una empresa altamente ágil. Esto es diferente de los enfoques de desarrollo ágiles que tienen un enfoque más táctico debido a un énfasis en la entrega de lógica de solución más rápidamente. Desde el punto de vista de la entrega, la orientación al servicio no tiende a aumentar la agilidad. Un cronograma de entrega se proyecta en función del porcentaje de lógica de solución ”nueva neta" que debe compilarse. Aunque, por ejemplo, solo se requiera el 35% de lógica nueva, la escala de tiempo se reduce en alrededor de un 50% porque todavía se requiere un esfuerzo significativo para incorporar los servicios existentes y reutilizables del inventario.
217. Reducción de la carga de TI La aplicación constante de la orientación al servicio da como resultado una empresa de TI con menor desperdicio y redundancia, menor tamaño y costo operativo, y reducción de los gastos generales asociados con su gobernanza y evolución. Una empresa de este tipo puede beneficiar a una organización a través de aumentos drásticos en eficiencia y rentabilidad. En esencia, el logro de los objetivos descritos anteriormente puede crear un departamento de TI más delgado y ágil; que es una carga menor para la organización y más bien un contribuyente habilitador a sus objetivos estratégicos. Si tomara una empresa automatizada típica y la redesarrollara por completo con servicios personalizados y normalizados, su tamaño general se reduciría considerablemente, lo que resultaría en un ámbito operativo reducido.
218. Modelos de servicios Independientemente de cómo se implementen los servicios, comúnmente se clasifican en uno de los siguientes modelos de servicios: • Servicios de Tareas (y servicios de tareas orquestadas) • Microservicios • Servicios de Entidades • Servicios Públicos Los modelos de servicios ayudan a establecer contextos funcionales y servicios de límites funcionales al proporcionar tipos genéricos predefinidos que son comunes a casi cualquier empresa de TI.
219. Capas de servicios Una vez establecidos, los modelos de servicios pueden crear capas de servicios conceptuales (grupos lógicos) que pueden facilitar la asignación de propiedad posterior y la gobernanza general del servicio. Las capas de servicios también proporcionan una perspectiva única de los servicios dentro de un inventario determinado, ya que la mayoría de las composiciones de servicios abarcan varias capas de servicios.
220. Patrones de implementación de código DevOps
221. DevOps • DevOps es una combinación de desarrollo de software y operaciones que hace hincapié en la comunicación, la colaboración y la cohesión entre los equipos de operaciones de TI y desarrolladores tradicionalmente independientes. • DevOps aboga firmemente por la automatización y el monitoreo de diferentes etapas de desarrollo, implementación y operación con el fin de obtener una integración continua sólida y consistente, la implementación y el funcionamiento de la aplicación y los servicios. • DevOps se centra en todo el ciclo de vida, incluida la planificación, la integración, las pruebas, el lanzamiento, la implementación, la retroalimentación, el cambio y la gestión.
222. DevOps • DevOps es una combinación de desarrollo de software y operaciones que hace hincapié en la comunicación, la colaboración y la cohesión entre los equipos de operaciones de TI y desarrolladores tradicionalmente independientes. • DevOps aboga firmemente por la automatización y el monitoreo de diferentes etapas de desarrollo, implementación y operación con el fin de obtener una integración continua sólida y consistente, la implementación y el funcionamiento de la aplicación y los servicios. • DevOps se centra en todo el ciclo de vida, incluida la planificación, la integración, las pruebas, el lanzamiento, la implementación, la retroalimentación, el cambio y la gestión.
223. DevOps • En otras palabras, DevOps permite agilizar la versión de software mediante la introducción de enfoques de desarrollo y comunicación que alinean el desarrollo, las operaciones y el aseguramiento de la calidad entre sí.
224. Ventajas de DevOps A continuación se indican algunas de las ventajas relevantes de DevOps: • Aumento de la velocidad • Entrega rápida • Escalabilidad • Mayor fiabilidad • Mejora de la colaboración organizativa
225. Prácticas de DevOps A continuación se indican las prácticas comunes de DevOps: • Integración continua (CI) • Entrega continua (CD) • Infraestructura como código (IaC) • Gestión automatizada de la configuración • Política como código (PaC) • Monitoreo y Registro • Colaboración y comunicación
226. Las etapas de DevOps DevOps incluye un ciclo continuo compuesto por 8 etapas diferentes: Etapas de “Dev” Etapas de “Ops” • Planificar • Liberación • Crear • Configurar • Verificar • Monitorear • Empaquetar • Retroalimentación
227. Implementación inmutable ¿Cómo se pueden implementar los servicios en la nube sin necesidad de mantener los recursos de infraestructura subyacentes, como servidores web o servidores virtuales? Problema Cuando los servicios se implementan en un servidor o en un contenedor, es posible que la infraestructura subyacente no esté preconfigurada para su implementación, lo que provoca retrasos hasta que el entorno se configura para admitirla. Solución Los servicios se pueden equipar para ser autohospedados al empaquetarse con los componentes necesarios y la información de configuración para que, tras su implementación en un entorno especial sin servidor, sean totalmente funcionales.
228. Implementación inmutable Aplicación Los servicios se diseñan, codifican e implementan junto con el descriptor en preparación para la implementación en un entorno sin servidor, que normalmente están disponibles para los proveedores de nube.
229. Patrones de disponibilidad Implementación redundante ¿Cómo se puede aumentar la fiabilidad y la disponibilidad de un servicio? • Un servicio que se está reutilizando activamente introduce un posible punto único de fallo que puede poner en peligro la fiabilidad de todas las composiciones en las que participa. • Múltiples implementaciones redundantes de servicios agnósticos con alto potencial de reutilización o proporcionando funcionalidad reutilizable crítica se pueden implementar para garantizar una alta disponibilidad, incluso cuando se producen excepciones o interrupciones inesperadas.
230. Patrones de disponibilidad Replicación de datos ¿Cómo se puede conservar la autonomía del servicio cuando los servicios requieren acceso a orígenes de datos compartidos? • La lógica del servicio se puede implementar de forma aislada para aumentar la autonomía del servicio, pero los servicios siguen perdiendo autonomía al requerir acceso a bases de datos compartidas. • Con este patrón, las implementaciones de servicio se pueden equipar con bases de datos dedicadas que proporcionan datos replicados desde un origen central. • De esta manera, los servicios pueden acceder a los datos actuales con plena autonomía y no requieren la propiedad exclusiva sobre los datos.
231. Patrones de disponibilidad y escalamiento Contenedorización ¿Cómo se puede proporcionar un entorno con el máximo soporte para servicios con requisitos de escalabilidad y recuperación de alto rendimiento? Los contenedores proporcionan varias ventajas sobre los servidores virtuales, ya que son más eficientes en cuanto a recursos, ya que no requieren que se incluya un sistema operativo invitado en el contenedor. • Un sistema de gestión de contenedores une los contenedores en ejecución y el sistema operativo host subyacente.
232. Patrones de disponibilidad Capacidad idempotente ¿Cómo puede una capacidad de servicio aceptar de forma segura varias copias del mismo mensaje para controlar el error de comunicación? • La idempotencia es un concepto importante dentro de las arquitecturas web y marcos de mensajería en general. El valor de este patrón es que lleva la regla de la idempotencia al nivel del contrato de servicio mediante la construcción de un nivel de fiabilidad de las comunicaciones entre el consumidor y el servicio sin necesidad de que compartan una conexión persistente. • Desde el punto de vista del servicio REST, para que una operación sea idempotente, los consumidores pueden realizar la misma llamada repetidamente mientras producen el mismo resultado. En otras palabras, realizar varias solicitudes idénticas tiene el mismo efecto que hacer una sola solicitud. Tenga en cuenta que la respuesta en sí puede no ser la misma debido a que el estado de un recurso cambia entre las solicitudes.
233. Patrones de escalabilidad y desempeño Distribución de la carga de trabajo ¿Cómo se puede evitar el uso excesivo de microservicios? • Problema: Los microservicios sometidos a grandes volúmenes de uso simultáneo pueden sufrir un rendimiento degradado, una disponibilidad y fiabilidad reducidas y pueden volverse susceptibles a errores generales. • Solución: el microservicio se escala horizontalmente y se utiliza un sistema de equilibrio de carga para distribuir cargas de trabajo en tiempo de ejecución entre varios recursos de TI. • Aplicación: La tecnología de equilibrio de carga se incorpora a la arquitectura de implementación de microservicios y se configura con algoritmos de equilibrio de carga adecuados para garantizar una eficacia distribución de cargas de trabajo.
234. Patrones de escalabilidad y desempeño Equilibrio de carga de servicio ¿Cómo puede un microservicio implementado acomodar el aumento de las cargas de trabajo? • Problema: una única implementación de microservicio tiene una capacidad finita, lo que puede provocar excepciones en tiempo de ejecución, errores y degradación del rendimiento cuando se superan sus umbrales de procesamiento. • Solución: se crean implementaciones redundantes del microservicio y se agrega un sistema de equilibrio de carga para distribuir dinámicamente las cargas de trabajo entre las implementaciones de microservicios. • Aplicación: las implementaciones de microservicios duplicadas se organizan en un grupo de recursos. El equilibrador de carga se posiciona como un componente externo o puede estar integrado, lo que permite a los servidores de hospedaje equilibrar las cargas de trabajo entre sí.
235. Patrones de escalabilidad Escalabilidad dinámica ¿Cómo se pueden escalar automáticamente los microservicios en respuesta a la demanda fluctuante? • Problema: Es difícil equipar un microservicio para que se ajuste a sus requisitos de procesamiento. Si la demanda del microservicio está por debajo de su capacidad, está infrautilizada y si la demanda está por encima de su capacidad está sobreutilizada o no puede satisfacer la demanda. • Solución: El microservicio se puede integrar con una arquitectura reactiva capaz de escalarlo automáticamente horizontal o verticalmente en respuesta a la demanda fluctuante. • Aplicación: El escalado horizontal dinámico se puede habilitar mediante el uso de grupos de microservicios y componentes idénticos capaces de dispersar y retraer cargas de trabajo en cada grupo. El escalado vertical dinámico se puede habilitar mediante tecnología capaz de intercambiar microservicios o componentes en tiempo de ejecución.
236. Patrones de desempeño Elección de nodo de líder ¿Cómo se pueden coordinar varias instancias del mismo microservicio para completar una tarea mayor? • Problema: A veces, la finalización de una tarea requiere la participación de varias instancias. Si el consumidor que invoca las instancias no tiene la lógica necesaria para coordinarlas, pueden producirse excepciones en tiempo de ejecución que provoquen daños en los datos y errores. • Solución: una de las instancias invocadas se designa como nodo principal, responsable de agregar las otras instancias en un esfuerzo coordinado para completar la tarea. • Aplicación: Se utiliza un mecanismo de elección de líder confiable, aisladodel tiempo de ejecución para elegir el nodo principal.
237. Replicación de mensajes y datos El Toerema CAP, también llamado Conjetura de Brewer, enuncia que es imposible para un sistema de cómputo distribuido garantizar simultáneamente: • La consistencia (Consistency), es decir, cualquier lectura recibe como respuesta la escritura más reciente o un error. • La disponibilidad (Availability), es decir, cualquier petición recibe una respuesta no errónea, pero sin la garantía de que contenga la escritura más reciente. • La tolerancia al particionado (Partition Tolerance), es decir, el sistema sigue funcionando incluso si un número arbitrario de mensajes son descartados (o retrasados) entre nodos de la red. Un sistema no puede garantizar más de dos de estas tres simultáneamente.
238. Patrones de sincronización Mensajería controlada por eventos ¿Cómo se puede notificar automáticamente a los consumidores de servicios de los eventos de servicio en tiempo de ejecución? • El patrón de mensajería controlada por eventos proporciona una alternativa eficaz al sondeo de mensajes para determinar cuándo se ha producido un evento de interés. • Este patrón introduce un programa de gestión de eventos, que permite al consumidor de servicios establecerse como suscriptor de eventos asociados a un servicio (que asume el papel de editor).
239. Patrones de sincronización Cola asíncrona ¿Cómo puede un servicio y sus consumidores acomodar errores aislados y evitar el bloqueo innecesario de recursos? • La comunicación sincrónica requiere una respuesta inmediata a cada solicitud y, por lo tanto, fuerza el intercambio bidireccional de datos para cada interacción de servicio. • Cuando se requieren servicios para llevar a cabo la comunicación síncrona, tanto el consumidor de servicio como el de servicio deben estar disponibles y listos, lo que puede introducir problemas de confiabilidad. • Debido a su naturaleza secuencial, los intercambios de mensajes sincrónicos pueden imponer aún más la sobrecarga de procesamiento, porque el consumidor tiene que esperar hasta que reciba una respuesta de su solicitud originalantes de proceder a su próxima acción.
240. Patrones de sincronización Este patrón introduce una cola como un búfer intermediario que recibe mensajes y, a continuación, los reenvía en nombre del remitente. • Si el servicio de destino no está disponible, la cola actúa como almacenamiento temporal y conserva el mensaje. • A continuación, intenta periódicamente la retransmisión. • Mientras el servicio o el consumidor está procesando el contenido del mensaje, el otro puede desactivarse (o pasar a otro procesamiento) con el fin de minimizar el consumo de memoria.
No comments...
none