O-O y RUP - prof.usb.ve. - Universidad Simón Bolívar

UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
SISTEMAS DE INFORMACIÓN II
TEORÍ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)
Material diseñado y elaborado por:
Prof. Luis Eduardo Mendoza M.
Material revisado por:
Prof. María A. Pérez de Ovalles
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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)
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
claramente los requerimientos del problema.
para
entender
• 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.
SISTEMAS DE INFORMACIÓN II
1/4
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
2/4
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
4/4
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
LA CALIDAD EN LOS SISTEMAS O-O
• Reusabilidad
• Extensibilidad-Mantenibilidad
• Compatibilidad-Interoperabilidad
• Verificabilidad
• Integridad
• Entendibilidad
• Facilidad de uso
• Portabilidad
• Correctitud
• Eficiencia
• Confiabilidad
• Robustez
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
• 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.
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
UNIFIED MODELING LANGUAGE (UML)
RELACIONES
•Dependencia
•Asociación
•Generalización
DIAGRAMAS
UML
ELEMENTOS
ESTRUCTURALES
•Casos de Uso
•Clases
•Componente
•Nodo
SISTEMAS DE INFORMACIÓN II
COMPORTAMIENTO
•Interacción
•Máquinas de estado
•Casos de Uso
•Clases
•Secuencia
•Colaboración
•Estados
•Actividad
•Despliegue
AGRUPACIÓN
•Paquete
•Subsistema
•Framework
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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
desarrollar, diseñar y validar una arquitectura;
para
• 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.
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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)
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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.
SISTEMAS DE INFORMACIÓN II
TEORÍA
UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
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)
SISTEMAS DE INFORMACIÓN II
TEORÍA