Introducción al análisis y diseño orientado a objetos

Depto de Lenguajes y Sistemas Informáticos. AESI

1

Introducción al análisis y diseño orientado a objetos


2

¿Por qué la Orientación a Objetos?

• Proximidad de los conceptos de modelado respecto de las entidades del mundo real– Mejora captura y validación de requisitos

– Acerca el “espacio del problema” y el “espacio de la solución”

• Modelado integrado de propiedades estáticas y dinámicas del ámbito del problema

• Facilita construcción, mantenimiento y reutilización


3

¿Por qué la Orientación a objetos?

• Conceptos comunes de modelado durante el análisis, diseño e implementación

•Facilita la transición entre distintas fases

•Favorece el desarrollo iterativo del sistema

•Disipa la barrera entre el “qué” y el “cómo”

• Sin embargo, existen problemas ...


4

“...Los conceptos básicos de la OO se conocen desde hace dos décadas, pero su aceptación todavía no está tan extendida como los beneficios que esta tecnología puede sugerir”

“...La mayoría de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretendía. Esta práctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados” --Wolfgang

Strigel

Problemas en OO


5

Introducción• Basado en el concepto de OBJETO• Objeto = unidad atómica que integra estado y

comportamiento• OBJETO = ATRIB. + OPERACIONES• Un objeto puede caracterizar una entidad física (coche) o

concepto (ecuación matemática)• Principios de Ing. del Software

– Abstracción– Ocultamiento de Información– Modularidad

• La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento


6

Objetivos

Productividad Calidad

– minimiz. Errores

– facilidad de uso

– portabilidad

– modificabilidad

• Misma represent. en fases del ciclo de vida


7

Beneficios

• Reusabilidad– Crear nuevos sistemas utilizando los ya existentes

• Extensibilidad– Fácil ampliación sin necesidad de retocar módulos


8

Mitos

• Todos los programas OO son automáticamente reutilizables y extensibles

• La POO rompe con la programación procedural• Un LOO no puede obtenerse como evolución de

uno no OO


9

Conceptos Previos

• Clase:– conj. de objetos que comparten una estructura y

comportamiento comunes

• Metaclase– clase cuyas instancias son a su vez otras clases

• Objeto– entidad abstracta o real con un papel definido en el

dominio de un problema


10

Objetos I

• Zona visible ( métodos )• Zona no visible ( atributos o variables instancia )• Caracteristicas:

– estado: propiedades del objeto. Valores actuales de sus atributos

– comportamiento: expresa cómo se producen los cambios de estado.

– Identidad: identificador unívoco de un objeto


11

Objetos II

• Paso de mensajes– expresa la acción que un objeto realiza sobre otro

• Métodos– operaciones sobre los atributos de un objeto

– tipos de operaciones:– modificadoras

– selectoras

– iteradoras

– constructoras y destructoras


12

Características OO

• Encapsulación• Herencia• Paso de Mensajes• Enlace Dinámico• Polimorfismo


13

Encapsulación

• También llamado abstracción• agrupar bajo una misma entidad los datos y las funciones

(métodos) que trabajan con esos datos

• Efecto– independiza la implementación interna del interface del

objeto


14

Herencia

• Sirve para construir clases a partir de clases ya existentes.

• Las nuevas clases incorporan estructura y comportamiento de la clase de la que heredan

• Superclase/Subclase, Clase Padre/Clase Hija, Clase Base/Clase Derivada


15

Paso de Mensajes

• El único mecanismo para modificar el estado actual de un objeto son sus METODOS o SERVICIOS.

• Los objetos se comunican entre sí mediante el paso de mensajes.

• Consiste en pedir a un objeto que ejecute un servicio.– Objeto_Destino.servicio(parámetros)


16

Enlace Dinámico

• Mecanismo que permite determinar o identificar el trozo de código a ejecutar en un tiempo dado.– T. Compilación: el código a ejecutar se conoce en

tiempo de compilación• averia.clasificar()

– T. Ejecución: el código no se conoce hasta la ejecución del servicio

• documento.salto_de_linea()


17

Polimorfismo

• Mecanismo que permite definir el mismo interface para un conj. de objetos con comportamiento totalmente distinto– figura.area()

– figura = cuadrado, rectángulo, triángulo, círculo.


18

Análisis OO

• Identificar objetos y clases• Diccionario de datos• Identificar asociaciones entre objetos• Identificar atributos y operaciones• Refinar mediante Herencia


19

Identificar clases y objetos

• Tener en cuenta entidades físicas y conceptos• Se suelen corresponder con sustantivos• Agrupar objetos por estructura y comportamiento

común


20

Diccionario de datos

• Describir con precisión cada clase de objetos• También se describirán

– asociaciones

– atributos

– operaciones


21

Identificar asociaciones

• Asociacion = dependencia y/o referencia entre dos o mas clases

• Se suelen corresponder con verbos de estado– acciones dirigidas: “conduce”

– ubicación física: “junto a, contenido en”

– comunicaciones: “habla con”

– propiedad: “tiene, parte de”

– cumpl. de condicion: “trabaja para, casado con”


22

Identificar atributos y operaciones

• Propiedades de los objetos• Se suelen corresponder con nombres seguidos por

frases posesivas– el color del coche

• Operaciones sobre el estado de los atributos• Se suelen corresponder con verbos relacionados

con actividades sobre los atributos– clasificar los partes de avería


23

Refinar mediante Herencia

• Organizar las clases que compartan estructura común.

• Concretizar aspectos comunes en una superclase• Refinar clases existentes en clases especializadas• Pistas: adjetivos relacionados con los nombres de

las clases.


24

Ejercicio “La Biblioteca”

• “Una biblioteca tiene libros que presta a sus socios. Los socios se caracterizan por un código de socio y su nombre. Los libros, por su ISBN, título y autor. Un préstamo relaciona la acción de prestar un libro a un socio en una fecha y tiene un código de préstamo. Cuando un socio devuelve un libro el bibliotecario disminuye su cantidad de libros prestados. Un socio con tres o mas libros prestados es un socio no fiable...”


25

Ejercicio “La Biblioteca”

socio libro

prestamo

socio no fiable

bibliotecario

codSocionombre

ISBNtituloautor

codPrestamofecha

diasDePenalizacion

DNInombre

crearSociodestruirSocio crearLibro

destruirLibro

crearPrestamodestruirPrestamo

hacerSocioNoFiable

despenalizar

crearBibliotecariodestruirBibliotecario


26

UML como lenguaje de análisis y diseño de software


27

Construir la casita del perro

Una persona puede realizarlaRequiere

Mínimo esfuerzo de modeladoProceso simpleHerramientas simples


28

Construir una casa

Un equipo la construye de forma más eficiente y en menos tiempoRequiere

ModeladoProceso bien definidoHerramientas potentes


29

Construir un rascacielos


30

Modelar una casa


31

Sistema Informáticoo

Reglas de Negocio

Item

PedirA

“ Un modelo captura los aspectos

esenciales de un sistema”James Rumbaugh

El modelado visual es la construcción de modelos usando herramientas gráficas estándar.

¿El modelado visual?


32

El Modelado Visual es una Herramienta de Comunicación

El modelado visual se usa para analizar y diseñar una aplicación.

Con él capturamos la lógica del problema


33

El Modelado Visual y la Complejidad de un Sistema


34

Inteefaz Usuario(Visual Basic,

Java)Logica del Problema

(C++, Java)

Sevidor de Bases deDatos

(C++ & SQL)

Modelar el sistema independientemente del lenguaje de programación

Arquitectura del Software


35

El lenguaje de modelado unificado

• UML significa Lenguaje de Modelado Unificado (Unified Modeling Language)

• Un lenguaje de propósito general para el modelado orientado a objetos.

• The UML combina– Conceptos de Modelado de Datos (Entity Relationship Diagrams)– Modelado de Objetos– Modelado de Componentes

• UML es el lenguaje estándar para visualizar, especificar, construir y documentar aplicaciones software.

• Puede ser usado a través de diferentes ciclos de vida y de diferentes tecnologías de implementación.

• Basado en la experiencia y necesidades de los usuarios.


36

Situación de Partida

• Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas notaciones

• Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc.

• Pugna entre distintos enfoques (y correspondientes gurús)

• => Necesidad de una notación estándar


37

Creación de UML

Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9Web - June ´96

publicfeedback

Final submission to OMG, Sep ‘97

First submission to OMG, Jan ´97

UML 1.1OMG Acceptance, Nov 1997

UML 1.3

UML 1.0UML partners


38

Meyer

Before and after conditions

Harel

StatechartsGamma, et al

Frameworks and patterns,

HP Fusion

Operation descriptions and message numbering

Embley

Singleton classes andhigh-level view

Wirfs-Brock

Responsibilities

Odell

Classification

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE

Contribuciones a UML


39

Características de UML

• UML es un lenguaje para– visualizar– specificar– construir– documentar

los artefactos de un sistema software


40

Métodos Formales en Modelado• Tipos de enfoques: no-formales, semi-formales y

formales• Las principales mejoras al utilizar métodos

formales son:– Mayor rigor en la especificación– Mejores condiciones para realizar la verificación y

validación en forma más exhaustiva– Mejores condiciones para automatización de

procesos para la generación automática de prototipos y/o código final


41

Inconvenientes en UML• Definición del proceso de desarrollo usando UML. UML no

es una metodología.

• Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc.

• Ejemplos aislados

• “Monopolio de conceptos, técnicas y métodos entorno a UML


42

Perspectivas de UML• UML será el lenguaje de modelado orientado a

objetos estándar predominante los próximos años• Razones:

– Participación de metodólogos influyentes– Participación de importantes empresas– Aceptación del OMG como notación estándar

• Evidencias:– Herramientas que proveen la notación UML– “Edición” de libros– Congresos, cursos, “camisetas”, etc.


43

Diagramas

• Un diagrama es una vista del modelo– Proporciona una representación parcial del sistema

– Semánticamente consistente con las otras vistas

• En UML, hay 9 tipos de diagramas– vistas de estructura: casos de uso, clases, objetos,

componentes, implantación

– vistas de comportamiento: secuencia, colaboración, estados, actividad


44

Diagramas de UML

Use CaseDiagramsUse Case

DiagramsDiagramas deCasos de Uso

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deImplantación

StateDiagramsState

DiagramsDiagramas deObjetos

ScenarioDiagramsScenario

DiagramsDigramas deEstados

Use CaseDiagramsUse Case

DiagramsDiagramas deSecuencia

StateDiagramsState

DiagramsDiagramas deClases

Diagramas deActividad

Un modelo es una descripción completa de un sistema desdeuna perspectiva particular

Modelos


45

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 límites 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 implementación.

• Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.


46

… Casos de Uso

• Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo.

• Están basado en el lenguaje natural, es decir, es accesible por los usuarios.


47

Ejemplo de Casos de Uso

Caso de Uso: Comprar productos

Actores: Cliente, Cajero

Tipo: Primario

Descripción: Un cliente llega a la caja registradora con los artículos que comprará. El cajero registra los artículos y cobra el importe. Al terminar la operación el cliente se marcha con los productos.

comprar productos


48

… Casos de Uso• Ejemplo:

Sistema

Actor A

Caso de uso X

Actor B

Caso de uso Y


49

… 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 aplicación y deben ser utilizados

– Otros sistemas: sistemas con los que el sistema interactúa• La misma persona física puede interpretar varios papeles

como actores distintos• El nombre del actor describe el papel desempeñado


50

… Casos de Uso• Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, 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


51

Casos de Uso: Relaciones

• UML define cuatro tipos de relación en los Diagramas de Casos de Uso:

– Comunicación:

Caso de Uso

Actor


52

… Casos de Uso: Relaciones

Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

En UML se estereotipa como <<include>>

Caso de uso origen

Caso de uso destino

<<include>>


53


Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

Caso de uso origen

Caso de uso destino

<<extend>>


54


Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía.

Caso de uso origen

Caso de uso destino


55

… Casos de Uso: Relaciones•Ejemplo:

Identificación

Trnasferencia por Internet

Cliente

Transferencia

<<extends>>

<<includes>>


56

Casos de Uso: Construcción• Un caso de uso debe ser simple, inteligible, claro y conciso

• Generalmente hay pocos actores asociados a cada Caso de Uso

• Preguntas clave:•¿cuáles son las tareas del actor?

•¿qué información 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?


57

… Casos de Uso: Construcción• La descripción del Caso de Uso comprende:

– el inicio: cuándo y qué actor lo produce?– el fin: cuándo se produce y qué valor devuelve?– la interacción actor-caso de uso: qué mensajes

intercambian ambos?– objetivo del caso de uso: ¿qué lleva a cabo o intenta?– cronología y origen de las interacciones– repeticiones de comportamiento: ¿qué operaciones son

iteradas?– situaciones opcionales: ¿qué ejecuciones alternativas se

presentan en el caso de uso?


58

RF- <id del requisito> <nombre del requisito funcional> Versión <numero de versión y fecha> Autores <autor> Fuentes <fuente de la versión actual> Objetivos asociados <nombre del objetivo> Descripción El sistema deberá comportarse tal como se describe en

el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}

Precondición <precondición del caso de uso> Paso Acción

1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x>

2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>

3 4 5 6

Secuencia Normal

n Postcondición <postcondición del caso de uso>

Paso Acción 1 Si <condición de excepción>,{el <actor> , el

sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta}

2

Excepciones

3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales>


59

PARTE IIPARTE II

FASE DE ANÁLISIS


60

Contenido

• PARTE II: Fase de Análisis• Modelado de Casos de Uso

• Modelado Estático

• Estructuración en Clases y Objetos

• Diagramas de Transición de Estados

• Modelado Dinámico


61

Modelado de

Casos de Uso


62

Introducción

•Los requisitos funcionales define lo que el sistema hará para el usuario.

•El sistema es visto como una caja negra: •Sólo se consideran las características externas.


63

Los Casos de Uso (cdu)

• Los requisitos funcionales se definen en términos de actores y casos de uso.

• Un actor participa en un caso de uso.

• Un caso de uso define una secuencia de interacciones entre uno o más actores y el sistema.

• El modelo de casos de uso incorpora a actores y casos de uso.


64

Actores• Actor: uno o más usuarios que interactúan con el

sistema.

• Puede ser un dispositivo externo I/O o un timer.

• En sistemas empotrados los actores son sólo

sensores y actuadores.

• Actor Primario y actores Secundarios.

• Actor beneficiario.


65

Actores• El actor es el ser humano aun cuando éste

interactúa mediante dispositivos periféricos.

• Ej. de un actor dispositivo I/O que

interactúa vía un sensor.


66

Actores• Un actor puede ser también un timer que

periódicamente manda eventos al sistema.

• En aplicaciones de tiempo real es aconsejable

tener a los timer como externos al sistema.


67

Actores

• Un sistema externo también puede participar

como actor (primario o secundario) en un

caso de uso.


68

Identificando casos de uso

• Secuencia de eventos iniciada por un actor donde se especifica la interacción entre éste y el sistema.

• No se busca la descomposición funcional del sistema sino secuencias de eventos que proporcionan un resultado a algún actor.


69

Identificando casos de uso

• Por ejemplo, el cliente ATM interactúa con 3 casos de uso que son distintos pues proveen resultados distintos:


70

Documentando casos de uso• Nombre del cdu: único.

• Resumen: una o dos frases.

• Dependencias: de otros casos de uso (opcional).

• Actores: que participan.

• Precondiciones: ciertas antes del cdu.

• Descripción: secuencia de pasos. El sistema es visto como una

caja negra.


71

Documentando casos de uso

• Alternativas: narrativa de las alternativas a la

secuencia principal.

• Postcondiciones: ciertas tras terminar.

• Cuestiones adicionales: planteadas por discusión

con los usuarios reales.

• visto como una caja negra.


72

Ej. Sacar dinero ATM (1/4)• Nombre del cdu: sacar dinero.

• Resumen: El cliente sacar una cantidad específica de dinero

del cajero de su cuenta bancaria.

• Dependencias: ninguna.

• Actores: Cliente ATM.

• Precondiciones: El ATM está listo con el mensaje de

bienvenida.


73

Ej. Sacar dinero ATM (2/4)• Descripción:

1. El cliente inserta la tarjeta en el lector del ATM.2. Si la tarjeta es reconocida se lee el número de la misma.3. El sistema pide la clave al cliente.4. El cliente introduce la clave (PIN).5. El sistema verifica la fecha de caducidad y si es robada o

extraviada.6. Si es válida el sistema comprueba la clave introducida con la

que lleva la tarjeta escrita.7. Si el PIN es válido el sistema ve qué cuentas están disponibles

para dicha tarjeta.8. El sistema muestra las cuentas disponibles y le solicita al cliente

elija entre “sacar dinero”, “consultar saldo” y “transferencia”.


74

Ej. Sacar dinero ATM (3/4)• Descripción:

9. El cliente selecciona “sacar dinero”, introduce la cantidad y selecciona el número de la cuenta.

10. El sistema comprueba si el cliente tiene suficiente dinero en dicha cuenta y si ha sobrepasado el límite diario.

11. Si todo es correcto el sistema autoriza dispensar el dinero.12. El sistema dispensa el dinero.13. El sistema muestra un recibo incluyendo el número de

operación, el tipo, la cantidad y el número de la cuenta.14. El sistema devuelve la tarjeta.15. El sistema muestra su mensaje de bienvenida.


75

Ej. Sacar dinero ATM (4/4)• Alternativas:

– Si el sistema no reconoce la tarjeta entonces es devuelta.

– Si la tarjeta ha caducado es confiscada.

– Si la tarjeta está extraviada o robada es confiscada.

– Si el PIN no es correcto se vuelve a pedir.

– Si se introduce el PIN tres veces mal la tarjeta es confiscada.

– Si el sistema determina que no hay suficiente dinero entonces muestra un

mensaje y devuelve la tarjeta.

– Si el cajero no tiene dinero se muestra un mensaje, se devuelve la tarjeta y se

apaga el cajero.

– Si el cliente introduce “cancelar” se cancela la transacción y se devuelve la

tarjeta.


76

Relaciones entre casos de uso

• Cuando los casos de uso se hacen complejos pueden definirse dependencias entre ellos.

• Vimos se distinguen en UML tres relaciones de dependencia:– Incluye.– Extiende.– Generaliza.


77

Diagrama de casos de uso

• Especifica una interacción entre el usuario y la aplicación para alcanzar un objetivo concreto. Imaginemos un sistema de información para una empresa de alquiler de coches algunos de los casos de uso serían:

– Cliente reserva coche

– Cliente recoge coche

– Cliente entrega coche


78


• Cliente reserva cocheEl cliente contacta con la agencia y hace la petición. La agencia acepta o no la petición según la disponibilidad de coches o el historial del cliente. Caso de aceptación la agencia completa el formulario con los datos relevantes del cliente. Finalmente el cliente paga un depósito para formalizar la reserva.


79


• Cliente recoge cocheCuando el cliente llega a la agencia , ésta localiza el model de coche solicitado. Después de pagar la fianza el cliente recibe el coche para su uso.

• Cliente recoge cocheEl cliente devuelve el coche a la agencia en el día establecido según el contrato de alquiler.


80



81

Arquitectura y UML

Vista de diseño Vista de implementación

Vista de proceso

Componentes Clases, interfaces,colaboraciones

Clases activas

Vista de implantación

Nodos

Vista casos usoCasos de uso


82

Ejemplo del caso de una Máquina Recicladora :

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

•Registrar el número de ítemes ingresados. •Imprimir un recibo cuando el usuario lo solicita:

a.Describe lo depositado b.El valor de cada item c.Total

•El usuario/cliente presiona el botón de comienzo •Existe un operador que desea saber lo siguiente:

a.Cuantos ítemes han sido retornados en el día. b.Al final de cada día el operador solicita un resumen de todo lo depositado en el día.

•El operador debe además poder cambiar: a.Información asociada a ítemes. b.Dar una alarma en el caso de que:

i.Item se atora. ii.No hay más papel.


83

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:


84

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.


85

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.


86

El diseño completo del diagrama Caso de uso es:


87

Ejemplo: casos de uso de un sistema de financiación

Documents

Introducción al análisis y diseño orientado a objetos