IS1-2012-Modelado OO Con UML

1Ingeniera en Informtica - UNCa

Ingeniera de Software I

UNCaIngeniera en Informtica

INGENIERA DE SOFTWARE I

Orientacin a Objetos

Lenguaje Unificado de Modelado

UML

Lic. Carola Flores

Lic. Erika Lobo

2012

Introduccin a la OO y UML


2012IS1 2 UNCa

Contenido


Introduccin a la Orientacin a Objetos

Conceptos Fundamentales

Identificacin de los elementos del Modelo de Objetos

Introduccin a UML

UML y el modelado

Presentacin de UML

Diagramas

Diagrama de Clases

Diagrama de Casos de Uso

Diagramas de Interaccin

Diagrama de Secuencias

Diagrama de Colaboraciones

Bibliografa





2012IS1 3 UNCa

Introduccin a la




2012IS1 4 UNCa

Porque aparece el Paradigma OO

Incremento de la complejidad.

Heterogeneidad de los usuarios.

Creciente necesidad de herramientas potentes, veloces yfciles de usar.

Necesidad de alto estndar de seguridad.

Necesidad por parte de las empresas de la creacin ymodificacin de aplicaciones de manera mas rpidapara mantenerse competitivas en un medio altamentecambiante.

Garantizar la calidad del software y que elmantenimiento de las aplicaciones se pueda realizar enforma rpida y econmica.





2012IS1 5 UNCa

Modelo de Desarrollo OO

Un modelo evolutivo de proceso acoplado con un enfoque que fomenta el ensamblaje (reutilizacin) de componentes es el mejor paradigma para ingeniera del software OO



2012IS1 6 UNCa

Conceptos Fundamentales de la






2012IS1 7 UNCa

Objeto: es una entidad tangible que posee atributos (estado interno) y queexhibe algn comportamiento bien definido.

Un objeto puede ser una cosa tangible y/o visible. De un modo msrefinado, se puede decir que un objeto representa un elemento, unidad oentidad individual e identificable, ya sea real o abstracta, con un papel biendefinido en el dominio del problema.

Clase: es una descripcin generalizada que describe una coleccin de objetossimilares

Al modelar un sistema algunos de los objetos tendrn un comportamientoy estructuras de informacin comunes y se puede agruparlos de acuerdo aellos. Estos objetos tienen el mismo molde o plantilla. Dicho gruporepresenta una clase.

Nombre de Clase

Atributos

Operaciones

Operaciones

Atributos

Representacin de una clase



2012IS1 8 UNCa

Instancia de clase e Interfaz

Cada objeto pertenece a una clase. Un objeto que pertenece a una clasedeterminada se denomina una instancia de esa clase .

Una instancia es un objeto creado a partir de una clase. La clase describe laestructura (comportamiento e informacin) de la instancia, mientras que elestado actual de la instancia u objeto es definido por las operacionesejecutadas en la instancia.

Desde el punto de vista de la programacin se hace una distincin entre lavisin externa y la visin interna de una clase.

La interfaz de una clase se puede dividir en tres partes: Pblica. Una declaracin accesible a todos los clientes. Protegida. Una declaracin accesible slo a la propia clase, sus subclases y sus clases

amigas. Privada. Una declaracin accesible slo a la propia clase y a sus clases amigas.

Operaciones

Atributos

Visin externa : es la interfazde una clase. Esta interfaz secompone de todas lasdeclaraciones de lasoperaciones aplicables ainstancias de esa clase

Visin interna: es laimplementacin de todas lasoperaciones definidas en lainterfaz de la misma





2012IS1 9 UNCa

Atributos y Operaciones o Mtodos

Atributo

Estn asociados a clases y objetos, estos describen la clase o elobjeto de alguna manera, los atributos indican caractersticasestables.

Operaciones o Mtodos

Un objeto encapsula datos (representados por atributos) y los algoritmosque procesan esos datos. Estos algoritmos son llamados Operaciones,Mtodos o Servicios.

Cada una de las operaciones encapsuladas por un objeto proporciona unarepresentacin de uno de los comportamientos del objeto.

Persona

Fecha Nac.

Ape y Nom

Color de ojos

Operaciones



2012IS1 10 UNCa

Encapsulacin, Herencia y Polimorfismo

La metodologa orientada a objetos modela la realidad tomando comoconcepto fundamental al objeto, combinando operaciones y datos en unasola entidad, los valores de los atributos del objeto no pueden manipularsedirectamente, sino a travs del envo de mensajes (encapsulamiento ).

La clasificacin define una jerarqua de clases, donde las superclases(antecesoras) heredan a sus subclases (descendientes) caractersticascomunes (herencia).

Los objetos invocan el comportamiento de otros objetos sin tener en cuentala clase especfica de los mismos (polimorfismo).





2012IS1 11 UNCa

Encapsulacin

Las clases y los objetos derivados de ella encapsulan los datos y lasoperaciones que trabajan sobre estos datos en un nico paquete.Esto proporciona los siguientes beneficios:

Los detalles de implementacin interna de datos y procedimientosestn ocultos al mundo exterior.

Las estructuras de datos y las operaciones que las manipulan estnmezcladas en una entidad sencilla la clase, esto facilita lareutilizacin.

Las interfaces entre objetos encapsulados estn simplificadas. Yaque al objeto emisor de un mensaje no le interesa la estructura dedatos del objeto receptor => bajo acoplamiento.



2012IS1 12 UNCa

Herencia

La herencia es una de las diferencias claves entre sistemasconvencionales y sistemas OO.

Cualquier cambio en los datos u operaciones contenidas dentro deuna superclase es heredado inmediatamente por todas lassubclases. Debido a esto la herencia es un mecanismo mediante elcual los cambios pueden propagarse inmediatamente a travs detodo el sistema.

Es importante tener en cuenta de que la reestructuracin de lajerarqua puede ser difcil y, por esta razn, se usa a veces laanulacin.

Anulacin: los atributos y operaciones se heredan de maneranormal, pero despus son modificados segn las necesidades de lanueva clase.





2012IS1 13 UNCa

Polimorfismo

El polimorfismo es una caracterstica que reduce en gran medida elesfuerzo necesario para extender un sistema OO.

El polimorfismo permite que un nmero de operacionesdiferentes tengan el mismo nombre. Esto reduce el acoplamientoentre objetos, haciendo a cada uno mas independiente.

Se refiere a la capacidad que tiene un determinadocomportamiento de ser comn a varias clases, o de tener distintasinterpretaciones de acuerdo a la clase a que se haga referencia. Elpolimorfismo permite que una misma operacin pueda llevarse acabo de forma diferente en clases diferentes.



2012IS1 14 UNCa

Identificacin de los elementos

del Modelo de Objetos





2012IS1 15 UNCa

Identificacin de Clases y Objetos

Podemos empezar a identificar objetos realizando unanlisis sintctico gramatical en la narrativa delproblema al que se desea dar solucin.

Los objetos se determinan subrayando cada nombre oclusula nominal e introducindola en un tabla simple.

Si se requiere del objeto que implemente una solucin,entonces ste objeto formar parte del espacio desolucin; en caso de que el objeto se necesite solamentepara describir una solucin, este forma parte del espaciodel problema.



2012IS1 16 UNCa

Identificacin de Clases y Objetos (II)

Cmo identificar objetos cuando estudio como resolver un problema?

Los objetos se manifiestan de alguna de estas formas.

Nombre de

ClaseAtributos

Operaciones

Ocurrencias Cosas

Entidades

Externas

Roles

Unidades

Organizativas

Lugares

Estructuras

Se debe utilizar un Analizador Sintctico Gramatical

para detectar objetos potenciales (nombres) y operaciones (verbos).





2012IS1 17 UNCa

Identificacin de Clases y Objetos (III)

Cmo saber si un objeto potencial es un buen candidato para utilizarlo en un sistema OO?

Coad y Yourdon sugieren seis caractersticas de seleccin:

1. Informacin retenida: el objeto potencial ser de utilidad durante el anlisis solamente si lainformacin acerca de el debe recordarse para que el sistema funcione.

2. Servicios necesarios: el objeto potencial debe poseer un conjunto de operaciones identificablesque pueden cambiar de alguna manera el valor de sus atributos.

3. Atributos mltiples: durante el anlisis de requisitos, se debe centrar la atencin en lainformacin principal (un objeto con un solo atributo puede, en efecto, ser til durante eldiseo, pero seguramente ser mejor presentado como un atributo de otro objeto durante laactividad de anlisis)

4. Atributos comunes: puede definirse un conjunto de atributos para el objeto potencial, loscuales son aplicables a todas las ocurrencias del objeto.

5. Operaciones comunes: puede definirse un conjunto de operaciones para el objeto potencial, lascuales son aplicables a todas las ocurrencias del objeto.

6. Requisitos esenciales: entidades externas que aparecen en el espacio del problema y produceno consumen informacin esencial para la produccin de cualquier solucin para el sistema,sern casi siempre definidas como objetos en el modelo de requisitos.

Un objeto potencial debe satisfacer la mayora de estas caractersticas para utilizarlo en el modelo de anlisis.



2012IS1 18 UNCa

Introduccin a

UML

10

Ingeniera en Informtica - UNCa




2012IS1 19 UNCa

Que es UML ?

UML es un lenguaje de modelado, es decir lanotacin (principalmente grfica) de que se valen losmtodos para expresar los diseos.

UML permite a los desarrolladores visualizar losresultados de su trabajo en esquemas y diagramasestandarizados. Es ms que una notacin grfica(sintaxis), especifica adems un significado, es decir,una semntica.

UML no es un mtodo, la mayor parte de los mtodosconsisten, al menos en principio, en un lenguaje y en unproceso para modelar.



2012IS1 20 UNCa

Los mtodos estructurados y funcionales aparecieron directamenteinspirados de la arquitectura de las computadoras. Los mtodos OOaparecen despus como respuesta a la necesidad de unametodologa de desarrollo de software que d soporte a los lenguajesorientados a objetos

A mediados de los noventa existan muchos mtodos de anlisis ydiseo OO.

Mismos conceptos con distinta notacin.

Mucha confusin.

Guerra de los mtodos

En 1994, Booch, Rumbaugh (OMT) y Jacobson (Objectory/OOSE) deciden unificar sus mtodos:

Unified Modeling Language (UML)

Proceso de estandarizacin promovido por el OMG(Object Management Group)

Como surge UML ?

11





2012IS1 21 UNCa

De Introduction to the Unified Modeling Language, Terry

Quatrani, UML,

Los mtodos OO se articulan alrededor de:

Las nociones de clases y asociaciones (JamesRumbaugh),

Divisiones en subsistemas (Grady Booch)

Expresin de los requerimientos a partir delestudio de la interaccin entre usuarios ysistema (los casos de uso de Ivar Jacobson).

Cada autor tena su propio mtodo, no obstantetodos los mtodos eran similares, tenan unagran cantidad de diferencia en cuestionesmenores pero los conceptos bsicos eran losmismos con distintos nombres, lo queprovocaba confusin. Hubo varios intentosinfructuosos pero afortunadamente, a finales de1994 Booch y Rumbaugh decidieron unificar sustrabajos en un mtodo nico, el mtodounificado. Al ao siguiente se uni al grupoJacobson.

Cmo se cre UML?



2012IS1 22 UNCa

UML 1.5Marzo03- OMG adopta UML 1.5

Junio99- OMG adopta UML 1.3 UML 1.3

UML 2.0Diciembre04- OMG adopta UML 2.0

Evolucin de UML

12





2012IS1 23 UNCa

Ventajas de la unificacin

Reunir los puntos fuertes de cada mtodo

Idear nuevas mejoras

Proporcionar estabilidad al mercado

Proyectos basados en un lenguaje maduro

Aparicin de potentes herramientas

Eliminar confusin en los usuarios

Objetivos en el diseo de UML

Modelar sistemas, desde los requisitos hasta los artefactosejecutables, utilizando tcnicas OO.

Cubrir las cuestiones relacionadas con el tamao propias delos sistemas complejos y crticos.

Lenguaje utilizable por las personas y las mquinas

Encontrar equilibrio entre expresividad y simplicidad.



2012IS1 24 UNCa

UML y el modelado

13





2012IS1 25 UNCa

UML y el modelado

UML es una notacin, no es un proceso

Se estn definiendo muchos procesos para UML.

Rational ha ideado RUP, Proceso Unificado deRational.

UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos (modelos) de un sistema que involucra una gran cantidad

de software, desde una perspectiva OO.



2012IS1 26 UNCa

La importancia de modelar

El modelado es una tcnica de ingeniera probada y bien aceptada. Construimosmodelos arquitectnicos para ayudar a los usuarios a visualizar el producto final.

Un modelo puede ser:

1) Estructural, destacando la organizacin del sistema

2) Comportamiento, resaltando su dinmica

Cuatro utilidades u objetivos de los modelos:

Visualizar cmo es o queremos que sea el sistema

Especificar la estructura y comportamiento del sistema

Proporcionan plantillas que guan la construccin del sistema

Documentan las decisiones

Equivalen a los planos de un edificio

Todo modelo puede expresarse a diferentes niveles de detalle y usarse en diferentes momentos del ciclo de vida.

Un modelo es una simplificacin de la realidad

14





2012IS1 27 UNCa

Utilidad del modelado Se facilita la comunicacin entre el equipo al existir un lenguaje

comn.

Se dispone de documentacin que trasciende al proyecto.

Hay estructuras que trascienden lo representable en un lenguajede programacin.

Utilidad de UML Permite especificar todas las decisiones de anlisis, diseo e

implementacin, construyndose modelos precisos, no ambiguos ycompletos.

UML puede conectarse a lenguajes de programacin:

Ingeniera directa e inversa

Permite documentar todos los artefactos de un proceso dedesarrollo (requisitos, arquitectura, pruebas, versiones,..)



2012IS1 28 UNCa

Presentacin de

UML

15





2012IS1 29 UNCa

Visin General

UML es un lenguaje de modelado estndar para escribir planos de software.

Qu es un lenguaje?Un lenguaje proporciona un vocabulario y las reglas para combinar palabras deese vocabulario con el objetivo de posibilitar la comunicacin.

Qu es un lenguaje de Modelado ?Es un lenguaje cuyo vocabulario y reglas se centran en la presentacinconceptual y fsica de un sistema.

UML indica cmo crear y leer modelos bien formados, pero no dicen que modelosse deben crear ni cundo se deberan crear. Esta es la tarea del proceso dedesarrollo de software.

Como se dijo anteriormente UML es un lenguaje para: Visualizar Especificar ConstruirDocumentar

Cmo se organiza UML

UML

Bloques bsicosde construccin

MecanismosComunes

Reglas de uso

Elementos

Relaciones

Diagramas

Estructurales, Comportamiento, Agrupacin (paquetes), Anotacin

(notas, comentarios)

Dependencia, Asociacin (Agregacin), Generalizacin, Realizacin

Clases, Objetos, Casos de Uso, Secuencia, Colaboracin, Actividad,

Statecharts, Componentes, Despliegue

Especifican cmo construir modelos bien formados .

Proporcionan reglas semnticas para: Nombres (a quse puede llamar elementos, relaciones ydiagramas); Alcance (contexto que da significadoespecfico a un nombre); Visibilidad (cmo losnombres pueden ser vistos y usados por otros);Integridad (cmo los elementos se relacionan entres de forma consistente); Ejecucin (significado desimular o ejecutar un modelo dinmico)

Especificaciones, Dicotoma, Adornos (detalles),

Mecanismos de Extensibilidad

16





2012IS1 31 UNCa

Bloques Bsicos de Construccin



2012IS1 32 UNCa

Son los sustantivos de los modelos UML, y representan elementos ya sea conceptuales o fsicos. Partes estticas de un modelo

Elementos Estructurales

ValidarTransaccion

Caso de usoVentana

origentamao

abrir()

cerrar()mover()dibujar()

Clase

IAvisable

IAvisable

Interface

Gestin Pedidos

Colaboracin

Gestor Eventos

suspender()

vaciarCola()

Clase activa

Servidor

NodoComponente

Hola

Mundo.class

17





2012IS1 33 UNCa

Elementos de Comportamiento

Son las partes dinmicas de los modelos UML. Son los verbos de un modelos Representan comportamiento en el tiempo y en el espacio.

Interaccin: Conjunto de mensajes intercambiados entre un conjunto de objetos con un propsito particular.

Mensaje

dibujar

Mquina de estados: Secuencia de estados por las que pasa un objeto durante su vida en respuesta a eventos.

Estado

activado



2012IS1 34 UNCa

Elementos de Agrupacin y Anotacin

Modelo del Negocio

Paquete

Elementos de Agrupacin

Son las partes organizativas de los modelos UMLPaquete: Un paquete incluye un conjunto de elementos de cualquier naturaleza. Su

propsito es organizar elementos en grupos. Tiene una naturaleza conceptual.

Elementos de Anotacin

Son las partes explicativas de los modelos UML.Permiten describir, clarificar hacer observaciones sobre los elementos de un

modelo.Nota

Retorna 0 si no

existe el valor

18





2012IS1 35 UNCa

Relaciones

Dependencias

Asociacionespatrn

empleado

0..1 *

Generalizaciones

Realizacin

Los bloques bsicos de construccin para relaciones de UML son cuatro:



2012IS1 36 UNCa

Relaciones de Dependencia

Relacin semntica entre dos elementos.

Cuando el elemento independiente sufre algn cambio la semntica del elemento dependiente se ve afectada

19





2012IS1 37 UNCa

Relaciones de Asociacin

Relacin estructural entre objetos que describe los enlaces entre ellos , esta relacin no es

muy fuerte ( es decir, no se exige dependencia existencial ni encapsulamiento).

Cada asociacin puede presentar algunos elementos adicionales que dan detalle a la

relacin, como son:

Nombre: describe la naturaleza de la relacinRol: Identificado como un nombres al los finales de la lnea, expresan el rol o tarea quecumple una clase en la asociacin.

Multiplicidad o Cardinalidad: Seala cuantos objetos pueden conectarse a travs de unainstancia de una asociacin. Se anotan en cada extremo de la relacin y stas pueden ser:

- uno o muchos: 1..* (1..n)

- 0 o muchos: 0..* (0..n)

- nmero fijo: m (m denota el nmero).

La composicin y agregacin (relacin todo/parte) es un tipo especial de asociacin.



2012IS1 38 UNCa

Relaciones de Asociacin Composicin

Es una asociacin fuerte, que implica tres cosas:

1 - Dependencia existencial. El elemento dependiente desaparece al destruirse

el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo.

2 - Hay una pertenencia fuerte. Se puede decir que el objeto contenido es

parte constitutiva y vital del que lo contiene

3 - Los objetos contenidos no son compartidos, esto es, no hacen parte del

estado de otro objeto.

20





2012IS1 39 UNCa

Relaciones de Asociacin Agregacin

Existe una relacin de composicin menos fuerte (no se exige dependencia existencial ) que es denotada por una un rombo sin rellenar en uno de los extremos.

Departamento

Empresa

*

1



2012IS1 40 UNCa

Relaciones de Generalizacin

Relacin de especializacin/generalizacin.

La relacin de generalizacin denota una relacin deherencia entre clases. La subclase hereda todos los atributosy mensajes descritos en la superclase.

21





2012IS1 41 UNCa

Relaciones de Realizacin

Es una relacin semntica entre clasificadores.

Estas relaciones se pueden encontrar entre interfaces y las

clases y componentes que las realizan y entre los casos de

uso y las colaboraciones que los realizan.

Grficamente se representa como una lnea discontinua con

una punta de flecha vaca.



2012IS1 42 UNCa

Sugerencias y consejos cuando se modelan

relaciones

Hay que usar dependencias slo cuando la relacin que seest modelando no sea estructural.

Hay que usar generalizacin slo cuando se tenga unarelacin de herencia.

Tener cuidado de no introducir relaciones de generalizacincclicas.

Las jerarquas de herencias no deben ser demasiadoprofundas ni demasiado anchas.

Hay que usar asociaciones principalmente donde existanrelaciones estructurales.

22





2012IS1 43 UNCa

Diagramas de UML

Un diagrama representa una vista resumida de los elementos queconstituyen el sistema, pudiendo contener cualquier combinacin deelementos y relaciones.

Estructurales

Comportamiento

Casos de usoSecuenciaColaboracinEstadosActividades

Diagramas de Clases

Diagramas de Objetos

Diagramas de Componentes

Diagramas de Despliegue

Interaccin

Implementacin

Diagramas

UML



2012IS1 44 UNCa

Diagramas de UML

23





2012IS1 45 UNCa

Descripcin de la Arquitectura

Vista de Diseo

Vista de

Implementacin

Vista de

DespliegueVista de Procesos

Vista de

Casos de Uso

La arquitectura de un sistema con gran cantidad desoftware puede describirse mejor a travs de cinco vistasinterrelacionadas.



2012IS1 46 UNCa

Diagrama de Clases

Muestran las clases del sistema y sus interrelaciones.Grficamente es una coleccin de nodos y arcos.

Contenido Clases Interfaces Colaboraciones Relaciones de dependencia, generalizacin yasociacin.

Usos ComunesSe utiliza para visualizar la vista de diseo esttica de unsistema, esta vista soporta los requisitos funcionales.

Los diagramas de clases se pueden utilizar para modelar:

El vocabulario del sistema Colaboraciones simples Un esquema lgico de base de datos

24





2012IS1 47 UNCa

Ejemplo - Modelado de una colaboracin. Recibir paquete



2012IS1 48 UNCa

Modelado de un esquema lgico de Bases de Datos

Para modelar un esquema lgico de bases de datos se debe:

Identificar aquellas clases persistentes.

Crear un diagrama de clases que las contengan las clases identificadas etiquetndolas como clases persistentes.

Expandir los detalles estructurales de estas clases

Buscar patrones comunes que complican el diseo fsico de bases de datos

Considerar el comportamiento de las clases persistentes expandiendo las operaciones que sean importantes para el acceso a los datos y la integridad de los mismos

Cuando sea posible usar herramientas que ayuden a transformar un diseo lgico en un diseo fsico

25





2012IS1 49 UNCa

Ejemplo Diag. de clases para una BD de una Universidad



2012IS1 50 UNCa

Sugerencias y Consejos

Un diagrama de clases bien estructurado: Se centra en comunicar un aspecto de la vista de diseo esttica de

un sistema. Contiene solo aquellos elementos que son esenciales para

comprender ese aspecto. Proporcionar detalles de forma consistente con el nivel de

abstraccin. Informar al lector sobre la semntica importante.

Consideraciones al dibujar un Diagrama de clases: Nombre que comunique su propsito Distribuir sus elementos para minimizar los cruces de lneas. Organizar los elementos para que los elementos relacionados

semnticamente estn cerca. Aadir notas resaltar caractersticas importantes. Intentar mostrar las relaciones mas importantes.

26





2012IS1 51 UNCa

Diagrama de Casos de Uso

El diagrama de casos de uso representa la forma en como

un Cliente (Actor) opera con el sistema en desarrollo,

adems de la forma, tipo y orden en como los elementos

interactan (operaciones o casos de uso)

Contenido

Los diagramas de Casos de Uso contienen: Actores Casos de Uso Relaciones



2012IS1 52 UNCa

Actores

Un actor representa un conjunto coherente de roles que jueganlos usuarios de los casos de uso al interaccionar con el sistema.

Roles jugados por personas, dispositivos, u otros sistemas.

No forman parte del sistema

Inician la ejecucin de los casos de uso

Un usuario puede jugar diferentes roles.

En la realizacin de un caso de uso pueden intervenir diferentes actores.

Un actor puede intervenir en varios casos de uso.

Identificar casos de uso mediante actores y eventos externos.

Un actor necesita el caso de uso y/o participa en l.

Tipos de Actores: A. Cockburn distingue dos tipos de actores:

Primarios: Requieren al sistema el cumplimiento de un objetivo.

Secundarios: El sistema necesita de ellos para satisfacer un objetivo

27





2012IS1 53 UNCa

Casos de Uso

Un caso de uso especifica una secuencia de acciones, incluyendovariantes, que el sistema puede ejecutar y que produce un resultadoobservable de valor para un particular actor

Un caso de uso especifica el comportamiento deseado del sistema.

Representan los requisitos funcionales del sistema.

Describen qu hace el sistema, no cmo lo hace.

Propiedades de los Casos de Uso

Son iniciados por un actor con un objetivo en mente y escompletado con xito cuando el sistema lo satisface

Puede incluir secuencias alternativas que llevan al xito y fracasoen la consecucin del objetivo.

El sistema es considerado como una caja negra y lasinteracciones se perciben desde fuera.

El conjunto completo de casos de uso especifica todas las posiblesformas de usar el sistema, esto es el comportamiento requerido.



2012IS1 54 UNCa

Encontrar los casos de uso

Es til encontrar primero los actores

Gua til: primero buscar los objetivos del usuario, y luego cubrir cadaobjetivo con interacciones del sistema. Ejemplo:

Objetivos del usuario: formatear un documento

Interacciones del sistema: definir un estilo, mover un estilo a otrodoc.

Escenarios y Casos de Uso Un caso de uso describe un conjunto de secuencias de interacciones o

escenarios: flujo principal y flujos alternativos o excepcionales.

Un escenario es una instancia de un caso de uso.

Especificacin con diagramas de secuencia.

Procesar PrstamoResponsablePrestamos

actor caso de uso

asociacin

28





2012IS1 55 UNCa

Relaciones

Asociacin

Dependencia o Instanciacin

Generalizacin

Un CU/clase hereda el comportamiento y significado de otro

Inclusin o Uso

Un CU base incorpora explcitamente el comportamiento de otro

en algn lugar de su secuencia

Extensin

Un CU. base incorpora implcitamente el comportamiento de otro

CU en el lugar especificado indirectamente por este otro CU.

NewUseCase4 NewUseCase5

NewUseCase4 NewUseCase5

Organizar

los casos de uso



2012IS1 56 UNCa

Ejemplo

Comprobar clave

Hacer Pedido

Urgente

Validar Usuario

Hacer Pedido

Examinar retina

Generalizacin

extend

(establecer

prioridad)

include

Seguir Pedidoinclude

Relacin de extensin

Relacin deinclusin

29





2012IS1 57 UNCa

Relacin de inclusin Permite factorizar un comportamiento en un caso de uso aparte y

evitar repetir un mismo flujo en diferentes casos de uso.

Ejemplo caso de uso Seguir Pedido:

Obtener y verificar el nmero de pedido. Include (Validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario.

Relacin de extensin El caso de uso base incluye una serie de puntos de extensin.

Sirve para modelar

la parte opcional del sistema

un subflujo que slo se ejecuta bajo ciertas condiciones

varios flujos que se pueden insertar en un punto

Ejemplo caso de uso Hacer Pedido:

Extiende (Hacer Pedido Urgente). Recoger los items delpedido del usuario. (establecer prioridad). Enviar pedido paraser procesado.



2012IS1 58 UNCa

Casos de uso. Ejemplo

Mquina de reciclado de botes, botellas y envases de plstico

Como cada tem tiene precios y dimensiones distintas elsistema debe identificar el tipo de tem que acaba de recibir

El sistema registra el nmero de tems recibidos y, si elcliente pide un recibo, imprime el nmero de tems recibidos,su tipo, los precios parciales y el total que ser devuelto alcliente en la caja, al presentar ese recibo impreso

Un operador puede, al final del da, solicitar un listado detodos los tems recuperados ese da

El operador tambin puede cambiar la informacin delsistema (precios, tipos, etc.)

30





2012IS1 59 UNCa

Casos de uso. Ejemplo

Primero determinar los actores: Usuario y Operador

Despus determinar los objetivos de los actores:

Usuario: puede devolver tems (el CU incluye desde la devolucin de tems a la impresin del recibo)

Operador: puede pedir listado diario o bien modificar informacin de tems

Usuario

Devolver

tems

Listar

diario

Actor Asociacin

Operador

Modif.

tems



2012IS1 60 UNCa

Descripcin de un caso de uso

Describir el flujo de eventos

Texto estructurado informal

Texto estructurado formal (pre y postcondiciones)

Notaciones grficas: Diagramas de Secuencia

Debe ser legible y comprensible para un usuario noexperto.

Debe indicarse: inicio y final, actores, objetos quefluyen, flujo principal y flujos excepcionales.

31





2012IS1 61 UNCa

Ejemplo de Descripcin de un caso de uso

Flujo Principal: Un cliente llega a la Terminal de Punto de Venta (TPV) con unconjunto de artculos. El Cajero registra los artculos y se genera un ticket. El clientepaga en efectivo y recoge los artculos.1. El cliente llega al TPV con los artculos.2. El cajero registra el identificador de cada artculo.3. El sistema obtiene el precio de cada artculo y aade la informacin a la transaccin de

venta.4. Al acabar el cajero indica la finalizacin de la introduccin de artculos.5. El sistema calcula el total de la compra y lo muestra.6. El Cajero le dice al cliente el total.7. El cliente realiza el pago.8. El cajero registra la cantidad de dinero recibida.9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.10. El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega alcliente junto al ticket de compra.11. El sistema almacena la compra completada.12. El cliente recoge los artculos comprados.

Cajero Comprar Artculos Cliente



2012IS1 62 UNCa

Obtencin de casos de uso

1) Identificar los usuarios del sistema.

2) Encontrar todos los roles que juegan los usuarios y que sonrelevantes al sistema.

3) Para cada rol identificar todas las formas (objetivos) de interactuarcon el sistema.

4) Crea un caso de uso por cada objetivo.

5) Estructurar los casos de uso.

6) Revisar y validar con el usuario.

Por qu casos de uso?

Ofrecen un medio sistemtico e intuitivo para capturar los requisitos funcionales, centrndose en el valor aadido para el usuario

Dirigen todo el proceso de desarrollo puesto que la mayora de actividades (planificacin, anlisis, diseo, validacin, test,..) se realizan a partir de los casos de uso.

Mecanismo importante para soportar trazabilidad entre modelos.

32





2012IS1 63 UNCa

Recomendaciones (E. Berard) Un caso de uso no debe considerar cuestiones de implementacin.

Conveniencia de una herramienta para la gestin de los casos de uso.

Encontrar contradicciones entre casos de uso.

Preocupacin por mantener la validez y consistencia del conjunto de casos de uso.

Cmo se comprueba que los casos de uso incluyen toda la funcionalidad del sistema?

Recomendaciones A. Pols Primero establecer los objetivos del proyecto.

Despus identificar actores y sus responsabilidades, y las tareas que ejecutan sonlos casos de uso.

Contrastar casos de uso frente a los objetivos.

Cuidado con la ambigedad

No profundizar en la descripcin de un caso de uso

No te preocupes en exceso de la notacin

Evita redes complicadas de casos de uso: Cuidado con las relaciones include y extend.

No considerar la interfaz del usuario

Los casos de uso slo consideran los requisitos funcionales del proyecto, hay queaadir los no funcionales.



2012IS1 64 UNCa

Diagramas de Interaccin

Una iteracin es un comportamiento que incluye un conjunto de mensajesintercambiados por un conjunto de objetos dentro de un contexto para lograrun propsito.

Cada interaccin puede modelarse de dos formas: Destacando la ordenacin temporal de los mensajes Destacando la secuencia de mensajes en el contexto de una organizacin

estructural de objetos.

Los diagramas de interaccin muestran una interaccin, que consiste en un conjunto de objetos y sus relaciones incluyendo los mensajes que se pueden enviar.

Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de un sistema.

Estos diagramas se clasifican en: Diagramas de secuencia Diagramas de colaboraciones

33





2012IS1 65 UNCa

Contenido

Objetos: que participan en una interaccin, estos puede ser

Elementos concretos

Elementos prototpicos

Enlaces: un enlace es una conexin semntica entre objetos, un enlace es una instancia de una asociacin.

Mensajes: es la especificacin de una comunicacin entre objetos quetransmite informacin, con la expectativa de que se desencadenar unaactividad. La recepcin de una instancia de un mensaje puede considerarseuna instancia de un evento.



2012IS1 66 UNCa

Diagrama de Secuencia

Un diagrama de secuencia es un diagrama de interaccin queresalta la ordenacin temporal de los mensajes, presenta unconjunto de objetos y los mensajes enviados y recibidos por ellos.

Estos diagramas describen la vista dinmica de un sistema.

Contenido

Objetos/Actor

Enlaces

Mensajes A otro objeto Al mismo objeto

34





2012IS1 67 UNCa

Modelado y caractersticas distintivas

Este diagrama tiene dos caractersticas distintivas: La lnea de vida El foco de control

Para modelar un flujo de control por ordenacin temporal se debe:

Establecer el contexto de la interaccin (sistema, subsistema, clase,casos de uso, colaboracin, etc.) identificando qu objetos juegan unrol en ellos.

Los objetos que participan en la interaccin en la parte superior deldiagrama a lo largo del eje X.

Ubicar a la izquierda el objeto que inicia la interaccin y a la derechalos objetos subordinados.

Se colocan los mensajes que estos objetos envan y reciben a lo largodel eje Y, en orden de sucesin en el tiempo desde arriba hacia abajo,proporcionado una vista clara del flujo de control a lo largo deltiempo.



2012IS1 68 UNCa

Ejemplo de Diagrama de Secuencia

: Pasajero : Vendedor

Boletos

: Aerolinea

1: Sol ici tarVuelo( )2: ChequearDisponibilidad( )

3: Reserva Disponible

4: Detal le del vuelo

5: Pref erenciaDeAsiento( )

6: ConsultaDisponibilidadAsiento( )

7: Conf irma Reserv a y Pago

8: PagoBoleto( )9: RegistrarPago( )

10: Boleto

35





2012IS1 69 UNCa

Diagrama de Colaboraciones

ste diagrama muestra la organizacin estructural delos objetos que participan en una interaccin.

Se utilizan para describir la vista dinmica de unsistema, dando una clara visin del flujo de control enel contexto de la organizacin estructural de losobjetos que colaboran.

Contenido

Objetos

Enlaces

Mensajes



2012IS1 70 UNCa

Caractersticas distintivas y Modelado

Los diagramas de colaboracin tienen dos caractersticas que losdistinguen de los diagramas de secuencia:

Camino: es un estereotipo que indica cmo se enlaza un objeto conotro.

Nmero de secuencia: indica la ordenacin temporal de unmensaje, est precedida por un nmero en notacin decimal.

Para modelar un flujo de control por organizacin se debe:

1. Establecer el contexto de la interaccin identificando los objetosque juegan un rol en ella.

2. Establecer las propiedades iniciales de cada objeto.

3. Especificar los enlaces entre los objetos.

4. Asociar cada mensaje al enlace apropiado, estableciendo sunmero de secuencia.

36





2012IS1 71 UNCa

Ejemplo de Diagrama de Colaboracin

: Pasajero

: Vendedor

Boletos

: Aerolinea

1: SolicitarVuelo( )

5: Pref erenciaDeAsiento( )

8: PagoBoleto( )

7: Conf irma Reserv a y Pago

10: Boleto

2: ChequearDisponibilidad( )

6: ConsultaDisponibilidadAsiento( )

9: RegistrarPago( )

3: Reserva Disponible

4: Detalle del v uelo



2012IS1 72 UNCa

FOWLER Martin, SCOTT Kendall UML Gota a Gota - Pearson 1999.

LARMAN, C. UML y Patrones: Una introduccin al anlisis y diseoorientado a objetos y al proceso unificado, Segunda Edicin,Prentice-Hall, 2002.

PILONE, Dan; Neil Pitman UML 2.0 in a Nutshell - O'Reilly 2005.

KIM Hamilton, Russell Miles. Learning UML 2.0 - O'Reilly 2006.

SOMMERVILLE, Ian. Ingeniera Del Software. 7ma Edicin. PearsonEducacin S.A. Madrid, 2005.

Bibliografa

IS1-2012-Modelado OO Con UML

Documents

Transcript of IS1-2012-Modelado OO Con UML