Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
A partir del ao 1994, Grady Booch (precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa comn, Rational Software
Corporation, y comienzan a unificar sus dos mtodos. Un ao ms tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versin del UML. A finales de ese mismo ao, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se aade al grupo. Como objetivos principales de la consecucin de un nuevo mtodo que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente: El mtodo deba ser capaz de modelar no slo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientacin a objetos (OO). Crear un lenguaje para modelado utilizable a la vez por mquinas y por personas. Establecer un acoplamiento explcito de los conceptos y los artefactos ejecutables. Manejar los problemas tpicos de los sistemas complejos de misin crtica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los mtodos ms utilizados sigan evolucionando en conjunto y no por separado. Y adems, unificar las perspectivas entre diferentes tipos de sistemas (no slo software, sino tambin en el mbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de anlisis, el diseo, la implementacin y los conceptos internos de la OO.
Pgina 1
Modelado de objetos
En la especificacin del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal y este se define como el lenguaje para expresar otros modelos. Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no slo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, adems, define un lenguaje con el que podemos abstraer cualquier tipo de modelo.
El UML es una tcnica de modelado de objetos y como tal supone una abstraccin de un sistema para llegar a construirlo en trminos concretos. El modelado no es ms que la construccin de un modelo a partir de una especificacin.
Pgina 2
La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura esttica; el modelo dinmico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construccin de modelos, se consigue una abstraccin de la realidad que tiene en s misma informacin sobre las principales caractersticas de sta.
Los modelos adems, al no ser una representacin que incluya todos los detalles de los originales, permiten probar ms fcilmente los sistemas que modelan y determinar los errores. Segn se indica en la Metodologa OMT (Rumbaugh), los modelos permiten una mejor comunicacin con el cliente por distintas razones:
Es posible ensear al cliente una posible aproximacin de lo que ser el producto final. Proporcionan una primera aproximacin al problema que permite visualizar cmo quedar el resultado. Reducen la complejidad del original en subconjuntos que son fcilmente tratables por separado.
Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programacin que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificacin total con detalles que no son importantes para el algoritmo que estn implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del
Pgina 3
UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creacin del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informtico o no, mediante los diagramas, es decir, mediante representaciones grficas que contienen toda la informacin relevante del sistema. Un diagrama es una representacin grfica de una coleccin de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vrtices son las relaciones entre los objetos y los vrtices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja d forma que se resaltan los detalles necesarios para entender el sistema.
Se necesita ms de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas grficos para obtener estos distintos puntos de vista de un sistema:
Pgina 4
Diagrama de clases.
Se derivan de los diagramas de proceso y mdulos de la metodologa de Booch, aunque presentan algunas modificaciones. Los diagramas de implementacin muestran los aspectos fsicos del sistema. Incluyen la estructura del cdigo fuente y la implementacin, en tiempo de implementacin. Existen dos tipos:
Pgina 5
Diagramas de componentes
Diagrama de componentes: Muestra la dependencia entre los distintos componentes de software, incluyendo componentes de cdigo fuente, binario y ejecutable. Un componente es un fragmento de cdigo software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilacin.
Diagrama de plataformas o despliegues: Muestra la configuracin de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecucin y los objetos que existen en tiempo de ejecucin. En este tipo de diagramas intervienen nodos, asociaciones de comunicacin, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto fsico en tiempo de ejecucin, es decir una mquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formada por otros componentes. Diagramas de interaccin o comportamiento
Pgina 6
Diagrama de secuencia
Diagrama de colaboracion
Diagrama de estado
Diagrama de actividades
Diagrama de Secuencia Muestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboracin, es decir son instancias concretas de una clase que participa en la interaccin. El objeto puede existir slo durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la ejecucin de la interaccin. Un diagrama de secuencia representa una forma de indicar el perodo durante el que un objeto est desarrollando una accin directamente o a travs de un procedimiento.
En este tipo de diagramas aparecen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operacin del objeto destino. Existen distintos tipos de mensajes segn cmo se producen en el tiempo: simples, sncronos, y asncronos. Los diagramas de secuencia permiten indicar cul es el momento en el que se enva o se completa un mensaje mediante el tiempo de transicin, que se especifica en el diagrama.
Diagrama de colaboracin Muestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo
Pgina 7
Un objeto es una instancia de una clase que participa como una interaccin, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.
Un enlace es una instancia de una asociacin que conecta dos objetos de un diagrama de colaboracin. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.
Los diagramas de interaccin indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envo de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envan entre objetos pueden ser de distintos tipos, tambin segn como se producen en el tiempo; existen mensajes simples, sincrnicos, balking, timeout y asncronos. Durante la ejecucin de un diagrama de colaboracin se crean y destruyen objetos y enlaces.
Diagrama de estado Representan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a estmulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una mquina de estados. Un estado en UML es cuando un objeto o una interaccin satisface una condicin, desarrolla alguna accin o se encuentra esperando un evento. Cuando un objeto o una interaccin pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transicin, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Adems una transicin puede ser interna si el
Pgina 8
Diagrama de actividades Son similares a los diagramas de flujo de otras metodologas OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de accin (estados con una accin interna y una o ms transiciones que suceden al finalizar esta accin, o lo que es lo mismo, un paso en la ejecucin de lo que ser un procedimiento) y las transiciones vienen provocadas por la finalizacin de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin de un caso de uso o de un mtodo (que tiene el mismo significado que en cualquier otra metodologa OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema. Diagrama de casos de uso
Pgina 9
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con l; un ejemplo de actor podra ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes:
Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de uso
Diagramas de clases
Pgina 10
Algunos de los elementos que se pueden clasificar como estticos son los siguientes:
Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un nico paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitindose que un paquete contenga otro paquete.
Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, mtodos, relaciones y significado. En UML una clase es una implementacin de un tipo.
Atributo. Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos.
Operacin. Tambin conocido como mtodo, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza.
Las clases pueden tener varios parmetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrn definidos segn sus parmetros formales. Las plantillas pueden tener especificados los valores reales para los
Pgina 11
Relacionando con las clases nos encontramos con el trmino utilidad, que se corresponde con una agrupacin de variables y procedimientos globales en forma de declaracin de clase, tambin puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaracin de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programacin.
Metaclase: Es una clase cuyas instancias son clases. Sirven como depsito para mantener las variables de clase y proporcionan operaciones (mtodo de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos).
Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementacin. Un tipo establece una especificacin de comportamiento para las clases.
Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo.
Las clases se relacionan entre s de distintas formas, que marcan los tipos de relaciones existentes:
Pgina 12
Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o n-arias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociacin (existen otros tipos de roles segn la relacin a la que identifiquen). Indican la informacin ms importante de las asociaciones. Es posible indicar el nmero de instancias de una clase que participan en una relacin mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociacin permiten especificar qu objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociacin que determina los valores que indican cuales son los valores que se asociarn.
Una asociacin se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociacin.
Existe una forma especial de asociacin, la agregacin, que especifica una relacin entre las clases donde el llamado "agregado" indica l todo y el "componente" es una parte del mismo.
Composicin:
Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro tipo de relacin. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composicin, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos.
Pgina 13
Generalizacin:
Cuando se establece una relacin de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber ms de una clase que se comporte como subclase.
Dependencia:
Una relacin de dependencia se establece entre clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente.
Definicin de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensin del modelo.
Responsabilidades. Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones. Tareas y procesos. Distribucin y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA). Patrones/Colaboraciones. Diagramas de actividad (para reingeniera de proceso de negocios) Clara separacin de tipo, clase e instancia. Refinamiento (para manejar relaciones entre niveles de abstraccin).
Sbado 08 de Marzo de 2014 Pgina 14
UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo nico que tendrn en comn con otras organizaciones que utilicen UML sern los tipos de diagramas.
El proceso de desarrollo
UML es un mtodo independiente del proceso. Los procesos de desarrollo deben ser definidos dentro del contexto donde se van a implementar los sistemas.
Herramientas CASE
Rational Rose es la herramienta CASE que comercializan los desarrolladores de UML y que soporta de forma completa la especificacin del UML 1.1. Esta herramienta propone la utilizacin de cuatro tipos de modelo para realizar un diseo del sistema, utilizando una vista esttica y otra dinmica de los modelos del sistema, uno lgico y otro fsico. Permite crear y refinar estas vistas creando de esta forma un modelo completo que representa el dominio del problema y el sistema de software.
Desarrollo Iterativo
Rational Rose utiliza un proceso de desarrollo iterativo controlado (controlled iterative process development), donde el desarrollo se lleva a cabo en una secuencia de iteraciones. Cada iteracin comienza con una primera aproximacin del anlisis, diseo e implementacin para identificar los riesgos del diseo, los cuales se utilizan para conducir la iteracin, primero se identifican los riesgos y despus se prueba la aplicacin para que stos se hagan mnimos. Cuando la implementacin pasa todas las pruebas que se determinan en el proceso, sta se revisa y se aaden los elementos modificados al modelo de anlisis y diseo.
Pgina 15
Trabajo en Grupo
Rose permite que haya varias personas trabajando a la vez en el proceso iterativo controlado, para ello posibilita que cada desarrollador opere en un espacio de trabajo privado que contiene el modelo completo y tenga un control exclusivo sobre la propagacin de los cambios en ese espacio de trabajo.
Tambin es posible descomponer el modelo en unidades controladas e integrarlas con un sistema para realizar el control de proyectos que permite mantener la integridad de dichas unidades.
Generador de Cdigo
Ingeniera Inversa
Rational Rose proporciona mecanismos para realizar la denominada Ingeniera Inversa, es decir, a partir del cdigo de un programa, se puede obtener informacin sobre su diseo.
Pgina 16
Ejemplo:
Introduccin
Se presenta a continuacin un ejemplo sencillo sobre el modelado de un proyecto, basado en la metodologa UML. UML (Lenguaje de Modelado Unificado) es una especificacin de notacin orientada a objetos, el cual se compone de diferentes diagramas, los cuales representan las diferentes etapas del desarrollo del proyecto. El ejemplo de este artculo se centra en el desarrollo de un pequeo aplicativo para administrar proyectos de desarrollo, donde se llevar el control de los avances de sus diferentes etapas. Se han usado varios diagramas, buscando mostrar su uso, ms en la prctica la complejidad del proyecto a desarrollar nos dice cules diagramas usar.
Objetivo
Es una descripcin corta del proyecto, de tal manera que nos d una idea general del mismo. Es importante su claridad, ya que su informacin sirve de origen para algunos de los diagramas junto a otros, ms adelante.
Proyecto: Descripcin:
Administrador de proyectos de desarrollo Herramienta computacional que permite controlar el proceso de desarrollo de aplicaciones. El sistema permite registrar las fases y las actividades de cada fase, as como el tiempo invertido en cada una de stas, y ofrece informes actualizados en lnea sobre el estado de cada proyecto.
Requerimientos
Pgina 17
R1 R2 R3
Almacenamiento R4 Datos por Proyecto: CodProyecto, nombre, fechaInicio, fechaTerminacion, porcentajeAvance y responsable R5 Datos por Etapa: CodEtapa, nombre, porcentajeAvance, pesoPorcentual y responsable R6 Datos por Actividad: codActividad, nombre,
porcentajeAvance, responsable
Pgina 18
R7 R8
Datos por Responsables: CodResponsable, nombre Datos por Reporte de Tiempos: codActividad, fecha, responsable, horas y porcentajeAvance
suma(porcentajeAvance*pesoPorcentual)
Casos de Uso
Este diagrama representa la funcionalidad completa de un sistema (o una clase)
representacin se hace a travs de las relaciones entre los actores (agentes externos) y los casos de uso (acciones) dentro del sistema. Los diagramas de casos de uso definen conjuntos de funcionalidades afines que el
Pgina 19
Descripcin de Casos de Uso Este formato muestra una descripcin para ayudar a comprender los Casos y SubCasos de Uso. Tambin hace referencia a los requerimientos consignados en el documento de Requerimientos, con los cuales tiene relacin. A causa de la limitacin de espacio, solo se muestran algunos a continuacin: Control de Proyectos
Nombre:
ManejoProyectos
Alias:
Actores:
Responsable
Funcin:
Descripcin:
El Responsable puede registrar proyectos nuevos, identificando todas sus caractersticas. El sistema debe validar que el cdigo est disponible. Tambin es posible modificar algunas de sus caractersticas o eliminar un proyecto si an no tiene registro de
Pgina 20
tiempo.
Referencias:
Control de Proyectos
Nombre:
ManejoEtapas
Alias:
Actores:
Responsable
Funcin:
Descripcin:
El responsable puede crear y asociar etapas o fases a cada Proyecto. Puede modificar sus caractersticas, y eliminar etapas que an no tengan registro de tiempo de labores o actividades realizadas.
Pgina 21
Referencias:
Control de Proyectos
Nombre:
ManejoActividades
Alias:
Actores:
Responsable
Funcin:
Descripcin:
El responsable puede crear y asociar actividades a las etapas de cada Proyecto. Puede modificar y eliminar etapas sin movimiento.
Referencias:
Pgina 22
Control de Proyectos
Nombre:
RegistroMovimiento
Alias:
Actores:
Responsable
Funcin:
Descripcin:
El responsable puede registrar el tiempo en horas utilizado en el desarrollo de las actividades del proyecto. El usuario debe registrar el porcentaje de avance de cada actividad, y el sistema debe calcular el avance ponderado por cada etapa y por el proyecto global.
Referencias:
Pgina 23
CalculoAvanceProyecto, CalculoAvanceEtapa.
Control de Proyectos
Nombre:
Responsable
Alias:
Actores:
Responsable
Funcin:
Descripcin:
Permitir el ingreso de nuevos analistas al sistema, modificacin de su nombre, y eliminacin del mismo, solo si no tiene movimiento.
Referencias:
Pgina 24
Control de Proyectos
Nombre:
CalculoAvanceEtapa
Alias:
Actores:
Responsable
Funcin:
Efectuar el clculo del porcentaje de avance por etapa, basado en los tiempos.
Descripcin:
Al registrar los tiempos por actividad, el sistema aplica la frmula para este clculo y actualiza este dato de la etapa a partir de los avances de las actividades correspondientes.
Referencias:
De Casos: RegistroMovimiento.
Pgina 25
Control de Proyectos
Nombre:
CalculoAvanceProyecto
Alias:
Actores:
Responsable
Funcin:
Efectuar el clculo del porcentaje de avance por proyecto, basado en los tiempos.
Descripcin:
Al registrar los tiempos por actividad, el sistema aplica la frmula para este clculo y actualiza este dato del proyecto a partir de los avances de las etapas correspondientes.
Referencias:
De Casos: RegistroMovimiento.
Control de Proyectos
Pgina 26
Nombre:
Informes Proyectos
Alias:
Actores:
Responsable
Funcin:
Descripcin:
Permite obtener un informe para consulta o impresin de uno o varios proyectos con sus etapas y actividades asociados, su avance y sus caractersticas.
Referencias:
De Casos: RegistroMovimiento.
Control de Proyectos
Pgina 27
Nombre:
Informes Responsables
Alias:
Actores:
Responsable
Funcin:
Descripcin:
Permite obtener un informe para consulta o impresin de los Analistas o Responsables de la realizacin de los Proyectos.
Referencias:
De requerimientos: R7.
De Casos: ManejoResponsables.
Control de Proyectos
Nombre:
Informes Movimientos
Alias:
Pgina 28
Actores:
Responsable
Funcin:
Descripcin:
Permite obtener un informe para consulta o impresin de los Movimientos de tiempos registrados a cada una de las actividades de las etapas de los proyectos.
Referencias:
De Casos: RegistroMovimientos.
Pgina 29
Pgina 30
SUBCASOS DE USO
Control de Proyectos
Nombre:
ManejoProyectos, IngresoProyectos
Alias:
Actores:
Responsable
Funcin:
Descripcin:
El Responsable puede registrar Proyectos nuevos, identificando todas sus caractersticas. El sistema debe validar que el cdigo est disponible, y que sea vlido para ser ingresado.
Referencias:
De Casos: RegistroMovimientos.
Pgina 31
Control de Proyectos
Nombre:
ManejoProyectos, ModificacionProyectos
Alias:
Actores:
Responsable
Funcin:
Descripcin:
El Responsable puede modificar las caractersticas de los Proyectos existentes en el sistema. El sistema debe validar que el cdigo exista, que no est terminado, y que solo pueda modificar datos como nombre y duracin del proyecto, ms no el tiempo reportado, ya que ste es resultado del registro de movimientos.
Referencias:
De Casos: RegistroMovimientos.
Pgina 32
Control de Proyectos
Nombre:
ManejoProyectos, EliminacionProyectos
Alias:
Actores:
Responsable
Funcin:
Descripcin:
El Responsable puede eliminarProyectos existentes en el sistema, que no tengan movimientos reportados. En este caso deber eliminar primero ese movimiento primero.
Referencias:
De Casos: RegistroMovimientos.
Pgina 33