Facultad de Ingeniería

Transcripción

1 Universidad Nacional del Santa Facultad de Ingeniería EAP Ingeniería de Sistemas e Informática Desarrollo de Software Orientado a Objetos Versión Mayo 2009 Por: Ing. Camilo Ernesto Suárez Rebaza Docente UNS Dpto. Acad. Ing. Civil y Sistemas EAP Ingeniería de Sistemas e Informática

2 - 2 - INDICE I. Fundamentos de la Tecnología Orientada a Objetos Conceptos Básicos de la Orientación a Objetos Tecnologías Orientadas a Objetos... 5 II. Sistemas de Información Ciclo de Vida de los Sistemas de Información Tipos y Usos de los Sistemas de Información Metodología para el desarrollo de Sistemas... 9 III. Arquitectura Cliente/Servidor Terminología y Conceptos Capas en una Arquitectura Cliente /Servidor IV. Lenguaje Unificado de Modelado (UML) Modelo Conceptual de UML Modelado de la Arquitectura de un Sistema V. Proceso Unificado de Rational (RUP) Mejores Prácticas para el desarrollo de Software Estructura del Proceso: Dos dimensiones Core Workflows (Flujos de Trabajo Central) VI. Rational Rose VII. Bibliografía

3 INTRODUCCION En la actualidad los sistemas de información basados en computadoras, son el centro de actividades de muchas organizaciones y objeto de gran consideración en la toma de decisiones. Las tecnologías de información aplicadas eficientemente a los sistemas automatizados hacen posible que las organizaciones tengan una estructura funcional de alto desempeño para actuar como negocios integrados. Esto motiva a que varias organizaciones traten de adoptar los nuevos avances tecnológicos de la información con el propósito de integrar y mejorar el control de su carga procesal. La implantación de sistemas informáticos en las organizaciones no está siendo cabalmente explotada, ya que son pocos los colegios que utilizan adecuadamente sus equipos computarizados, llegando a usar en sus áreas administrativas herramientas ofimáticas para la presentación de documentos y mecanismos manuales para el procesamiento de Datos. Esto conlleva a buscar una mejora en la actual forma de trabajo administrativo de los colegios, automatizando sus principales procesos de control con el fin de obtener información rápida, exacta y oportuna.

4 I. Fundamentos de la Tecnología Orientada a Objetos 1.1. Conceptos Básicos de la Orientación a Objetos Algunas de las ideas fundamentales que subyacen en la tecnología orientada a objetos son las siguientes: Objeto: Los objetos son construcciones representacionales de las entidades. Los objetos encapsulan las características estructurales conocidas como atributos y las características de comportamiento conocidas como operaciones. Los atributos son construcciones que representan las características estructurales de las entidades y determinan los posibles estados de un objeto. Las operaciones son construcciones representacionales de las características de comportamiento de las entidades y determinan los comportamientos posibles de un objeto invocado, en respuesta a la recepción de un mensaje. Los objetos son instanciamientos de clases. Clases: Las clases son descripciones de objetos con una implementación en común. Las clases están ligadas a la implementación uniforme de las características estructurales y de comportamiento, es decir especifica una estructura de datos y los métodos operativos permisibles que se aplican a cada uno de sus objetos. Fundamentalmente, las clases son descripciones de objetos con atributos, implementación de operaciones, semánticas, asociaciones e interacciones comunes. Métodos: Los métodos especifican la forma en que se controlan los datos de un objeto. Los métodos en una clase sólo hacen referencia a las estructuras de datos de ese tipo de objeto. No tienen acceso directo a las estructuras de datos de otros objetos, debiéndoles enviar un mensaje para utilizar su estructura. Herencia: Es un mecanismo mediante el cual se puede crear una nueva clase partiendo de una existente, se dice entonces que la nueva clase hereda las características de la clase existente, aunque se le puede añadir 4

5 más capacidades o modificar las que tiene. Por lo tanto una subclase puede heredar la estructura de datos y los métodos o algunos de los métodos de su clase padre o superclase. Polimorfismo: Hace referencia a la posibilidad de que dos métodos implementen distintas acciones, aun teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o de los parámetros que recibe. Es una operación que adopta varias formas de implantación, es decir se puede hacer una solicitud de una operación sin conocer el método que debe ser llamado. Estos detalles de la implantación quedan ocultos para el usuario. Mensajes: Un mensaje es una solicitud para llevar a cabo una operación indicada y producir un resultado. Una solicitud invoca una operación específica, con uno o más objetos como parámetros Tecnologías Orientadas a Objetos La Tecnología Orientada a Objetos es un nuevo enfoque sobre la manera de organizar las diferentes piezas que componen un sistema de información (software), el equipo físico (hardware) o una base de datos. Estas piezas son denominadas "objetos", los cuales son pequeños subsistemas independientes con datos propios caracterizados por clases y tipos, y que están regidos por propiedades como herencia, comunicación con lenguejes, poliformismos y otros que en conjunto permiten diferentes ventajas prácticas. Análisis Orientado a Objetos (AOO): En el AOO se distinguen los objetos que van a ser parte de la aplicación. En un primer momento, no se debe enfocar con rigurosidad los objetos que pueden hacer falta en una aplicación. Lo que se hace, es un Brain Storming (tormenta de ideas depuradas con posterioridad), para luego explicar con mayor claridad los puntos funcionales definidos utilizando escenarios. Hay que tener en claro la idea de que un buen análisis puede acortar 5

6 considerablemente la fase de desarrollo de programas, por ello, no se debe escatimar horas en organizar y estructurar la aplicación en cuestión. Diseño Orientado a Objetos (DOO): El DOO de una aplicación es la implementación del AOO, teniendo en cuenta el lenguaje con el que se va a programar. El enfoque particular del análisis orientado a objetos (AOO), modela la forma en que las personas comprenden y procesan la realidad a través de los conceptos que adquieren. Estos conceptos se pueden implantar por diversos medios, entre los que están las máquinas, computadoras y personas. Así uno de los objetivos del diseño se restringe al software de aplicación, en donde los diseños orientados a objetos (DOO) no necesitan de un lenguaje de programación orientado a objetos para implantarse. Programación Orientada a Objetos (POO): Anteriormente la mayoría de las personas programaban de un modo TOP- Down, en el que la programación era totalmente secuencial. En la POO los mismos programas son vistos como objetos. El interés creciente en el campo del análisis y el diseño orientado a objetos es debido a que la programación orientada a objetos (POO) permite la producción de diseños con esquemas flexibles, haciendo posible una fácil estructuración del programa, similar a la forma de pensar humana. Base de Datos Orientada a Objetos (BDOO) : Una base de datos orientada a objetos (BDOO) es una base de datos inteligente que está diseñada para ser físicamente eficiente en el almacenamiento de datos complejos. Las bases de datos orientadas a objetos toman la idea de las bases inteligentes de datos a su conclusión lógica. No se tiene acceso a dato alguno si no es a través de los métodos almacenados en la base de datos. Estos métodos están listos para entrar en acción al momento en que reciben una solicitud. Los datos de todos los objetos quedan entonces encapsulados. 6

7 II. Sistemas de Información 2.1. Ciclo de Vida de los Sistemas de Información El concepto de ciclo de vida de un sistema de información es medular en las investigaciones de sistemas. Durante su desarrollo, cada sistema se mueve a través de varias fases de un ciclo de vida, después del cual sólo funciona por varios años con un mínimo mantenimiento. El sistema se deteriora gradualmente hasta el punto en que cesa de funcionar por completo y se comienza un nuevo ciclo de vida con el desarrollo de un nuevo sistema. Los autores sobre sistemas de información ilustran el ciclo de vida con diferentes números de fases. Los ciclos de vida de sistemas varían en gran manera en términos de longitud, pero por lo regular el ciclo de vida de un sistema de información está en el rango de 3 a 8 años Tipos y Usos de los Sistemas de Información Los Sistemas de Información cumplen tres objetivos básicos: 1) Automatizar los procesos operativos. 2) Proporcionar información que sirva como apoyo al proceso de toma de decisiones organizacionales. 3) Lograr ventajas competitivas a través de su implantación y uso. Los Sistemas de Información que logran la automatización de procesos operativos dentro de una organización, son llamados frecuentemente Sistemas Transaccionales, ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, entradas, salidas y sus controles. Por otra parte, los Sistemas de Información que apoyan el proceso de toma de decisiones son llamados Sistemas de Soporte a la Toma de Decisiones. El tercer tipo de sistemas, de acuerdo con su uso y objetivo, es el de los Sistemas Estratégicos, los cuales se desarrollan en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información. Por último se considera un cuarto tipo de Sistemas de Información denominado Sistemas Personales de Información, enfocado a incrementar la productividad de los usuarios. 7

8 Sistemas de Control de Información: El Control es un sistema que permite asegurar que la puesta en marcha de los objetivos institucionales se desarrolle de acuerdo a la planificación, o bien, que se ajusten los procesos a aquellas variables que no pudieron ser previstas durante el período de planificación. Para diseñar un proceso de control de información, se reconocen cinco pasos esenciales, que son: a) Definición de los resultados deseados por la Institución, para ello los objetivos deben expresarse en términos precisos. b) Establecer predictores de resultados, para controlar el conjunto de actividades durante la marcha del proyecto. c) Definir los estándares para los predictores y los resultados, determinando normas para evaluar tanto los resultados intermedios como los finales. d) Diseñar una red de información y retroalimentación, recopilando información en las diversas etapas del proyecto, y comparándola con las normas definidas. e) Evaluar la información y poner en marcha la acción correctiva. Un Sistema de Control de Información es un Sistema de Informacción transaccional y estratégico que abarca el control de: La planeación y administración de recursos, para apoyar los objetvos del sistema de información Los recursos de cómputo, para ser utilizado en forma efectiva proporcionando controles de entrada y salida adecuados, y guardando los archivos de datos en un almacenamiento seguro. El software del sistema, siguiendo procedimientos sistemáticos para mantener y usar el software adquirido o desarrollado. El acceso a los recursos de cómputo, para prever la seguridad física y lógica de los recursos de cómputo evitando el uso no autorizado. Integridad de Sistemas: La integración es el método o procedimiento que sigue una Institución con el fin de aprovechar todos los medios señalados por la mecánica 8

9 administrativa. La integridad es considerada como una de las fuerzas de diseño que actúa sobre los componentes principales de un Sistema de Información, permitiendo la comunicación entre dependencias dentro y fuera de un área Institucional. Para desarrollar un Sistema Integral es necesario seguir tres pasos bien marcados, que son: a) Usar métodos adecuados para la selección de elementos y recursos necesarios en cada dependencia institucional. b) Articular rápida y eficazmente los nuevos elementos a la funcionalidad de cada dependencia. c) Estudiar las necesidades de progreso y desarrollo de las nuevas funcionalidades de la institución. La integración de los sistemas de información tienden a diseñarse con un acoplamiento más estrecho entre sus diversas dependencias funcionales, permitiendo que la conectividad y la comunicación mejore dentro de las mismas. La tecnología informática está insertada y enlazada en las organizaciones para una sincronización completa y una coordinación de sus operaciones. Un sistema integral evita la separación funcional y espacial del lugar de trabajo, dando como resultado una malla de información organizacional Metodología para el desarrollo de Sistemas La metodología del desarrollo de sistemas es el camino que siguen los analistas de sistemas para realizar su trabajo. Se emplea el término genérico de analista de sistemas para describir a la persona que tiene la responsabilidad principal de conjuntar los componentes estructurales, dándoles forma y sustancia en conformidad con las fuerzas del diseño para construir sistemas de información exitosos. En una organización pequeña, el analista quizás no solo diseñará el sistema de información, sino que también hará la programación y operará la computadora. En una organización grande el analista de sistemas solo preparará las especificaciones del diseño que se darán a los técnicos. 9

10 III. Arquitectura Cliente/Servidor La tecnología informática permite no sólo disminuir el papeleo y en general agilizar las operaciones, sino también aumentar la competitividad de la empresa. Los tiempos actuales han modificado substancialmente la forma de operar de las organizaciones y ha inducido modificaciones en el quehacer de la tecnología computacional dentro de ellas. Algunos de los aspectos que han cambiado son los siguientes: Las aplicaciones deben ser desarrolladas más rápidamente pues los requerimientos del negocio cambian rápidamente. La importancia de contar con una buena información destaca el fundamental papel que juegan los sistemas de información. Cada vez es más importante el poder hacer que la información esté disponible en donde se necesita. A medida que crece la competencia, las organizaciones tienen cada vez menos recursos disponibles para los proyectos internos. Con el fin de aumentar la productividad y de facilitar el uso de las aplicaciones por parte de los usuarios, se requieren interfaces simples e intuitivas, y que proporcionen un acceso transparente a la información. Cada vez es mayor la tendencia hacia la integración de los sistemas evitando las "islas de información" en las diferentes dependencias de una empresa. Las aplicaciones deben adaptarse al ritmo vertiginoso de desarrollo de la tecnología, para que puedan aprovechar sus potencialidades. Las tecnologías computacionales modernas buscan responder a éstas necesidades empresariales y para ello plantean nuevas formas de hacer las cosas. Entre ellas una de las más importantes es el llamado modelo o Arquitectura Cliente/Servidor. En el sentido más estricto, el término Cliente/Servidor describe un sistema en el que una máquina cliente solicita a una segunda máquina llamada servidor que ejecute una tarea específica. El cliente suele ser una computadora personal común conectada a una LAN, y el servidor es, por lo general, una máquina anfitriona, como un servidor de archivos PC. Algunas de las principales LAN cliente/servidor con servidores especializados que pueden realizar trabajos para clientes, incluyen a Windows NT, NetWare de Novell, 10

11 VINES de Banyan y LAN Server de IBM entre otros. Todos estos sistemas operativos de red pueden operar y procesar solicitudes de aplicaciones que se ejecutan en clientes, mediante el procesamiento de las solicitudes mismas Terminología y Conceptos Cliente: Una aplicación que inicia una comunicación con otra se la califica como Cliente. Los usuarios finales invocan aplicaciones cliente cuando utilizan un servicio de red. Cada vez que se ejecuta una aplicación cliente, esta contacta con el servidor, le envía una solicitud de servicio y espera la respuesta o resultados del servicio. Los Clientes interactúan con el usuario, usualmente en forma gráfica. Frecuentemente se comunican con procesos auxiliares que se encargan de establecer conexión con el servidor, enviar el pedido, recibir la respuesta, manejar las fallas y realizar actividades de sincronización y de seguridad. Por lo tanto, un proceso cliente es el encargado de llevar a cabo la interacción con el usuario y de mostrar los resultados de las peticiones de servicio. En la mayoría de las ocasiones los Clientes son mas fáciles de diseñar que los servidores, y no suelen precisar privilegios especiales del sistema para poder funcionar. En general el programa cliente cumple dos funciones distintas: por un lado gestiona la comunicación con el servidor, solicita un servicio y recibe los datos enviados por aquél. Por otro, maneja la interface con el usuario: presenta los datos en el formato adecuado y brinda las herramientas y comandos necesarios para que el usuario pueda utilizar las prestaciones del servidor de forma sencilla. Servidor: Un Servidor es un programa que espera peticiones de servicio por parte de un cliente. El Servidor recibe la petición del cliente, ejecuta el servicio solicitado y retorna los resultados al cliente. No existe una interacción directa entre el usuario y el servidor, de esto se encarga la aplicación 11

12 cliente. El programa servidor en cambio, sólo tiene que encargarse de transmitir la información de manera eficiente. De esta forma un mismo servidor puede atender a varios clientes al mismo tiempo. Por consiguiente, los Servidores proporcionan un servicio al cliente y devuelven los resultados. En algunos casos existen procesos auxiliares que se encargan de recibir las solicitudes del cliente, verificar la protección, activar un proceso servidor para satisfacer el pedido, recibir su respuesta y enviarla al cliente. Además deben manejar los interbloqueos, la recuperación ante fallas, y otros aspectos afines. Por las razones anteriores la plataforma computacional asociada con los servidores es más poderosa que la de los clientes. Por esta razón se utilizan PCs poderosos, estaciones de trabajo, minicomputadores o sistemas grandes. Por otro lado deben manejar servicios como administración de la red, mensajes, control, administración de la entrada al sistema ( login ), y recuperación. Usualmente en los servidores existe además algún tipo de servicio de bases de datos. Infraestructura de Comunicaciones: Para que los clientes y los servidores puedan comunicarse se requiere una infraestructura de comunicaciones, la cual proporciona los mecanismos básicos de direccionamiento y transporte. La mayoría de los sistemas Cliente/Servidor actuales se basan en redes locales y por lo tanto utilizan protocolos no orientados a conexión, lo cual implica que las aplicaciones deben hacer las verificaciones. La red debe tener características adecuadas de desempeño, confiabilidad, transparencia y administración. En una red de comunicaciones, el cliente es la máquina solicitante y el servidor es la máquina proveedora mediante un software especializado en ambos extremos. Por ejemplo, en un sistema de base de datos basado en redes, la interface de usuario reside en el cliente, y las funciones de almacenamiento y recuperación de datos, en el servidor. 12

13 Privilegios y Complejidad: Debido a que los servidores a menudo tienen la necesidad de acceder a datos, funciones, o puertos que el sistema operativo protege, el software servidor suele precisar de privilegios del sistema especiales para poder realizar la tarea para la cual ha sido creado. Como consecuencia de esto se tiene mucho cuidado para evitar que los privilegios concedidos al servidor sean aprovechados por los clientes para obtener permisos especiales. Por ejemplo, un servidor de objetos que se ejecuta como un programa privilegiado debe contener código para verificar si un cliente dado tiene permiso para acceder a un objeto en concreto. El servidor no puede relegar esta función sobre el sistema operativo, ya que su estado privilegiado le sitúa, en ciertos aspectos concretos, por encima del sistema. Los programas servidores deben contener código que maneje situaciones de: Autenticación : Verificar la identidad del cliente. Autorización : Determinar si un cliente dado posee permisos para acceder al servicio que suministra. Seguridad de datos : Garantizar que la información no es revelada, de manera no intencionada, a clientes sin autorización. Privacidad : Preservar la información de un usuario de accesos no autorizados. Protección : Garantizar que las aplicaciones de red no puedan abusar de los recursos del sistema. Los servidores que realizan un intensivo uso de la potencia del procesador o que manejan grandes volúmenes de información operan más eficientemente si manejan las solicitudes de servicio concurrentemente. La combinación de privilegios especiales y ejecución concurrente, por norma general, hace que los servidores sean más difíciles de diseñar e implementar que los clientes Capas en una Arquitectura Cliente /Servidor En un esquema Cliente/Servidor clásico (Figura 1) existen dos capas, el cliente y el servidor: éste último está ubicado normalmente en otra 13

14 máquina, y suele ser un gestor de base de datos, como DB2, SQL Server, Sybase Adaptive Server, Oracle, aunque también puede ser una base de datos más pequeña, como Paradox, dbase, etc., a los cuales se acceden directamente desde una aplicación cliente. Los mejores gestores de base de datos relacionales proporcionan soporte para implementar en ellos diversas reglas de negocio, mediante el uso de claves primarias, integridad referencial, triggers, etc., mientras que sistemas como dbase y otros apenas proporcionan soporte para reglas de negocio. Figura 1 Arquitectura Cliente /Servidor en dos capas Suponiendo que se tenga la información en un gestor de bases de datos potente, entonces se podrá llevar a cabo la codificación de numerosas validaciones: así, si en la base de datos se crea una regla de integridad referencial que indique que todo pedido pertenece a un cliente, el gestor de base de datos rechazará cualquier intento de almacenar un pedido en el que no se indique al mismo. Cualquier aplicación que acceda a esta base de datos se beneficiará de esta y otras validaciones automáticamente, sin tener que añadir ni una línea de código. Si se utiliza una base de datos menos potente, casi todas las reglas de negocio deberán implementarse dentro de los programas que accedan a la base de datos. Si los programas que acceden a la base de datos son varios, garantizar que en todos ellos se respetan todas las reglas puede llegar a ser muy difícil y engorroso, especialmente si se desarrollan con distintas herramientas. Las bases de datos relacionales son cada vez más potentes, pero no todas las reglas de negocio pueden reflejarse en ellas: por ejemplo, las reglas de flujo son bastante difíciles de implementar dentro de la base de datos, y 14

15 suelen ser las aplicaciones cliente las que controlan que la información siga una ruta válida a través del sistema. El problema se agrava cuando la información del negocio se encuentra en distintas bases de datos, en donde no hay manera de establecer una regla de integridad referencial entre tablas almacenadas en dos bases de datos distintas y correspondientes a distintos gestores de base de datos. De nuevo, la solución al problema es implementar el chequeo en cada aplicación cliente. Por lo tanto es conveniente encontrar la manera de centralizar la gestión de estas reglas en un único lugar, de modo que todo el código necesario no se tenga que duplicar en cada una de las aplicaciones. La solución es crear una aplicación que se encargue de llevar a cabo estas tareas, de modo que todos los clientes pidan o envíen información a la misma, no al gestor de base de datos en el servidor: a éste solo accederá la nueva aplicación, que conforma una nueva capa dentro de un sistema Cliente/Servidor, la capa intermedia o middle-tier (Figura 2), con lo que el sistema pasa de ser un sistema Cliente/Servidor convencional a ser un sistema con tres capas (three-tiered), en la que puede haber varias de estas aplicaciones, llamadas servidores de aplicación, lo que permite distribuir la carga de trabajo. Figura 2 Arquitectura Cliente /Servidor en tres capas (Three-Tiered) Ubicación de las Reglas o la lógica del Negocio : La decisión de dónde ubicar una determinada regla de negocio dentro de una arquitectura Cliente/Servidor en tres capas puede simplificarse mucho 15

16 si se atiende al tipo de regla. Las reglas del modelo de datos especifican los valores válidos para cada campo de cada tabla. Estas reglas deben ser reforzadas en el servidor. Como complemento de esto, sin embargo, se debe implementar estas validaciones también a nivel de cliente, por una simple razón: evitar trabajo y esperas innecesarias a los usuarios. Por lo que respecta a las reglas de relación, el lugar más adecuado para implementarlas es el servidor. La mayor parte de los gestores de base de datos proporcionan integridad referencial y los mecanismos necesarios para implementar fácilmente estas reglas. Además, el hecho de que los datos necesarios para verificar si se respetan las relaciones residan en la misma base de datos hace que las verificaciones sean rápidas, mientras que si el chequeo se hace en el cliente se incrementará el tráfico de red. Las reglas de derivación pueden variar mucho en complejidad. Lo ideal es implementar las reglas de derivación complejas en la capa intermedia para su ejecución en el servidor, posiblemente mediante un procedimiento almacenado, o mediante una sentencia SQL. Por otro lado, las reglas más sencillas pueden también implementarse en la capa intermedia, de modo que se tenga las reglas de cálculo centralizadas en una única aplicación. Las reglas de restricción deben implementarse en el servidor, o en la capa intermedia. Dado que estas reglas contemplan restricciones en los datos que dependen casi siempre de información presente en varias tablas, llevar a cabo el control en el cliente puede implicar cierto tráfico de red, por lo que es más conveniente situar la implementación de la regla más cerca de los datos. Por último, quedan las reglas de flujo: estas reglas son excelentes candidatas a ser implementadas en la capa intermedia, dado que su complejidad suele ser bastante grande, lo que las hace inmanejables por un gestor de bases de datos. 16

17 Figura 3 Ubicación de las reglas de negocio dentro del esquema de tres capas Sistemas Cliente/Servidor en tres Capas: Un Sistema Cliente/Servidor en tres capas representa un Sistema Distribuido en el que se han separado los distintos servicios que componen el sistema. La división que normalmente se sigue para estos sistemas es la definición de tres capas lógicas (que posteriormente se convertirán en diferentes capas físicas) de la siguiente manera: En la capa más inferior se encuentra la capa de datos, en esta capa se ubican las diferentes bases de datos de las que la aplicación obtendrá y añadirá datos, en ésta capa también se encuentran los procedimientos almacenados que ayudan a simplificar los accesos, modificaciones e inserciones sobre los datos. La siguiente capa contiene las reglas o la lógica de negocios, en esta capa se definen los componentes (entendiéndose por componente un conjunto de clases que hacen algo) que contienen la definición de las operaciones que son necesarias para que el sistema haga su trabajo, además en dichos componentes residen las operaciones que manejan los datos de la capa inferior. En éstos componentes están las reglas que dicen como utilizar los datos y mantienen la integridad de los mismos. Por otro lado la capa de negocios oculta una posible distribución física de los datos. Por último está la capa de presentación, ésta capa se encarga únicamente de presentar los datos a los usuarios y de establecer la interface para que 17

18 exista una comunicación entre los mismos usuarios y el sistema. Esta capa carece de procesamiento y se limita únicamente a mostrar los datos a los usuarios y comprobar que las peticiones de los mismos son, por lo menos, semánticamente, correctas y de esta manera evitar que se hagan peticiones a la capa de negocio que a priori son inviables debido a que incumplen algún requisito previo. En éste sentido, un sistema cliente/servidor en tres capas establece, al menos, tres capas donde los usuarios no tienen constancia sobre como se almacenan ni donde residen los datos, estos sólo se comunican con la capa de presentación, ésta se ocupa de procesar las peticiones de los usuarios y transmitirlas a los componentes de la capa de negocios, en esta capa se procesará la petición modificando, pidiendo o consultando los datos necesarios, que son provistos por la capa de datos que además de proveer dichos datos a la capa superior se encarga de almacenarlos y mantenerlos correctamente. IV. Lenguaje Unificado de Modelado (UML) El Lenguaje Unificado de Modelado es un lenguaje estándar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. UML es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones distribuidas basadas en la web. Es un lenguaje de modelado que proporciona un vocabulario y reglas para su uso en la representación conceptual y física de un sistema. La decisión de usar actualmente UML como notación para procesos software se debe a que se ha convertido en un estándar de facto que tiene las siguientes características: Permite modelar sistemas utilizando técnicas orientadas a objetos (OO). Cubre la especificación de todas las decisiones de análisis, diseño e implementación, permitiendo la construcción de modelos precisos. Puede conectarse con lenguajes de programación usando Ingeniería directa e inversa (Java, C++, Visual Basic). 18

19 Permite documentar todos los artefactos de un proceso de desarrollo (requisitos, arquitectura, pruebas, versiones, etc.) Cubre las cuestiones relacionadas con el tamaño propias de los sistemas complejos y críticos. Es un lenguaje muy expresivo que cubre todas las vistas necesarias para desarrollar y luego desplegar los sistemas. Existe un equilibrio entre expresividad y simplicidad, pues no es difícil de aprender ni de utilizar. UML es independiente del proceso, aunque para utilizarlo óptimamente debe ser usado en un proceso dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental Modelo Conceptual de UML Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto requiere aprender tres elementos principales: los bloques de construcción de UML, las reglas que dictan cómo se pueden combinar estos bloques básicos y algunos mecanismos comunes que se aplican a través de UML. Bloques de Construcción UML: El vocabulario de UML incluye tres clases de bloques de construcción: Elementos, Relaciones y Diagramas. Los ELEMENTOS son abstracciones de primera clase en un modelo. Hay cuatro tipos de elementos en UML: Elementos estructurales, Elementos de Comportamiento, Elementos de agrupación y Elementos de anotación. Los elementos estructurales, son los nombres de los modelos UML. En su mayoría son las partes estáticas de un modelo, y representan cosas que son conceptuales o materiales. Hay siete tipos de elementos estructurales. 1) Clase: Es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente una clase se representa 19

20 como un rectángulo, que normalmente incluye su nombre, atributos y operaciones. 2) Interfaz : Es una colección de operaciones que especifican un servicio de una clase o componente. Una interfaz puede representar el comportamiento completo de una clase o componente o sólo una parte de ese comportamiento. Gráficamente una interfaz se representa con un círculo junto con su nombre. 3) Colaboración: Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Gráficamente, una colaboración se representa como una elipse de borde discontinuo, incluyendo normalmente sólo su nombre. 4) Caso de Uso: Es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Gráficamente, un caso de uso se representa como una elipse de borde continuo, incluyendo normalmente sólo su nombre. 5) Componente: Es una parte física y reemplazable de un sistema que conforma un conjunto de interfaces y proporciona la implementación de dicho conjunto. Gráficamente, un componente se representa como un rectángulo con pestañas, incluyendo normalmente sólo su nombre. 6) Nodo: Es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que por lo general dispone de algo de memoria y, con frecuencia, capacidad de procesamiento. Gráficamente un nodo se representa como un cubo. Los elementos de comportamiento, son las partes dinámicas de los modelos UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y el espacio. Hay dos tipos principales de elementos de comportamiento. 20

21 1) Interacción: Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos. Gráficamente, un mensaje se muestra como una línea dirigida con el nombre de su operación. 2) Máquina de estados: Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción. Gráficamente, un estado se representa como un rectángulo de esquinas redondeadas, incluyendo su nombre y sus subestados. Los elementos de agrupación, son las partes organizativas de los modelos UML. Estos son las cajas en las que puede descomponerse un modelo. Hay un elemento de agrupación principal, los paquetes. 1) Paquete : Es un mecanismo de propósito general para organizar elementos en grupos. Gráficamente, un paquete se visualiza como una carpeta, incluyendo sólo su nombre y, a veces, su contenido. Los elementos de anotación, son las partes explicativas de los modelos UML. Hay un tipo principal de elemento de anotación llamado nota. 1) Nota : Es simplemente un símbolo para mostrar restricciones y comentarios. Gráficamente, una nota se representa como un rectángulo con una esquina doblada, junto con un comentario textual o gráfico. Las RELACIONES en UML son de cuatro tipos: Dependencia, Asociación, Generalización y Realización. Una dependencia, es una relación semántica entres dos elementos, en la cual un cambio a un elemento puede afectar a la semántica del otro elemento. Gráficamente una dependencia se representa como una línea discontinua, posiblemente dirigida, que incluye a veces una etiqueta. Una asociación, es una relación estructural que describe un conjunto de enlaces. La agregación es un tipo especial de asociación, que representa una relación estructural entre un todo y sus partes. Gráficamente, una asociación se representa como una línea continua dirigida, que a veces 21

22 incluye una etiqueta, y a menudo incluye otros adornos, como la multiplicidad y los nombres del rol. Una generalización, es una relación de especialización/generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). Gráficamente, una relación de generalización se representa como una línea continua con una punta de flecha vacía apuntando al padre. Una realización, es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Gráficamente una relación de realización se representa como una mezcla entre una generalización y una relación de dependencia. Los DIAGRAMAS en UML son la representación gráfica de un conjunto de elementos. En teoría, un diagrama UML puede contener cualquier combinación de elementos y relaciones. En la práctica, sin embargo, sólo surge un pequeño número de combinaciones, las cuales son consistentes con las cinco vistas más útiles que comprenden la arquitectura de un sistema. Por esta razón UML incluye nueve diagramas: Un diagrama de clases, muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Los diagramas de clases cubren la vista de diseño estática de un sistema. Un diagrama de objetos, muestra un conjunto de objetos y sus relaciones. Estos diagramas cubren las vista de diseño estática o la vista de procesos estática de un sistema. Un diagrama de casos de uso, muestra un conjunto de casos de uso y actores relacionados. Los diagramas de casos de uso cubren la vista de casos de uso estática de un sistema. Los diagramas de interacción cubren la vista dinámica de un sistema. Un diagrama de secuencia, es un diagrama de interacción que resalta la ordenación temporal de los mensajes; un diagrama de colaboración, es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes. 22

23 Un diagrama de estados, muestra una máquina de estados, que consta de estados, transiciones, eventos y actividades. Los diagramas de estados cubren la vista dinámica de un sistema. Un diagrama de actividades, es un tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la vista dinámica de un sistema. Un diagrama de componentes, muestra la organización y las dependencias entre un conjunto de componentes. Los diagramas de componentes cubren la vista de implementación estática de un sistema. Un diagrama de despliegue, muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Los diagramas de despliegue cubren la vista de despliegue estática. Reglas de UML: Los bloques de construcción de UML, no pueden simplemente combinarse de cualquier manera. Como cualquier lenguaje, UML tiene un número de reglas que especifican a qué debe parecerse un modelo bien formado. UML tiene reglas semánticas para: Nombres : Cómo llamar a los elementos, relaciones y diagramas. Alcance : El contexto que da un significado específico a un nombre. Visibilidad : Cómo se pueden ver y utilizar esos nombres por otros. Mecanismos Comunes en UML: La construcción de modelos UML se hace más simple y armonioso al ajustarse a un patrón de características comunes. En UML existen cuatro mecanismos comunes: Especificaciones: Proporcionan una base semántica que incluye a todos los elementos de todos los modelos de un sistema. Adornos: Sirven para conferir a los modelos de más semántica, proporcionando a un elemento o modelo más nivel de detalle. Divisiones comunes: Permiten que los modelos se dividan al menos en un par de formas diferentes para facilitar su comprensión. 23

24 Mecanismos de extensibilidad: Sirven para poder representar ciertos matices, incluye a los estereotipos, los valores etiquetados, y las restricciones. Figura 4 Vista General del Modelo Conceptual de UML 4.2. Modelado de la Arquitectura de un Sistema La visualización, especificación, construcción y documentación de un sistema con gran cantidad de software requiere que el sistema sea visto desde varias perspectivas. La arquitectura de un sistema es quizás el artefacto más importante que puede emplearse para manejar estos diferentes puntos de vista y controlar el desarrollo iterativo e incremental de un sistema a lo largo de su ciclo de vida. La arquitectura de un sistema con gran cantidad de software puede describirse mejor a través de cinco vistas interrelacionadas. Cada vista es una proyección de la organización y la estructura del sistema, centrada en un aspecto particular de ese sistema. 24

25 La vista de casos de usos, comprende los casos de uso que describen el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas. La vista de diseño, comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solución. La vista de procesos, comprende los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema. La vista de implementación, comprende los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema físico. La vista de despliegue, contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema. Figura 5 Modelado de la arquitectura de un sistema 25

26 V. Proceso Unificado de Rational (RUP) El Proceso Unificado de Rational es un proceso de ingeniería de software que se adapta especialmente a UML. Proporciona una disciplina metodológica para la asignación de tareas y responsabilidades dentro del desarrollo organizacional. Tiene por objetivo asegurar la producción de software de alta calidad de acuerdo a las necesidades de los usuarios finales dentro de un cronograma y presupuesto predecible. RUP es un producto proceso. Es desarrollado y mantenido por Software Rational y viene integrado con un conjunto de herramientas desarrolladoras de software. RUP es también un proceso armazón (framework) que puede ser adaptado y extendido para satisfacer las necesidades de una organización. Esta metodología captura muchas de las mejores prácticas para desarrollar software modernos, de una forma que sea adecuada a un amplio rango de proyectos y organizaciones Mejores Prácticas para el desarrollo de Software Si las causas de los problemas para el desarrollo de software son tratadas de raíz, no sólo se eliminarán los síntomas, sino también se tendrá una mejor posición para desarrollar y mantener software de calidad de un modo repetible y predecible. La mejor práctica software radica en probar todas los posibles métodos en el desarrollo del mismo, de manera que el equipo de trabajo pueda descubrir la causa que origina los problemas durante el desarrollo de software. Estas son las mejores prácticas no porque se pueda cuantificar las causas de los problemas en forma precisa, sino porque su uso permitirá el éxito de una organización. Las mejores prácticas para el desarrollo de software son las siguientes: Desarrollar software iterativamente. Manejar requerimientos. Usar una arquitectura basada en componentes. Modelar visualmente el software. Verificar continuamente la calidad del software. Controlar los cambios en el software. 26

27 Desarrollo de software iterativo El desarrollo de software iterativo ofrece las siguientes soluciones a las causas de los problemas encontrados en su desarrollo: 1) Hace evidente serios errores de manera fácil durante el ciclo de vida, siendo posible reaccionar a ellos. 2) Esta metodología facilita y estimula el uso de la retroalimentación, de manera que responda a los requerimientos reales del sistema. 3) El equipo de desarrollo es forzado para centrarse en los temas más críticos del proyecto, evitando de esta manera los riesgos reales durante su ciclo de vida. 4) Continuas iteraciones permiten probar un objetivo estimado del estado del proyecto. 5) Las inconsistencias entre requerimientos, diseños, e implementaciones son detectadas fácilmente. 6) La carga de trabajo del equipo, especialmente del equipo de pruebas, es dividida más uniformemente a lo largo del ciclo de vida del proyecto. 7) El equipo de trabajo puede usar enseñanzas aprendidas y por consiguiente puede mejorar el proceso continuamente. 8) Pueden detectarse riesgos en el proyecto, proporcionando la evidencia concreta del estado del proyecto a lo largo de su ciclo de vida. Figura 6 Proceso Iterativo e Incremental de RUP 27

28 Manejo de requerimientos El manejo de requerimientos en un proyecto ofrece las siguientes soluciones a las causas de los problemas durante el desarrollo de software: 1) Una metodología disciplinada que se construye bajo la administración de requerimientos. 2) Las comunicaciones son basadas en requerimientos definidos. 3) Los requerimientos pueden ser priorizados, filtrados, y trazados. 4) Posibilita un objetivo estimado de funcionalidad y rendimiento. 5) Las inconsistencias son detectadas más fácilmente. 6) Con apoyo de la herramienta adecuada, es posible proveer un repositorio para los requerimientos del sistema, atributos, y trazos, con enlaces automáticos a documentos externos. Uso de Arquitectura basada en componentes El uso de una arquitectura basada en componentes ofrece las siguientes soluciones a las causas de los problemas durante el desarrollo de software: 1) Los componentes facilitan la arquitectura elástica. 2) La modularidad permite una clara separación de intereses entre los elementos de un sistema que están sujetas al cambio. 3) El reuso es facilitado para apoyar la estandarización de armazones y poder comercializar los componentes disponibles. 4) Los componentes proveen una base natural para el manejo de configuraciones. 5) Las herramientas de modelamiento visual proveen la automatización para el desarrollo de componentes. Modelado visual del software El modelado visual del software ofrece las siguientes soluciones a las causas de los problemas encontrados en su desarrollo: 1) Los casos de uso especifican comportamientos no ambiguos. 2) Los modelos no ambiguos capturan el diseño del software. 3) La no modularidad y las arquitecturas inflexibles son expuestas. 28

29 4) Los detalles pueden ser ocultados cuando sea necesario. 5) Los diseños no ambiguos revelan sus inconsistencias más rápidamente. 6) Las herramientas de modelado visual proveen soporte a modelamientos basados en UML. 7) La calidad de la aplicación empieza con un buen diseño. Figura 7 Modelamiento de un Sistema desde diversas perspectivas Verificación continua de la calidad del software La verificación continua de la calidad del software ofrece las siguientes soluciones a las causas de los problemas encontrados en su desarrollo: 1) La estimación del estado del proyecto se hace objetiva, y no subjetivamente, porque prueba los resultados, y no los documentos. 2) Esta estimación del objetivo expone inconsistentes requerimientos, diseños e implementaciones. 3) Las pruebas y las verificaciones se enfocan en las áreas de más alto riesgo, aumentando la calidad y efectividad de estas áreas. 4) Los defectos son identificados tempranamente, reduciendo en forma radical el costo de arreglos. 5) Las herramientas de pruebas automatizadas proveen funcionalidad, fiabilidad, y rendimiento. 29

30 Control de los cambios en el software El control de los cambios en el software ofrece las siguientes soluciones a las causas de los problemas encontrados en su desarrollo: 1) El flujo de trabajo de los cambios en los requerimientos es definido y repetible. 2) Las peticiones de cambio facilitan comunicaciones claras. 3) Las áreas de trabajo aisladas reducen la interferencia entre los miembros del equipo que trabajan en paralelo. 4) Los cambios en las proporciones estadísticas proveen una buena métrica para evaluar el estado del proyecto objetivamente. 5) Las áreas de trabajo contienen todos los artefactos, que facilitan la consistencia de un cambio. 6) La propagación de un cambio es tasable y controlada. 7) Los cambios pueden mantener a un sistema robusto y personalizado Estructura del Proceso: Dos dimensiones Figura 8 Arquitectura Global del RUP (Dos dimensiones) La figura 8 muestra la arquitectura global del Rational Unified Process. El proceso tiene dos estructuras, o dos dimensiones: El eje horizontal representa el tiempo y muestra como son desplegados los aspectos del ciclo de vida del proceso. 30

31 El eje vertical representa los flujos de trabajo del proceso central (core process), que agrupa las actividades lógicas por naturaleza. La primera dimensión representa el aspecto dinámico del proceso, tal como es implementado, y es expresado en términos de ciclos, fases, iteraciones e hitos. La segunda dimensión representa el aspecto estático del proceso y sé describe en términos de componentes del proceso, actividades, flujos de trabajo, artefactos y trabajadores. Aspecto Dinámico del RUP Es la dinámica de la organización del proceso a lo largo del tiempo. El ciclo de vida del software está dividido en ciclos y en cada ciclo se trabaja una nueva generación del producto. RUP divide un ciclo de desarrollo en cuatro fases consecutivas: Fase de Iniciación (Inception). Fase de Elaboración (Elaboration). Fase de Construcción (Construction). Fase de Transición (Transition ). Cada fase concluye con un hito o hecho bien definido, que es un punto en el tiempo en donde ciertas decisiones críticas deben hacerse, y por consiguiente en donde se deben haber logrado metas importantes. Fase de Iniciación: Durante la fase de iniciación, se establece los casos de negocio del sistema y se delimita el alcance del proyecto. El resultado de esta fase es: Un documento visión: que es una visión general de los requerimientos centrales del proyecto, características importantes, y restricciones principales. Un modelo de casos de uso inicial (10%-20% completo). Un glosario inicial del proyecto (opcionalmente puede expresar en forma parcial un modelo del dominio). 31

32 Un caso de negocio inicial que incluye el contexto del negocio, criterios de éxito (proyección de réditos, reconocimiento de mercados, etc.) y la proyección financiera. Un plan del proyecto, mostrando fases e iteraciones. Un modelo de negocio, si es necesario. Uno o varios prototipos. Al final de la fase de iniciación está el primer hito principal del proyecto: Objetivos del ciclo de vida. El proyecto puede ser cancelado o repensado considerablemente si falla al pasar el hito. Entre los principales criterios de evaluación para la fase de iniciación tenemos: Requerimientos entendidos como evidencias fidedignas de los casos de uso primarios. Profundidad y amplitud de cualquier prototipo arquitectónico desarrollado. Fase de Elaboración: El propósito de la fase de elaboración es analizar el dominio del problema, estableciendo un convincente fundamento arquitectónico; además se desarrolla el plan del proyecto. El resultado de la fase de la elaboración es: Un modelo de casos de uso (por lo menos 80% completo), en donde se han identificado todos los casos de uso y actores, y se han desarrollado la mayoría de descripciones de casos de uso. Requerimientos suplementarios que capturan los requerimientos no funcionales y cualquier requerimiento que no está asociado con un caso de uso específico. Una descripción de la Arquitectura del Software. Un prototipo arquitectónico ejecutable. Una lista de casos de negocio revisados. Un plan de desarrollo para el proyecto global, mostrando las iteraciones y el criterio de evaluación para cada iteración. Un caso de desarrollo actualizado especificando el proceso a ser usado. 32