La arquitectura de 4 +1 vistas La arquitectura de un sistema es quizs el artefacto ms importante que puede emplea rse para manejar estos diferentes

puntos de vista y controlar el desarrollo iter ativo e incremental de un sistema a lo largo de su ciclo de vida. Vista de casos de uso Comprende los casos de uso que describen el comportamiento del sistema tal y com o es percibido por los usuarios finales, analistas y encargados de las pruebas. Vista de diseo Comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solucin. Esta vista soporta principalmente los requisitos funcional es del sistema, entendiendo por ello los servicios que el sistema debera proporci onar a sus usuarios finales. Vista de procesos Comprende los hilos y procesos que forman los mecanismos de sincronizacin y concu rrencia del sistema. Esta vista cubre principalmente el funcionamiento, capacida d de crecimiento y rendimiento del sistema. Vista de implementacin Comprende los componentes y archivos que se utilizan para ensamblar y hacer disp onible el sistema fsico. Esta vista se preocupa principalmente de la gestin de con figuraciones de las distintas versiones de un sistema, a partir de componentes y archivos un tanto independientes y que pueden ensamblarse de varias formas para producir un sistema de ejecucin. Vista de despliegue Contiene los nodos que forman la topologa hardware sobre la que se ejecuta el sis tema. Esta vista se preocupa principalmente de la distribucin, entrega e instalac in de las partes que constituyen el sistema fsico. Esta vista se preocupa principa lmente de la distribucin, entrega e instalacin de las partes que constituyen el si stema fsico. Vistas y Frameworks La mayora de los frameworks y estrategias reconoce entre tres y seis vistas, que son las que se incluyen en el cuadro. Una vista es, para definirla sucintamente, un subconjunto resultante de practicar una seleccin o abstraccin sobre una realid ad, desde un punto de vista determinado. El marco de referencia para la arquitectura empresarial de John Zachman Identifica 36 vistas en la arquitectura ( celdas ) basadas en seis niveles (scope, e mpresa, sistema lgico, tecnologa, representacin detallada y funcionamiento empresar ial) y seis aspectos (datos, funcin, red, gente, tiempo, motivacin). El Modelo de Referencia para Procesamiento Distribuido Abierto (RM-ODP) Es un estndar de ISO y de ITU que define un marco para la especificacin arquitectni ca de grandes sistemas distribuidos. Define, entre otras cosas, cinco puntos de vista (viewpoints) para un sistema y su entorno: empresa, informacin, computacin, ingeniera y tecnologa. C4ISR Architecture Framework Es el marco de referencia arquitectnico promovido por el Departamento de Defensa de Estados Unidos (DoD). Las vistas arquitectnicas homologadas son la Operacional (que identifica relaciones y necesidades de informacin), la de Sistemas (que vin cula capacidades y caractersticas a requerimientos operacionales) y la Tcnica (que prescribe estndares y convenciones). El marco de referencia arquitectnico de The Open Group (TOGAF) Reconoce cuatro componentes principales, uno de los cuales es un framework de al to nivel que a su vez define cuatro vistas: Arquitectura de Negocios, Arquitectu

ra de Datos/Informacin, Arquitectura de Aplicacin y Arquitectura Tecnolgica. En 1995 Philippe Kruchten propuso su clebre modelo 4+1 Vinculado al Rational Unified Process (RUP) Que define cuatro vistas diferentes de la arquitectura de software: (1) La vista lgica, que comprende las abstracciones fundamentales del sistema a partir del do minio de problemas. (2) La vista de proceso: el conjunto de procesos de ejecucin independiente a partir de las abstracciones anteriores. (3) La vista fsica: un ma peado del software sobre el hardware. (4) La vista de desarrollo: la organizacin esttica de mdulos en el entorno de desarrollo. El quinto elemento considera todos los anteriores en el contexto de casos de uso. Lo que acadmicamente se define com o AS concierne a las dos primeras vistas. Mtodos de diseo orientado a objetos (Object-Oriented design methods) Esta nueva tecnologa cambia la naturaleza del anlisis y diseo de software como un p roceso industrial. Los productos de software pueden ser desarrollados de manera similar a los productos de hardware. La programacin orientada a objetos cambia de escribir instrucciones a interconectar componentes de software reutilizables. Programacin orientada a objetos (Object oriented programming) La programacin orientada a objetos fue primero discutida en Norway en los inicios de los 70 en conexin con el lenguaje Simula. Ahora hay en existencia lenguajes o rientados a objetos, sistemas operativos, interfaces de usuario, y bases de dato s. Mtodologa OOP (OOP Method) La programacin orientada a objetos (OOP) es una metodologa para dirigir problemas de programacin complicados. La OOP considera a los sistemas como objetos independ ientes que interactan y operan en sus componentes. Los objetos sern definidos prop iamente en el OOD (diseo orientado a objetos). Las acciones son hechas a los obje tos y son tomadas por los objetos para comunicarse por mensajes. Las acciones de finidas dentro del objeto son ocultadas al usuario. La nica interfaz vista es el mensaje resultante proveniente del objeto. OOP es un cambio de forma de pensar ( mindset). Considera al mundo como objetos que pueden actuar. Un objeto puede tom ar acciones y tener acciones hacia l. Los objetos, desde una vista de muy alto ni vel, son entidades que existen nicamente en el tiempo y espacio. En otras palabra s, los objetos tienen un estado, y estn caracterizados por las acciones que reali zan sobre otros objetos y las acciones realizadas sobre ellos. Los objetos puede n funcionar como actores, agentes, y servidores, dependiendo de su relacin con ot ros objetos. Fortaleza de OOP (OOP strength) La fortaleza del enfoque es la forma en la cual un sistema complejo puede ser ex presado en trminos de sus componentes y sus relaciones, ms que apuntar hacia (addr essing) un sistema como un proceso largo. Enfoque convencional vs. OOP (OOP vs. conventional approach) La OOP es ms apropiada para problemas que carecen de predectibilidad. Si todos lo s aspectos de un problema son bien comprendidos y requieren lgica de control, ent onces un enfoque ms convencional es probablemente requerido. Diseo orientado a objetos (Object-oriented design) El diseo orientado a objetos (OOD) se enfoca en los aspectos de diseo y de impleme ntacin del proceso de software. Grady Booch es el desarrollador de este mtodo. OOD apunta hacia estas actividades: diseo preliminar, simulacin, prototipado, diseo de tallado, codificacin, prueba y mantenimiento de software. Concepto OOD (OOD concept) OOD concibe un modelo de un sistema que est basado en entidades reales. Un proble ma de espacio est siempre enfocado en alguna parte del mundo real, y el espacio d e solucin es implementado por una combinacin de software y hardware. H. Ledgard de sarroll un modelo que describe una tarea de programacin tpica.

Principios del OOD (OOD principles) En OOD, el sistema es diseado alrededor de objetos que existen en el modelo de la realidad. Un objeto es definido como una entidad que: Tiene estado Es caracterizado por las acciones que sufre y que requiere de otros objetos Es una instancia nica de alguna clase (posible annima) Es denotado por un nombre Tiene visibilidad restringida de y hacia otros objetos Puede ser visto ya sea por su especificacin o por su implementacin Un constructor Es una operacin que altera el estado de un objeto. Un selector Es una operacin que evala el estado actual del objeto. Un iterador Es una operacin que permite explorar todas las partes de un objeto. La semntica esttica Es expresada por la existencia de las operaciones que sufre o requiere de otros objetos. La semntica dinmica Es expresada por el efecto que cada operacin tiene en un objeto. La semntica dinmic a puede incluir concurrencia entre objetos. La vista exterior De un objeto sirve para capturar el comportamiento abstracto. Un objeto puede in teractuar con otro viendo solo la vista exterior sin saber cmo el otro es represe ntado o implementado. La vista interna Indica como el comportamiento es implementado, y no es visible desde el exterior . En el cuerpo de un objeto o clase, t escoges una de muchas posibles representac iones que implementan el comportamiento de la especificacin. Mtodo OOD (OOD method) El mtodo OOD ha estado en uso desde 1981 y ha sido aplicado a un gran espectro de reas de problemas. El mtodo busca realizar: Descomposicin lgica y fsica Comportamiento esttico y dinmico El mtodo tambin busca las dos dimensiones de la estructura del sistema que son pec uliares de los sistemas orientados a objetos: Jerarquas padre-hijo y antigedad (seniority) Descomposicin de objeto y clase Pasos del OOD 1. Identifica los objetos y sus atributos. 2. Identifica las operaciones sufridas y requeridas por cada objeto. 3. Establece la visibilidad de cada objeto en relacin con otros objetos. 4. Establece la interfaz de cada objeto. 5. Implementa cada objeto. Notacin OOD (OOD notation) Una notacin debe ser representada claramente, de tal forma que todos los detalles relevantes del diseo sean visibles. Una notacin consiste de cuatro partes. La generacin del conjunto de estas partes c onstituye los productos del OOD. Las cuatro partes son: 1. Diagrama de Hardware (Hardware diagram)

2. Estructura de Clase (Class structure) 3. Diagrama de Objetos (Object diagram) 4. Diagrama de Arquitectura (Architecture diagram) Diagrama de Hardware El diagrama de hardware afirma la existencia de procesadores, dispositivos, rede s y conexiones. Un diagrama de hardware aparece como una grfica, mientras que los procesadores, dispositivos y redes son vrtices de la grfica, y las conexiones son arcos dirigidos. Diagrama de Objetos Representan la segunda dimensin del diseo lgico de un sistema. Estticamente los diag ramas de objetos son usados para expresar la visibilidad de cada objeto en relac in con otros objetos; dinmicamente, los diagramas de objetos son utilizados para e xpresar el tiempo y espacio en la comunicacin entre objetos y para expresar el pa ralelismo que pudiera existir entre una coleccin de objetos. Diagrama de arquitectura Representan el diseo fsico de un sistema y capturan la informacin esttica. Cada diag rama de arquitectura contiene smbolos que denotan componentes y dependencias; los componentes representan componentes estructurales y las dependencias representa n una compilacin de relaciones entre componentes. Modelos del desarrollo orientado a objetos El desarrollo de software orientado a objetos incluye los siguientes modelos: Modelo de Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual s e desarrolla en cooperacin con otros modelos como se ver ms adelante. Modelo de Anlisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de anlisis, que es estable con respecto a cambios, lo que lo hace un mode lo lgico independiente del ambiente de implementacin. Modelo de Diseo: La funcionalidad de los casos de uso, ya estructurada por el anlisis, la realiza el modelo de diseo, adaptndose al ambiente de implementacin real y refinndose an ms. Modelo de Implementacin: Los casos de uso se instrumentan mediante el cdigo fuente en el modelo de impleme ntacin. Modelo de Pruebas: Los casos de uso se comprueban a travs de las pruebas de componentes y de integra cin. Modelo de Requisitos El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la f uncionalidad que ofrecer desde la perspectiva del usuario. Este modelo puede trab ajar como un contrato entre el desarrollador y el cliente, o usuario del sistema , por lo que deber proyectar lo que el cliente desea segn la percepcin del desarrol lador. Por ello, es esencial que los clientes lo comprendan. Modelo de Anlisis Es importante enfatizar que el modelo de anlisis es una representacin conceptual, correspondiente al problema y modelo de requisitos, en trmino de clase de objetos . Arquitectura de Clases El modelo de anlisis tiene como objetivo generar una arquitectura de objetos que

sirva como base para el diseo del sistema. Tipos de diagramas UML tiene tres clases principales de diagramas. Los diagramas estticos Describen la estructura lgica invariable de los elementos software representando clases, objetos, estructuras de datos y las relaciones entre ellas. Los diagramas estructurales Sirven para visualizar, especificar, construir y documentar los aspectos estticos de un sistema. Los diagramas de comportamiento Se emplean para visualizar, especificar, construir y documentar los aspectos dinm icos de un sistema. Diagrama de objetos. Muestra un conjunto de objetos y sus relaciones en un momento particular de la e jecucin del sistema. El diagrama de clases Muestra las clases y relaciones principales del programa. Diagrama de secuencia. Describe cmo est implementado el mtodo. Los diagramas de colaboracin Contienen la misma informacin que los diagramas de secuencia. Sin embargo, mientr as que los diagramas de secuencia clarifican el orden de los mensajes, los diagr amas de colaboracin clarifican las relaciones entre los objetos. UML Tiene una notacin muy comprensiva para las mquinas de estados finitos, su diagrama de estado. La figura 1.15 muestra un diagrama de estado, justo el subconjunto ms simple de la notacin de estados finitos.