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
Ingeniera de Software I
2012IS1 2 UNCa
Contenido
Orientacin a Objetos
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
2Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 3 UNCa
Introduccin a la
Orientacin a Objetos
Introduccin a la OO y UML
Ingeniera de Software I
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.
3Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 6 UNCa
Conceptos Fundamentales de la
Orientacin a Objetos
4Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
5Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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).
6Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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.
7Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 14 UNCa
Identificacin de los elementos
del Modelo de Objetos
8Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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).
9Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 18 UNCa
Introduccin a
UML
10
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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?
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 24 UNCa
UML y el modelado
13
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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,..)
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 28 UNCa
Presentacin de
UML
15
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 31 UNCa
Bloques Bsicos de Construccin
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 35 UNCa
Relaciones
Dependencias
Asociacionespatrn
empleado
0..1 *
Generalizaciones
Realizacin
Los bloques bsicos de construccin para relaciones de UML son cuatro:
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 44 UNCa
Diagramas de UML
23
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 47 UNCa
Ejemplo - Modelado de una colaboracin. Recibir paquete
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
2012IS1 49 UNCa
Ejemplo Diag. de clases para una BD de una Universidad
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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.
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Ingeniera en Informtica - UNCa
Ingeniera de Software I
Introduccin a la OO y UML
Ingeniera de Software I
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
Introduccin a la OO y UML
Ingeniera de Software I
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
Top Related