You are on page 1of 105

Desarrollo de Software Orientado a Objeto usando UML

Milton Cesar Garca Castiblanco

Introduccin

Todo gira en torno a una visin. Un sistema complejo toma forma cuando alguien tiene la visin de cmo la tecnologa puede mejorar las cosas. El xito de los proyectos de desarrollo de aplicaciones o sistemas se debe a que sirven como enlace entre quien tiene la idea y el desarrollador. El UML (Lenguaje unificado de modelado) es una herramienta que cumple con esta funcin, ya que ayuda a a capturar la idea de un sistema para comunicarla posteriormente a los involucrados en los diferentes procesos.

Claves en desarrollo de SI

Abstraccin - Modelado Visual

Notacin (Visual) - Beneficios

Introduccin al UML

Qu es UML? Por qu es necesario el Uml ? La concepcin del Uml (Historia) Diagramas del UML Para qu tantos diagramas?

Qu es UML?

UML = Unified Modeling Language Un lenguaje de propsito general para el modelado orientado a objetos. Impulsado por el Object Management Group (OMG, www.omg.org) Documento OMG Unified Modeling Language Specification UML combina notaciones provenientes desde:

Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows)

Historia de UML

Comenz como el Mtodo Unificado, con la participacin de Grady Booch y Jim Rumbaugh. Se present en el OOPSLA95 El mismo ao se uni Ivar Jacobson. Los Tres Amigos son socios en la compaa Rational Software. Herramienta CASE Rational Rose

Por qu es necesario el Uml?

Complejidad del mundo de los sistemas informticos Organizar el proceso de diseo de tal forma que los analistas, desarrolladores, clientes y dems interesados en el sistema a desarrolla lo comprendan y convengan con l.

Participantes en UML 1.0


Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson) Digital Equipment Hewlett-Packard i-Logix (David Harel) IBM ICON Computing (Desmond DSouza) Intellicorp and James Martin & co. (James Odell)

MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys

Modelos y Diagramas

Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Diagrama: una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos

... Modelos y Diagramas

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos ...
Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos.

Diagramas de UML

Diagrama de Casos de Uso Diagrama de Clases Diagrama de Objetos Diagramas de Comportamiento


Diagrama de Estados Diagrama de Actividad Diagramas de Interaccin


Diagrama de Secuencia Diagrama de Colaboracin

Diagramas de implementacin

Diagrama de Componentes Diagrama de Despliegue

... Diagramas de UML

Los diagramas expresan grficamente partes de un modelo

Organizacin de Modelos

... Organizacin de Modelos

Propuesta de Rational Unified Process (RUP) M. de Casos de Uso del Negocio (Business UseCase Model) M. de Objetos del Negocio (Business Object Model) M. de Casos de Uso (Use-Case Model) M. de Anlisis (Analysis Model) M. de Diseo (Design Model) M. de Despliegue (Deployment Model) M. de Datos (Data Model) M. de Implementacin (Implementation Model) M. de Pruebas (Test Model)

Diagrama de Casos de Uso

Casos de Uso es una tcnica para capturar informacin respecto de los servicios que un sistema proporciona a su entorno desde el punto de vista del usuario. No pertenece estrictamente al enfoque orientado a objeto, es una tcnica para captura y especificacin de requisitos

Ejemplos

Diagrama de Clases

El Diagrama de Clases es el diagrama principal para el anlisis y diseo del sistema El modelo de casos de uso debera aportar informacin para establecer las clases, objetos, atributos y operaciones (acciones)

Ejemplos

Diagrama de Objetos

Un objeto es una instancia de una clase (una entidad que tiene valores especficos de los atributos y las acciones)

Diagrama de estados

En cualquier momento un objeto se encuentra en un estado en particular

Diagrama de Secuencia

Los diagramas de clases y los de objeto representan informacin esttica. No obstante en un sistema funcional los objetos interactan entre si, y tales interacciones suceden en el tiempo.

Ejemplos

Diagrama de Actividad

Diagrama de Colaboracin

Diagrama Componentes

Diagrama de Despliegue - Distribucin

Paquetes en UML

Los paquetes ofrecen un mecanismo general para la organizacin de los modelos/subsistemas agrupando elementos de modelado Se representan grficamente como:

Paquetes en UML

Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento pertenece a (est definido en) slo un paquete. Una clase de un paquete puede aparecer en otro paquete por la importacin a travs de una relacin de dependencia entre paquetes.

Paquetes en UML

Todos los elementos no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa. El operador ::permite designar una clase definida en un contexto distinto del actual.

TIP

El 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML Grady Booch

Por que tantos diagramas?

Permite examinar un sistema desde diferentes puntos de vista, porque existen diferentes perfiles involucrados los cuales tienen diferentes enfoques particulares.

El Paradigma Orientado a Objeto

Por qu la Orientacin a Objetos?

Proximidad de los conceptos de modelado respecto de las entidades del mundo real

Mejora captura y validacin de requisitos Acerca el espacio del problema y el espacio de la solucin

Modelado integrado de propiedades estticas y dinmicas del mbito del problema

Facilita construccin, mantenimiento y reutilizacin

Por qu la Orientacin a Objetos?

Conceptos comunes de modelado durante el anlisis, diseo e implementacin


Facilita la transicin entre distintas fases Favorece el desarrollo iterativo del sistema Disipa la barrera entre el qu y el cmo

Sin embargo, existen problemas ...

Problemas en OO

...Los conceptos bsicos de la OO se conocen desde hace dos dcadas, pero su aceptacin todava no est tan extendida como los beneficios que esta tecnologa puede sugerir ...La mayora de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretenda. Esta prctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados

Problemas en OO

Un objeto contiene datos y operaciones que operan sobre los datos, pero ... Podemos distinguir dos tipos de objetos degenerados:

Un objeto sin datos (que sera lo mismo que una biblioteca de funciones) Un objeto sin operaciones, con slo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondera con las estructuras de datos tradicionales)

Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos Las aplicaciones de gestin estn constituidas mayoritariamente por objetos degenerados

Fundamentos de Modelado OO

Objetos

Objeto = unidad atmica que encapsula estado y comportamiento La encapsulacin en un objeto permite una alta cohesin y un bajo acoplamiento Un objeto puede caracterizar una entidad fsica (carro) o abstracta (ecuacin matemtica)

Objetos

En UML, un objeto se representa por un rectngulo con un nombre subrayado

Clases y Objetos

Comportamiento

Comportamiento

Los mensajes navegan por los enlaces, a priori en ambas direcciones Estado y comportamiento estn relacionados Ejemplo: no es posible aterrizar un avin si no est volando. Est volando comoconsecuencia de haber despegado del suelo

Persistencia

La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo Podremos despus reconstruirlo, es decir, tomarlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto) Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruya

Comunicacin

Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico. El comportamiento global se basa pues en la comunicacin entre los objetos que la componen.

Comunicacin

Categoras de objetos:

Activos - Pasivos Cliente Servidores, Agentes

Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio. Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitado.

Comunicacin

Los agentes renen las caractersticas de clientes y servidores Son la base del mecanismo de delegacin Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente

Comunicacin

El Concepto de Mensaje

Mensaje y Estmulo

Requisitos del software

Casos de Uso

Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario. Permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno. Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado

Casos de Uso

Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en cuanto a la determinacin de requisitos. Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo. El usuario debera poder entenderlos para realizar su validacin.

Casos de Uso

Casos de Uso

Actores:

Principales: personas que usan el sistema Secundarios: personas que mantienen o administran el sistema. Material externo: dispositivos materiales imprescindibles que forman parte del mbito de la aplicacin y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interacta.

La misma persona fsica puede interpretar varios papeles como actores distintos. El nombre del actor describe el papel desempeado.

Casos de Uso

Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario. Un escenario es una instancia de un caso de uso. Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de uso.

Casos de Uso: Relaciones

UML define cuatro tipos de relacin en los Diagramas de Casos de Uso:

Comunicacin

Casos de Uso: Relaciones

Inclusin : una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino <<include>> reemplaz al denominado <<uses>>

Casos de Uso: Relaciones

Extensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

Casos de Uso: Relaciones

Casos de Uso: Relaciones

Herencia : el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla.

Casos de Uso: Construccin

Un caso de uso debe ser simple, inteligible, claro y Conciso Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave:

cules son las tareas del actor? qu informacin crea, guarda, modifica, destruye o lee el actor? debe el actor notificar al sistema los cambios externos? debe el sistema informar al actor de los cambios internos?

Casos de Uso: Construccin

La descripcin del Caso de Uso comprende:


el inicio: cundo y qu actor lo produce? el fin: cundo se produce y qu valor devuelve? la interaccin actor-caso de uso: qu mensajes intercambian ambos? objetivo del caso de uso: qu lleva a cabo o intenta? cronologa y origen de las interacciones repeticiones de comportamiento: qu operaciones son iteradas? situaciones opcionales: qu ejecuciones alternativas se presentan en el caso de uso?

Interaccin entre objetos

Interaccin

Los objetos interactan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin. Existen dos tipos de diagramas de interaccin: el Diagrama de Colaboracin y el Diagrama de Secuencia

Diagramas de interaccin

El Diagrama de Secuencia es ms adecuados para observar la perspectiva cronolgica de las interacciones. El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos. El D. de Colaboracin puede obtenerse automticamente a partir del correspondiente D. de Secuencia (o viceversa)

Diagrama de Secuencia

Muestra la secuencia de mensajes entre objetos durante un escenario concreto. Cada objeto viene dado por una barra vertical El tiempo transcurre de arriba abajo Cuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblicua.

Diagrama de Secuencia

Diagrama de Colaboracin

Son tiles en la fase exploratoria para identificar objetos. La distribucin de los objetos en el diagrama permite observar adecuadamente la interaccin de un objeto con respecto de los dems. La estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaces.

Clases y relaciones Entre clases

Clasificacin

El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstraccin:

Clasificacin / Instanciacin Composicin / Descomposicin Agrupacin / Individualizacin Especializacin / Generalizacin

La clasificacin es uno de los mecanismos de abstraccin ms utilizados.

Clases

La clase define el mbito de definicin de un conjunto de objetos. Cada objeto pertenece a una clase. Los objetos se crean por instanciacin de las clases.

Clases: Notacin Grfica

Cada clase se representa en un rectngulo con tres compartimientos:


nombre de la clase atributos de la clase operaciones de la clase

Clases: Encapsulacin

La encapsulacin presenta dos ventajas bsicas:


Se protegen los datos de accesos indebidos. El acoplamiento entre las clases se disminuye. Favorece la modularidad y el mantenimiento.

Los atributos de una clase no deberan ser manipulables directamente por el resto de objetos.

Clases: Encapsulacin

Los niveles de encapsulacin estn heredados de los niveles de C++: (-) Privado : es el ms fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminologa C++). (#) Los atributos/operaciones protegidos estn visibles para las clases friends y para las clases derivadas de la original. (+) Los atributos/operaciones pblicos son visibles a otras clases (cuando se trata de atributos se est transgrediendo el principio de encapsulacin).

Clases: Encapsulacin

Relaciones entre Clases

Los enlaces entre objetos pueden representarse entre las respectivas clases Formas de relacin entre clases:

Asociacin y Agregacin (vista como un caso particular de asociacin) Generalizacin/Especializacin

Las relaciones de Agregacin y Generalizacin forman jerarquas de clases

Asociacin

La asociacin expresa una conexin bidireccional entre objetos. Una asociacin es una abstraccin de la relacin existente en los enlaces entre los objetos.

Asociacin

Especificacin de multiplicidad (mnima...mxima)


1 Uno y slo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) * Cero o muchos 0..* Cero o muchos 1..* Uno o muchos (al menos uno)

La multiplicidad mnima >= 1 establece una restriccin de existencia

Asociacin Cualificada

Reduce la multiplicidad del cualificador.

Agregacin

La agregacin representa una relacin parte_de entre objetos En UML se proporciona una escasa caracterizacin de la agregacin Puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes.

Ejemplo

Ejemplos

Generalizacin

Nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre estn disponibles en sus clases hijas

... Generalizacin

Herencia Mltiple

Polimorfismo

Diagrama de Estados

Los Diagramas de Estados representanautmatas de estados finitos, desde el p.d.v. de los estados y las transiciones Son tiles slo para los objetos con un comportamiento significativo El formalismo utilizado proviene de los Statecharts (Harel)

Diagrama de Estados

Cada objeto est en un estado en cierto instante El estado est caracterizado parcialmente por los valores algunos de los atributos del objeto El estado en el que se encuentra un objeto determina su comportamiento Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase Los D. De Estados y escenarios son complementarios

Diagrama de Estados

Los D. de Estados son autmatas jerrquicos que permiten expresar concurrencia, sincronizacin y jerarquas de objetos Los D. de Estados son grafos dirigidos Los D. De Estados de UML son deterministas Los estados inicial y final estn diferenciados del resto La transicin entre estados es instantnea y se debe a la ocurrencia de un evento

Diagrama de Estados

Generalizacin de Estados

Diagrama de Actividad

El Diagrama de Actividad es una especializacin del Diagrama de Estado, organizado respecto de las acciones y usado para especificar:

Un mtodo Un caso de uso Un proceso de negocio (Workflow)

Las actividades se enlazan por transiciones automticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad.

Ejemplo

Diagrama de Componentes

Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable.

...Diagrama de Componentes

Object Constraint Language OCL

OCL es un lenguaje formal usado para describir expresiones acerca de modelos UML OCL es parte del estandar UML y fue desarrollado en IBM Las evaluacin de expresiones OCL no afecta el estado del sistema en ejecucin

Usos de OCL

Lenguaje de consulta Especificacin de invariantes en clases y tipos Especificacin de invariantes de tipo para Estereotipos Describir pre- y post condiciones en Operaciones y Mtodos Describir Guardas Especificar destinatarios para mensages y acciones Especificar restricciones en Operaciones Especificar reglas de derivacin para atributos

Ejemplo

Invariantes
El nmero de empleados debe ser mayor que 50
self.nmeroDeEmpleados > 50 (siendo el contexto Company) context Compaa inv: self. nmeroDeEmpleados > 50 context c:Compaa inv: c.nmeroDeEmpleados > 50 context c:Compaa inv suficientesEmpleados: c.nmeroDeEmpleados > 50

Pre- Post condiciones


Sintaxis context NombreTipo::NombreOperacin(Param1 : Tipo1, ... ):TipoRetorno pre parametroOk: param1 > ... post resultadoOk : result = ... Ejemplo context Persona::nmina(fecha : Date) : Integer post: result = 5000

Valores iniciales y derivados


Sintaxis context NombreTipo::NombreAtributo: Tipo init: - alguna expresin representando el valor inicial context NombreTipo::NombreRolAsociacin: Tipo init: - alguna expresin representando la regla de derivacin Ejemplo context Persona::nmina : Integer init: padres.nmina->sum() * 1% derive: if menorDeEdad then padres.nmina->sum() * 1% else puesto.sueldo endif

Expresiones Let
Ejemplo context Persona inv: let ingresos : Integer = self.puesto.sueldo>sum() in if estEnParo then ingresos < 100 else ingresos >= 100 endif

You might also like