SISTEMAS DE INFORMACIÓN II TEORÍA

Transcripción

1 CONTENIDO: PARADIGMA DE LA ORIENTACIÓN A OBJETO - DESARROLLO DE SOFTWARE O-O - POTENCIALES BENEFICIOS DE LA TECNOLOGÍA O-O - ALGUNOS MÉTODOS O-O - CICLO DE VIDA DE DESARROLLO O-O - EL PROCESO DE ANÁLISIS Y DISEÑO O-O - LA CALIDAD EN LOS SISTEMAS O-O - VENTAJAS DE LA ORIENTACIÓN A OBJETOS - UNIFIED MODELING LANGUAGE (UML) - RATIONAL UNIFIED PROCESS (RUP) Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Material revisado por: Prof. María A. Pérez de Ovalles

2 PARADIGMA DE LA ORIENTACIÓN A OBJETO Es una nueva manera de ver y expresar el mundo, de pensar acerca de los problemas para encontrar una representación adecuada a nivel de software. El software es organizado como una colección de unidades atómicas (los OBJETOS) constituidas por datos y funciones, que interactúan entre sí. DESARROLLO DE SOFTWARE O-O Los CONCEPTOS inherentes al dominio de la aplicación son identificados, organizados y comprendidos antes de que los detalles sobre las estructuras de datos y las funciones puedan ser considerados efectivamente. Es un proceso conceptual INDEPENDIENTE del lenguaje de programación hasta que se encuentra en sus etapas finales. Consiste en la construcción y paulatino refinamiento del MODELO DEL DOMINIO DE LA APLICACIÓN para, finalmente, agregarle los detalles de implementación.

3 POTENCIALES BENEFICIOS DE LA TECNOLOGÍA O-O Promueve la reusabilidad. Reduce la complejidad del mantenimiento (extensibilidad y facilidad de cambios). Riqueza semántica. Disminuye la brecha semántica entre la visión interna y la visión externa del sistema. Facilita la construcción de prototipos. ALGUNOS MÉTODOS O-O Diseño Basado en Responsabilidades (Wirfs-Brock et al., 1990) Análisis Orientado a Objeto (Peter Coad y Ed. Yourdon, 1991) Diseño Orientado a Objeto (Peter Coad y Ed. Yourdon, 1991) Diseño Orientado a Objeto (Grady Booch, 1991) Técnica de Modelación Orientada a Objeto: OMT (James Rumbaugh et al., 1991) Ingeniería de Software Orientada a Objeto: OOSE (Ivar Jacobson et al., 1992) Fusión (Derek Coleman et al., 1994) Lenguaje de Modelación Unificado: UML (Rational Corporation, 1996)

4 CICLO DE VIDA DE DESARROLLO O-O El ciclo de vida de desarrollo O-O consiste en el desarrollo progresivo de la representación de objetos a través de tres (3) fases -análisis, diseño e implementación-, similares a las del ciclo de vida de desarrollo simplificado. En contraste con del ciclo de vida tradicional, gráficamente se asemeja más a una cebolla (por capas) que a una cascada. Implementación Diseño de Sistema Análisis - aplicación -qué Diseño de Objeto - arquitectura de sistemas - subsistemas - estructura de datos - algoritmos - controles - programación - acceso a las bases de datos FASES DEL CICLO DE VIDA DE DESARROLLO O-O

5 EL PROCESO DE ANÁLISIS Y DISEÑO O-O En la fase de análisis, el modelo del mundo real de la aplicación es desarrollado mostrando sus propiedades importantes. Los conceptos abstractos de la aplicación dominan y describen QUÉ debe hacer el sistema, más que CÓMO lo va a hacer. El modelo de análisis especifica el comportamiento funcional del sistema, independientemente de los aspectos relativos al ambiente en el que va a ser finalmente implementado. Es necesario tomar el tiempo suficiente para entender claramente los requerimientos del problema. El modelo de análisis captura completamente y con exactitud los requerimientos del sistema. Siempre hay que tener presente que es más fácil y menos costoso hacer cambios o arreglar defectos en el análisis que en las fases siguientes. 1/4

6 EL PROCESO DE ANÁLISIS Y DISEÑO O-O En la fase de diseño O-O, se define cómo el modelo de análisis orientado a la aplicación va a ser realizado en el ambiente de implementación. Jacobson cita tres (3) razones para usar el diseño O-O: (Jacobson et al., 1992) El modelo de análisis no es lo suficientemente formal para ser implementado directamente en un lenguaje de programación. El sistema actual debe ser adaptado al ambiente en cual va a ser implementado. En el modelo de diseño se consideran aspectos como: requerimientos de desempeño, requerimientos de tiempo real y concurrencia, el HW y el SW, el DBMS y el lenguaje de programación a ser utilizado. Los resultados del análisis podrán ser validados usando el diseño O-O. Se podrán verificar si los resultados provenientes del análisis son apropiados para construir el sistema y hacer cualquier cambio que sea necesario al modelo de análisis. 2/4

7 EL PROCESO DE ANÁLISIS Y DISEÑO O-O Para desarrollar el modelo de diseño, se debe identificar y definir las consecuencias que el ambiente de implementación tendrá en el diseño (Jacobson et al., 1992). Todas las decisiones estratégicas de diseño -tales como: cómo el DBMS va a ser incorporado, cómo el proceso de comunicación y el manejo de errores van a ser llevado a cabo, qué componentes de librerías van a ser reusados-, son tomadas. Rumbaugh (Rumbaugh et al., 1991) separa las actividades de diseño en dos: diseño de sistema y diseño de objetos. Como diseñador del sistema, se propone una arquitectura global del sistema que organiza a éste en componentes llamados subsistemas y provee el contexto para tomar las decisiones acerca de la identificación de concurrencia, asignación de subsistemas a procesos y tareas, manejo del acceso a recursos globales, selección de la implementación del control en el software y más. 3/4

8 EL PROCESO DE ANÁLISIS Y DISEÑO O-O Durante el diseño de objeto, se construye el modelo de diseño adicionando los detalles de implementación -tales como la reestructuración de clases para ser eficiente, estructuras internas de datos y algoritmos a ser implementados para cada clase, implementación del control, implementación de asociaciones y empaque en módulos físicos-, al modelo de análisis de acuerdo con la estrategia establecida durante el diseño de sistema. Las clases de objetos del dominio de la aplicación del modelo de análisis permanecen en el modelo de diseño pero son replanteadas con los constructos del dominio de la computación, con una visión que optimiza las medidas importantes de desempeño. En la fase de implementación se usa un lenguaje de programación y/o un DBMS, para implementar el modelo de diseño. Traducir el diseño en código de programación es relativamente directo, dado que el modelo de diseño ya incorpora los matices del lenguaje de programación y/o el DBMS. 4/4

9 LA CALIDAD EN LOS SISTEMAS O-O Reusabilidad Extensibilidad-Mantenibilidad Compatibilidad-Interoperabilidad Verificabilidad Integridad Entendibilidad Facilidad de uso Portabilidad Correctitud Eficiencia Confiabilidad Robustez

10 VENTAJAS DE LA ORIENTACIÓN A OBJETOS Reutilización El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel Confiabilidad Un diseño más rápido Integridad Mantenimiento más sencillo. Modificaciones locales. Ciclo vital dinámico. Modelado más realista. Modelos empresariales inteligentes. Independencia del diseño. Computación Cliente-Servidor. Computación paralela. Eficacia de la máquina. Mejores herramientas CASE. Bibliotecas de clases para las empresas. Estabilidad Se construyen clases cada vez más complejas. Nuevos mercados para el software. Diseño de mayor calidad. Programación mas sencilla. Invención. Esmero durante la construcción Mejor comunicación entre los profesionales de los Sistemas de Información y los empresarios. Especificaciones declarativas y diseño. Interacción. Computación de distribución masiva. Mayor nivel de automatización de las bases de datos. Migración. Bibliotecas de clases para las industrias. La comprensión del sistema es más fácil porque la semántica entre el sistema y la realidad son similares.

11 UNIFIED MODELING LANGUAGE (UML) El Unified Modeling Language -UML- (Lenguaje de Modelación Unificado), es un lenguaje para especificar, visualizar y construir los artefactos de sistemas de software, así como para la modelación del negocio (UML Document Set, 1997) Es la culminación de los esfuerzos de Grady Booch, Ivar Jacobson y James Rumbaugh, quienes definieron un lenguaje de modelación O-O que se espera sea el estándar de la industria en el futuro. El UML construye y unifica las semánticas y notaciones de los métodos Booch (Booch, 1994), OOSE (Jacobson et al., 1992) y OMT (Rumbaugh et al., 1991), así como de otros métodos pioneros. Un desarrollador puede usar los modelos de análisis y/o diseño expresados en UML como medio para comunicarse con expertos del negocio, usuarios y otros. UML permite representar múltiples vistas de un sistema usando una variedad de diagramas como: diagramas de casos de uso, diagramas de clase, diagramas de estado, diagramas de secuencia y diagramas de colaboración

12 UNIFIED MODELING LANGUAGE (UML) RELACIONES Dependencia Asociación Generalización UML ELEMENTOS DIAGRAMAS Casos de Uso Clases Secuencia Colaboración Estados Actividad Despliegue ESTRUCTURALES Casos de Uso Clases Componente Nodo COMPORTAMIENTO Interacción Máquinas de estado AGRUPACIÓN Paquete Subsistema Framework

13 RATIONAL UNIFIED PROCESS ES UN PROCESO DE INGENIERÍA DE SOFTWARE. Provee un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización desarrolladora. ES UN PRODUCTO. Desarrollado y mantenido por Rational Software e integrado a un conjunto de herramientas de desarrollo de software. MEJORES PRACTICAS EN EL DESARROLLO DE SISTEMAS. Desarrollar Software Iterativamente Modelar el software visualmente Gerenciar los Requerimientos Usar arquitecturas basadas en componentes Verificacion continua de la calidad Gerenciar los cambios

14 RATIONAL UNIFIED PROCESS DESARROLLAR SOFTWARE ITERATIVAMENTE. Los malos entendidos se detectan al inicio Facilita el feedback para elicitiar requerimientos El equipo se concentra en lo esencial Evaluaciones continuas dan un estado mas exacto del proyecto Las inconsistencias entre analisis, diseño e implementacion se detectan tempranamente Permite una mejor gerencia de riesgos Se aplican las lecciones aprendidas El cliente ve resultados a corto plazo MODELAR EL SOFTWARE VISUALMENTE. Dsiminuyen la ambiguedad Los detalles no necesarios se ocultan Se identifican arquitecturas no modulares e inflexibles Un grafico dice mas que 1000 palabras

15 RATIONAL UNIFIED PROCESS GERENCIAR LOS REQUERIMIENTOS. Las comunicaciones se basan en requerimientos definidos Los requerimientos se priorizan y filtran Se hace posible una evaluacion de la funcionalidad deseada Las inconsistencias se detectan tempranamente Se puede contar con un repositorio de requerimientos USAR ARQUITECTURAS BASADAS EN COMPONENTES. Conlleva a la modularidad Facilita el uso de frameworks estandards (CORBA, COM, EJB) Contribuye con el control de cambios Existen herramientas que soportan la construccion basada en componentes Arquitecturas libres de errores

16 RATIONAL UNIFIED PROCESS VERIFICACION CONTINUA DE LA CALIDAD. Se hace una evaluacion objetiva del estatus del proyecto Se detecta inconsistencias entre analisis, diseño e implementacion Las pruebas se concentran en los aspectos de mayor riesgo Los defectos se identifican claramente, se reducen los costos de su depuracion GERENCIAR LOS CAMBIOS. Las solicitudes de cambios se logran con buena comunicacion Las tasas de cambios arrojan informacion sobre el desempeño del proceso La propagacion del cambio es controlada Se mantiene una arquitectura robusta

17 RATIONAL UNIFIED PROCESS En resumen, la meta de RUP es: (Kruchten, 1999) asegurar la producción de un software de alta calidad que reúna las necesidades de los usuarios finales dentro de un plan y un presupuesto predecible; proveer un enfoque disciplinado para asignar tareas y responsabilidades dentro del desarrollo del sistema; proveer un camino metódico, sistemático para desarrollar, diseñar y validar una arquitectura; reducir en gran medida el riesgo que representa la construcción de sistemas complejos, porque evoluciona de forma incremental partiendo de sistemas más pequeños en los que ya se tiene confianza.

18 RATIONAL UNIFIED PROCESS El proceso propuesto por RUP posee dos (2) dimensiones: la primera, representa el aspecto dinámico del proceso, y está expresado en términos de ciclos, fases, iteraciones e hitos; la segunda, representa el aspecto estático, que se describe en términos de componentes, actividades, flujos de trabajo, artefactos, y actores. PROCESO PROPUESTO POR RUP. (Kruchten, 1999)

19 RATIONAL UNIFIED PROCESS FASE DE INICIO (INSPECCIÓN, CONCEPCIÓN) La idea, la visión del producto, como se enmarca en el negocio, el alcance del proyecto. Artefactos: Un documento con la visión del proyecto. El modelo de Casos de Uso con una lista de todos los Casos de Uso y los actores que puedan ser identificados. Un glosario inicial del proyecto. Un Caso de Uso inicial de Negocio el cual incluye: contexto del negocio, criterios de éxito y planificación financiera. Un estudio inicial de riesgos. Un plan del proyecto que muestre las fases y las iteraciones. Piedra de milla: Objetivo del Ciclo de Vida.

20 RATIONAL UNIFIED PROCESS FASE DE ELABORACIÓN Planificar las actividades necesarias y los recursos requeridos, especificando las características y el diseño de la arquitectura. Artefactos: Un modelo de Casos de Uso (completo en al menos un 80%), con todos los actores identificados y la mayor parte de las descripciones de Casos de Uso. Requerimientos adicionales: los no funcionales o no asociados con ningún caso de uso. Descripción de la arquitectura del software. Prototipo ejecutable de arquitectura. Una lista revisada de riesgos. Plan del proyecto, incluyendo iteraciones y criterios de evaluación para cada iteración. Manual preliminar de usuario. Piedra de milla: Arquitectura del Ciclo de Vida.

21 RATIONAL UNIFIED PROCESS FASE DE CONSTRUCCIÓN Construir el producto, la arquitectura y los planes, hasta que el producto está listo para ser enviado a la comunidad de usuarios. Artefactos El producto de software integrado sobre la plataforma adecuada. Los manuales de usuario. Una descripción de la versión actual. Piedra de milla: Capacidad operativa inicial.

22 RATIONAL UNIFIED PROCESS FASE DE TRANSICIÓN Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y mantenimiento del producto, hasta que el cliente esté satisfecho. Actividades esenciales Ajustes, incluyendo corrección de errores y mejoramiento para desempeño y usabilidad. Empaque, envío, producción, venta y entrenamiento personal. Piedra de milla: Versión de Producto.

23 RATIONAL UNIFIED PROCESS CONSTRUYENDO SOLUCIONES WEB CON RUP INTEGRACIÓN DEL PROCESO DE DISEÑO CREATIVO Y EL RATIONAL UNIFIED PROCESS (Ward y Kroll, 1999)