SISTEMAS DE INFORMACIÓN II TEORÍA - prof.usb.veprof.usb.ve/lmendoza/Documentos/PS-6116/Teoria...

SISTEMAS DE INFORMACIÓN IITEORÍA

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)

UNIVERSIDAD SIMÓN BOLÍVARDEPARTAMENTO DE PROCESOS Y SISTEMAS

Material diseñado y elaborado por:Prof. Luis Eduardo Mendoza M.Material revisado por:Prof. María A. Pérez de Ovalles

SISTEMAS DE INFORMACIÓN II TEORÍA


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, queinteractú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.



POTENCIALES BENEFICIOS DE LATECNOLOGÍ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)



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.

FASES DEL CICLO DE VIDA DE DESARROLLO O-O

Implementación

Diseño de Objeto

Diseño de Sistema - arquitectura de sistemas

- subsistemas

- estructura de datos- algoritmos- controles

- programación- acceso a las

bases de datos

Análisis

- aplicación- qué



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




• 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




• Para desarrollar el modelo de diseño, se debe identificar y definir las consecuencias que el ambiente de implementación tendrá en eldiseñ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




• 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 deanálisis permanecen en el modelo de diseño pero son replanteadascon 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 deprogramación y/o el DBMS.

4/4



LA CALIDAD EN LOS SISTEMAS O-O

• Reusabilidad• Extensibilidad-Mantenibilidad• Compatibilidad-Interoperabilidad• Verificabilidad• Integridad• Entendibilidad• Facilidad de uso• Portabilidad• Correctitud• Eficiencia• Confiabilidad• Robustez



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. Modifica-

ciones 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 profesio-

nales 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.



UNIFIED MODELING LANGUAGE (UML)

• El Unified Modeling Language -UML- (Lenguaje de ModelaciónUnificado), 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, diagramasde clase, diagramas de estado, diagramas de secuencia y diagramas de colaboración



UNIFIED MODELING LANGUAGE (UML)

UML

ELEMENTOS

ESTRUCTURALES•Casos de Uso•Clases•Componente•Nodo

COMPORTAMIENTO•Interacción•Máquinas de estado

AGRUPACIÓN•Paquete•Subsistema•Framework

RELACIONES•Dependencia•Asociación•Generalización

DIAGRAMAS•Casos de Uso•Clases•Secuencia•Colaboración•Estados•Actividad•Despliegue



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 RationalSoftware 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




• 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




• 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




• 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



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.




• 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)





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.




FASE DE ELABORACIÓNPlanificar 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.




FASE DE CONSTRUCCIÓNConstruir 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.




FASE DE TRANSICIÓNRealizar 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.



RATIONAL UNIFIED PROCESSCONSTRUYENDO SOLUCIONES WEB CON RUP

INTEGRACIÓN DEL PROCESO DE DISEÑO CREATIVO YEL RATIONAL UNIFIED PROCESS (Ward y Kroll, 1999)

SISTEMAS DE INFORMACIÓN II TEORÍA - prof.usb.veprof.usb.ve/lmendoza/Documentos/PS-6116/Teoria...

Documents

Transcript of SISTEMAS DE INFORMACIÓN II TEORÍA - prof.usb.veprof.usb.ve/lmendoza/Documentos/PS-6116/Teoria...