Diseño Orientado a Objetos

Presentación del tema: "Diseño Orientado a Objetos"— Transcripción de la presentación:

1 Diseño Orientado a Objetos
UML Diseño Orientado a Objetos Este Esta presentación, que se recomienda ver en modo de presentación, muestra las nuevas funciones de PowerPoint. Estas diapositivas están diseñadas para ofrecerle excelentes ideas para las presentaciones que creará en PowerPoint 2010. Para obtener más plantillas de muestra, haga clic en la pestaña Archivo y después, en la ficha Nuevo, haga clic en Plantillas de muestra.

2 El Problema! Usted ha sido contratado para desarrollar un sistema para administrar una biblioteca universitaria. La biblioteca actualmente usa un programa de 1960s, escrito en un lenguaje obsoleto, para algunas tareas de préstamo y búsqueda. Usted quiere construir un sistema interactivo que maneja ambas opciones en línea.

3 Definición vaga del sistema
Diferentes usuarios tienen diferentes prioridades Los usuarios no se expresan claramente de que es lo que quieren que el sistema realice Difícil de imaginar trabajar con un sistema del cual se tiene solo una descripción que parece buena pero le falta algo vital. Administradores del sistema no tienen experiencia haciendo las tareas que los usuarios deben realizar.

4 El Problema! Libros y Revistas
La biblioteca almacena libros y revistas. Tiene varias copias de un libro determinado. Algunos libros son para para prestamos de tiempo corto. El resto de libros pueden ser prestados hasta por 3 semanas por cualquier miembro de la Biblioteca. Solo miembros del personal bibliotecario pueden prestar revistas. Miembros de la biblioteca pueden prestar hasta 6 libros a la vez. Miembros del personal bibliotecario pueden prestar hasta 12 libros a la vez. Nuevos libros y revistas llegan regularmente, y los viejos son descartados algunas veces. Las revistas del año son archivadas en un volumen anual al final del año. Préstamo Es necesario que el sistema mantenga la información de cuando libros y revistas son prestados y devueltos, como lo hace el sistema actual. El nuevo sistema debe enviar alertas cuando un libro esta no ha sido devuelto. Como posible futuro requerimiento esta la posibilidad de que se pueda extender el préstamo de un libro, siempre que este no este reservado. Búsqueda Usted quiere construir un sistema interactivo que maneja ambas opciones en línea.

5 Qué es UML UML es una notación que se produjo como resultado de la unificación de la técnica de modela de objetos e ingeniería de software orientada a objetos. UML es un lenguaje de modelamiento estándar que sirve para visualizar, especificar, construir y documentar los artefactos de un sistema orientado a objetos. UML ha sido utilizado en sistemas: Información, Financieros, Telecomunicaciones, Transporte, Defensa/aeroespacio, Electrónica Médica, Científicos, Distribuidos

6 Fases en el desarrollo de sistemas
Análisis del sistema Modelo funcional Representado en UML con diagramas de caso de uso Describe la funcionalidad del sistema desde el punto de vista del usuario. Diseño Modelo de objetos Representado en UML con diagrama de clases Describe la estructura del sistema desde el punto de vista de objetos, atributos, asociaciones y operaciones Modelo dinámico Representado en UML con diagramas de secuencias, estados y actividad. Describe el comportamiento interno del sistema Implementación (programación) Pruebas

7 1 Análisis del sistema Fases en el desarrollo de un sistema

8 Casos de Uso Identificar usuarios del sistema
Si queremos realizar un sistema de calidad, debemos entonces satisfacer las necesidades de sus usuarios. Realizar un análisis del sistema orientado desde el punto de vista de los usuarios Identificar usuarios del sistema Identificar las tareas que deben realizar los usuarios del sistema Identificarlas en orden de importancia

9 Casos de Uso ¿Usuarios? ¿Tareas?
UML utiliza los términos técnicos “Actores” y “Casos de Uso” Actor ó Usuarios Casos de Uso Caso de Uso ó Tareas Actor Es un usuario del sistema en un rol en particular. Puede ser otro sistema que actúa como un usuario para nuestro sistema

10 Actores Un actor es un usuario del sistema en un rol en particular.
Puede ser otro sistema que actúa como un usuario para nuestro sistema

11 Casos de Uso Un caso de uso es una tarea que el actor necesita realizar con ayuda del sistema. Prestar la copia de un libro Devolver un libro Nótese que una frase tan simple como prestar un libro puede implicar una serie de variantes. El detalle de cada caso de uso debe ser documentado en tercera persona. .

12 Casos de Uso Se utilizan durante la obtención de requerimientos y el análisis para representar la funcionalidad del sistema. Se enfocan en el comportamiento del sistema desde un punto de vista externo. Diagrama de caso de uso Describe una función proporcionada por el sistema que produce un resultado visible para un actor. Los casos de uso están dentro de la frontera del sistema.

13 Casos de Uso Prestar copia de libro Una persona presta un libro.
El sistema verifica que la persona sea miembro de la biblioteca, si no lo es no tiene permitido prestar libros, El máximo numero de libros a prestar es 6 si es miembro y 12 si es parte del staff. Si es miembro de la biblioteca o del staff y el libro esta disponible graba exitosamente el préstamo caso contrario lo rechaza. Casos de Uso Actor Es un usuario del sistema en un rol en particular. Puede ser otro sistema que actúa como un usuario para nuestro sistema

14 Casos de Uso

15 Diagrama de Casos de Usos
Actor: Un actor es cualquier entidad que interactúa con el sistema (un usuario, otro sistema, el ambiente físico del sistema). Caso de uso: Describe qué hace el sistema (i.e., funcionalidad) Escenario : secuencia de interacciones entre el usuario y el sistema Relación: Extension (or generalization) entre actores Asociación entre actores y casos de uso Dependencia entre casos de uso: include y extend

16 Especificación de Casos de Uso
Los casos de uso se escriben en lenguaje natural Se describen en tercera persona Permite comunicación entre los desarrolladores, clientes y usuarios Describir cada caso de uso con suficiente detalle para entender la funcionalidad requerida. Registrar en las notas las limitaciones, decisiones de diseño, consideraciones de la interfase con el usuario y políticas de la empresa y roles.

17 Plantilla para especificación de Casos de Uso
Nombre del caso de uso Descripción de caso de uso Notas

18 Especificación de Casos de Uso Escenarios
Un caso de uso es una abstracción que describe todos los escenarios posibles que involucran la funcionalidad que se describe. Un escenario es una instancia de un caso de uso que describe un conjunto de acciones concretas. Ilustrar casos comunes.

19 Especificación de Escenarios de Casos de Uso Plantilla
Caso de Uso: Nombre del caso de uso Escenario: Nombre de escenario Actores participante Suposiciones / Asunciones Suposiciones que definen el contexto en el cual el sistema puede proveer la funcionalidad descrita por el caso de uso. Flujo de acciones Secuencia de acciones del caso del escenario Resultados Los resultados garantizados por el escenario.

20 Especificación de Escenarios de Casos de Uso
Caso de Uso 1: Rentar Vídeo. Escenario 1.1: Socio renta un vídeo exitosamente. Suposiciones/Asunciones: – Socio cancela el dinero del alquiler. – Copia del vídeo de la película requerida está disponible. Flujo: 1. El usuario busca el cliente en el sistema 2. El usuario busca el video que el cliente desea rentar y crear una renta registrando video en la cuenta del cliente. Resultados: – Socio renta el vídeo satisfactoriamente. – Contador de rentas para la película es incrementado.

21 2 Diseño del sistema Modelo de objetos / Modelo dinámico

22 Identificando clases y relaciones
Modelo de objeto

23 Diseño Orientado a Objetos
¿Diagrama de Clases? Diagrama UML para documentar la estructura esta Determina las clases del sistemas Determina las relaciones entre las clases del sistema Diseño Orientado a Objetos Libro Modelo simple de una clase

24 Diagrama de Clases Identificación de clases y objetos
Construir un modelo de clases involucra identificar que clases deben existir en el sistema Que hace bueno a un modelo de clases? Construir tan rápido como barato sea posible Construir un sistema fácil de mantener y que se adapte a futuros requerimientos Cada pieza de funcionalidad requerida por el sistema debe estar disponible para proveerse por un objeto de las clases que se seleccionen

25 Diagrama de Clases Identificación de clases y objetos
Cada pieza de funcionalidad requerida por el sistema debe estar disponible para proveerse por un objeto de las clases que se seleccionen Un buen modelo de clases el mismo representa los objetos del dominio del problema No depende de una funcionalidad en particular requerida hoy en día. Para el ejemplo de la biblioteca es razonable tener una clase llamada Libro. No es razonable una clase llamada B o PapelLiterario.

26 Diagrama de Clases Cómo construir un buen modelo de clases?
Se puede utilizar cualquier técnica para obtener las clases Si su modelo de clases resulta ser malo no importa cual maravilloso sea el método que utilizo El conjunto de clases es una de las cosas que cambiaran dentro de cada iteración del desarrollo. Usualmente identificamos las clases mas importantes del domino de objetos El resto de clases que no están definidas claramente dentro del dominio son mas difíciles de identificar.

27 Diagrama de Clases Identificación de clases y objetos
Se pueden elegir dos enfoques Diseño centrado en datos (DDD) Diseño centrado en responsabilidades (RDD) No olvide que las clases contiene datos y responsabilidades. Diseño basado en datos (DDD) Identificar los datos en el sistema Dividir los datos identificados en clases Considerar las responsabilidades de las clases Utilizar la técnica de identificación de sustantivos

28 Diagrama de Clases Identificación de clases y objetos
Diseño basado en responsabilidades (RDD) Identificar las responsabilidades del sistema Dividir las responsabilidades identificadas en clases Considerar los datos de las clases El preferible utilizar una mezcla de estos dos diseños.

29 Diagrama de Clases Identificación de clases y objetos
Identificación de sustantivos Identificar clases candidatas tomando todos los sustantivos a partir de la especificación de requerimientos del sistema. Considerar las formas singulares No incluir frases que contienen “o” como candidatos Diagrama de Clases Identificación de clases y objetos

30 Diagrama de Clases Identificación de clases y objetos
Identificación de sustantivos Descartar candidatos que no son apropiados por alguna razón, renombrar las clases restantes si es necesario. Redundancia Misma clase con diferente nombre: Préstamo y PrestamoCorto Seleccionar un nombre de clase que describa todo el contenido Vago No se puede decir de manera no ambigua cual es el significado por medio de un sustantivo Se debe librar de ambigüedades para poder determinar si un sustantivo representa una clase. Evento o operación Cuando un sustantivo se refiere algo hecho por o para o en el sistema No siempre esto esta bien modelado por una clase Si una instancia de una operación o evento no tiene estado, comportamiento o identidad descartarlo. Diagrama de Clases Identificación de clases y objetos

31 Diagrama de Clases Identificación de clases y objetos
Identificación de sustantivos Descartar candidatos que no son apropiados por alguna razón, renombrar las clases restantes si es necesario. Meta-lenguaje Cuando los sustantivos forman parte de la forma como se definen cosas. Los sustantivos requerimientos y sistema se usan como lenguaje de modelamiento en lugar de representar objetos en el dominio del problema Fuera de alcance Los sustantivos son relevantes para describir como el sistema trabaja pero no para referirse algo dentro del sistema. Un atributo Un sustantivo que se refiere a algo simple sin comportamiento interesante el mismo que es un atributo de otra clase Diagrama de Clases Identificación de clases y objetos

32 Identificación de clases y objetos Qué tipo de cosas son clases?
Una clase describe un conjunto de objetos con un rol o roles equivalentes en un sistema. Objetos y sus divisiones en clases frecuentemente se derivan de una de las siguientes fuentes Cosas tangibles o del mundo real Libro, Copia, Curso, etc. Roles Bibliotecario, Estudiante, Director de estudios Eventos Llevar, Dejar, Requerir, etc. Interacciones Encontrar, Interceptar, etc.

33 Diagrama de Clases Identificación de clases y objetos
Recordar que los objetos son cosas reales dentro de un programa de computadora No grabar información que es irrelevante para el sistema No perder de vista el hecho que los objetos son el sistema El error clásico de las personas es inventarse una clase llamada Sistema No generan un diseño orientado a objetos sino un diseño monolítico en el que un objeto conoce y hace todo.

34 Elementos de un diagrama de clases

35 Diagrama de Clases Elementos de un Clases
Una clase se representan como un rectángulo dividido en tres partes El nombre de la clase. Los atributos, en la forma: visibilidad nombreAtributo: tipo Los métodos, en la forma: visibilidad nombreMétodo(parámetros): tipoRetorno. Los parámetros van separados por comas y sólo se especifica el tipo. Los constructores no tienen tipo de retorno. La visibilidad de atributos y métodos – privado + público # protegido ~ de paquete Diagrama de Clases Elementos de un

36 Diagrama de Clases Elementos de un Asociaciones
Una asociación (relación entre dos clases) Se representa como una línea continua entre dos Clases, Puede tener el nombre de la relación sobre esta línea La relación puede ser en un solo sentido para lo cual se muestra con una flecha que indica el sentido de la relación Diagrama de Clases Elementos de un Cada Carro tiene una relación con Conductor, pero también cada Conductor tiene relación con Carro. Esta es una relación en ambos sentidos. Un Pasajero conoce el Carro(o carros) con el cual viaja, pero el Carro no tiene ninguna relación con los Pasajeros

37 Diagrama de Clases Elementos de un Multiplicidad
Es una restricción que se pone a una asociación Limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase Diagrama de Clases Elementos de un - Un chofer tiene relación con cero o más autobuses. - Un autobús tiene relación con uno o dos choferes. - Una terminal de pasajero tiene relación con cero o muchos autobuses. - Un autobús tiene relación con un terminal de pasajero.

38 Diagrama de Clases Elementos de un Roles
Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol. Diagrama de Clases Elementos de un

39 Diagrama de Clases Elementos de un Herencia
La herencia es tomar características y funcionalidades definidas en otras clases. La relación de herencia se representa mediante un triangulo en el extremo de la relación que corresponde a la clase mas general o clase “padre”. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos pre-existentes. Diagrama de Clases Elementos de un

40 Diagrama de Clases Elementos de un Agregación y Composición
Las relaciones de Agregación y Composición son dos tipos de especialización de la relación de Asociación. Agregación Similar a la relación de Asociación solo varía en la multiplicidad ya que en lugar de ser una relación “uno a uno” es de “uno a muchos”. Composición Es una relación mas fuerte. Aporta documentación conceptual ya que es una “relación de vida”, es decir, el tiempo de vida de un objeto está condicionado por el tiempo de vida del objeto que lo incluye. Diagrama de Clases Elementos de un Tenemos una clase Agenda. Tenemos una clase Contacto. Una Agenda agrupa varios Contactos. Tenemos una clase Silla. Un objeto Silla está a su vez compuesto por cuatro objetos del tipo Pata. El tiempo de vida de los objetos Pata depende del tiempo de vida de Silla, ya que si no existe una Silla no pueden existir sus Patas.

41 Diagramas de secuencia, estado y actividad
Modelo dinámico

42 Diagramas de interacción
Describen como grupos de objetos colaboran para conseguir algún fin Muestran objetos y mensajes que se envían estos dentro de un Caso de Uso Capturan el comportamiento de los casos de uso Tipo de diagramas Diagramas de colaboración Diagramas de secuencia

43 Diagramas de Secuencia
Muestra una interacción ordenada según la secuencia temporal de eventos Muestra la interacción entre los objetos que tiene lugar a través del intercambio de mensajes Muestra los objetos participantes en la interacción y los mensajes que se intercambian ordenados según la secuencia de tiempo

44 Diagramas de Secuencia
Interacciones expresadas en función del tiempo Muestra los objetos participantes y los mensajes que intercambian entre ellos a lo largo del tiempo No muestra los enlaces entre los objetos Especifican restricciones de interacción en tiempo real Dos dimensiones Vertical: Representa el tiempo Horizontal: Representa los distintos objetos

45 Diagramas de Secuencia
El tiempo avanza verticalmente desde el comienzo hasta el final del diagrama El orden en que aparecen los objetos horizontalmente no tiene importancia Las líneas punteadas bajo los objetos representan la línea de vida de los mismos Se coloca una X para indicar que el objeto fue destruido (destroy)

46 Diagramas de Secuencia

47 Diagramas de Secuencia
Un mensaje es una comunicación entre objetos (invocación a métodos) que contiene información y que espera la realización de una acción El orden del envió de mensajes se visualiza de arriba abajo en el diagrama. Un mensaje se representa como una fecha entre las líneas de la vida de los objetos,

48 Diagramas de Secuencia

49 Diagrama de Estados Describen el comportamiento de clases y sistemas que han sido concebidos haciendo uso de un modelo de estados. En un modelo de estados se identifican las situaciones en la que el comportamiento o capacidad de respuesta con cualitativamente diferentes, así como los eventos o condiciones bajos las que se pasa de una situación a otra (transiciones de estados). Los diagramas de estados son intensivamente utilizados en: Sistemas de tiempo real y críticos. La descripción de sistemas reactivos. La descripción de sistemas basados en protocolos

50 Diagrama de Estados Calificación de estado
Estáticamente En función del valor que tienen sus atributos. Dinámicamente En función de la actividad que ejecuta. El comportamiento describe las acciones que se producen mientras que el sistema se encuentra en un estado: entry/behavior => Acción que se realiza cuando se llega a un estado. do/behavior => Actividad que se ejecuta mientras se está en un estado. Exit/behavior => Acciones que se ejecuta cuando se abandona un estado. Transiciones internas => Se formulan como trigger[guard]/behavior

51 Diagramas de estado Estado Estado inicial Transición a otro estado
Estado final Transición al mismo estado