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

Introducción al análisis y diseño orientado a objetos
Depto de Lenguajes y Sistemas Informáticos. AESI

¿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 Depto de Lenguajes y Sistemas Informáticos. AESI

Depto de Lenguajes y Sistemas Informáticos. AESI
¿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 ... Depto de Lenguajes y Sistemas Informáticos. AESI

Problemas en OO “...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 Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

Objetivos  Productividad  Calidad minimiz. Errores facilidad de uso portabilidad modificabilidad Misma represent. en fases del ciclo de vida Depto de Lenguajes y Sistemas Informáticos. AESI

Beneficios Reusabilidad Crear nuevos sistemas utilizando los ya existentes Extensibilidad Fácil ampliación sin necesidad de retocar módulos Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

Características OO Encapsulación Herencia Paso de Mensajes Enlace Dinámico Polimorfismo Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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) Depto de Lenguajes y Sistemas Informáticos. AESI

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() Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

Análisis OO Identificar objetos y clases Diccionario de datos Identificar asociaciones entre objetos Identificar atributos y operaciones Refinar mediante Herencia Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

Diccionario de datos Describir con precisión cada clase de objetos También se describirán asociaciones atributos operaciones Depto de Lenguajes y Sistemas Informáticos. AESI

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” Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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...” Depto de Lenguajes y Sistemas Informáticos. AESI

Ejercicio “La Biblioteca”

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

Construir la casita del perro
Una persona puede realizarla Requiere Mínimo esfuerzo de modelado Proceso simple Herramientas simples Depto de Lenguajes y Sistemas Informáticos. AESI

Construir una casa Un equipo la construye de forma más eficiente y en menos tiempo Requiere Modelado Proceso bien definido Herramientas potentes Depto de Lenguajes y Sistemas Informáticos. AESI

Construir un rascacielos

Modelar una casa Depto de Lenguajes y Sistemas Informáticos. AESI

“ Un modelo captura los aspectos esenciales de un sistema”
¿El modelado visual? “ Un modelo captura los aspectos esenciales de un sistema” James Rumbaugh Reglas de Negocio Item PedirA El modelado visual es la construcción de modelos usando herramientas gráficas estándar. Sistema Informáticoo Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

El Modelado Visual y la Complejidad de un Sistema

Arquitectura del Software
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 Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

Creación de UML OOSE Other methods UML 0.9 Web - June ´96 UML 1.3 Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 public feedback UML 1.0 UML partners Unified Method 0.8 OOPSLA ´95 Booch method OMT Depto de Lenguajes y Sistemas Informáticos. AESI

Contribuciones a UML Harel Meyer Gamma, et al HP Fusion Booch Embley
Statecharts Meyer Before and after conditions Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Booch Booch method Embley Singleton classes and high-level view Rumbaugh OMT Wirfs-Brock Responsibilities Jacobson OOSE Shlaer - Mellor Object lifecycles Odell Classification Depto de Lenguajes y Sistemas Informáticos. AESI

Características de UML
UML es un lenguaje para visualizar specificar construir documentar los artefactos de un sistema software Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

Diagramas de UML Un modelo es una descripción completa de un sistema desde una perspectiva particular State Diagrams Diagramas de Clases Use Case Diagrams Diagramas de Casos de Uso State Diagrams Diagramas de Objetos Use Case Diagrams Diagramas de Secuencia Scenario Diagrams Diagramas de Colaboración State Diagrams Diagramas de Componentes Modelos Scenario Diagrams Digramas de Estados Component Diagrams Diagramas de Implantación Diagramas de Actividad Depto de Lenguajes y Sistemas Informáticos. AESI

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. Algunas similitudes y diferencias entre DFDs y D. de Casos de Uso: Un caso de uso es una función (servicio o transacción) atómica ofrecida por el sistema al entorno (actores), mientras que un proceso de un DFD puede ser detallado en un DFD hijo. Así, el concepto de “explosión de proceso” sólo se aplica a los DFDs. Aunque en cierta forma con relaciones de inclusión entre casos de uso (que se explican más adelante) puede mostrarse la factorización de un caso de uso esto no llega a ser equivalente a explosión de proceso. Aunque un caso de uso y un proceso modelan una pieza de funcionalidad del sistema su especificación es diferente. En un caso de uso interesa expresar la funcionalidad mediante la interacción (enlaces de comunicación) actor(es) – sistema. En un proceso la funcionalidad se expresa mediante la transformación que se hace de los flujos de entrada para producir flujos de salida. Un caso de uso en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visión externa del sistema. La excepción a lo anterior podría producirse al factorizar funcionalmente un caso de uso para establecer una relación de inclusión (que se explica más adelante). Un DFD, según sea el nivel de detalle, puede mostrar descomposición funcional interna del sistema. La diferencia entre Captura de Requisitos y Análisis radica esencialmente en el grado de detalle que se obtiene respecto del particionamiento del problema (funcional y de datos). La Captura de Requisitos ofrece un particionamiento en el contexto del usuario y adecuado para su comprensión. El Análisis provee un particionamiento que pueda ser utilizado como entrada para el Diseño del Sistema. Así, se puede afirmar que los D. de Casos de Uso son una herramienta exclusivamente de Captura de Requisitos mientras que los DFD podrían utilizarse en ambas actividades. En captura de requisitos para un DFD una entidad externa equivale a un actor, un almacén único y global evita entrar en análisis de datos y los procesos establecidos sólo hasta el nivel de transacciones se corresponden casos de uso. Las relaciones de extensión y de generalización entre casos de uso no tienen correspondencias en los DFDs. ... Depto de Lenguajes y Sistemas Informáticos. AESI

… 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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

… Casos de Uso Ejemplo: Depto de Lenguajes y Sistemas Informáticos. AESI

… 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 Depto de Lenguajes y Sistemas Informáticos. AESI

… 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 Depto de Lenguajes y Sistemas Informáticos. AESI

Casos de Uso: Relaciones
UML define cuatro tipos de relación en los Diagramas de Casos de Uso: Comunicación: Actor Caso de Uso Depto de Lenguajes y Sistemas Informáticos. AESI

<<include>>
… 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>> Depto de Lenguajes y Sistemas Informáticos. AESI

<<extend>>
… Casos de Uso: Relaciones Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino Caso de uso origen Caso de uso destino <<extend>> Depto de Lenguajes y Sistemas Informáticos. AESI

… Casos de Uso: Relaciones 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 Depto de Lenguajes y Sistemas Informáticos. AESI

… Casos de Uso: Relaciones Ejemplo: <<extends>> Trnasferencia por Internet Cliente <<includes>> Transferencia Identificación Depto de Lenguajes y Sistemas Informáticos. AESI

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? Depto de Lenguajes y Sistemas Informáticos. AESI

… 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? Depto de Lenguajes y Sistemas Informáticos. AESI

PARTE II FASE DE ANÁLISIS Es importante destacar que, por estrategia del curso, en el capítulo “Breve Tour por UML” se aborda de una manera muy resumida todos los diagramas que constituyen UML, dando una visión global de todo lo que posteriormente será detallado y complementado con guías de modelado y de proceso. En nuestra experiencia esta estrategia ha sido efectiva puesto que el alumno puede visualizar el alcance de UML. Por otra parte en este capítulo se desarrolla una sencilla guía de laboratorio con la cual se consigue un primer contacto con la herramienta utilizada (Rational Rose). Esto ha resultado motivador para el alumno. Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

Modelado de Casos de Uso Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

Actores Un sistema externo también puede participar como actor (primario o secundario) en un caso de uso. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

Identificando casos de uso
Por ejemplo, el cliente ATM interactúa con 3 casos de uso que son distintos pues proveen resultados distintos: Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

Ej. Sacar dinero ATM (2/4) Descripción: El cliente inserta la tarjeta en el lector del ATM. Si la tarjeta es reconocida se lee el número de la misma. El sistema pide la clave al cliente. El cliente introduce la clave (PIN). El sistema verifica la fecha de caducidad y si es robada o extraviada. Si es válida el sistema comprueba la clave introducida con la que lleva la tarjeta escrita. Si el PIN es válido el sistema ve qué cuentas están disponibles para dicha tarjeta. El sistema muestra las cuentas disponibles y le solicita al cliente elija entre “sacar dinero”, “consultar saldo” y “transferencia”. Depto de Lenguajes y Sistemas Informáticos. AESI

Ej. Sacar dinero ATM (3/4) Descripción: El cliente selecciona “sacar dinero”, introduce la cantidad y selecciona el número de la cuenta. El sistema comprueba si el cliente tiene suficiente dinero en dicha cuenta y si ha sobrepasado el límite diario. Si todo es correcto el sistema autoriza dispensar el dinero. El sistema dispensa el dinero. El sistema muestra un recibo incluyendo el número de operación, el tipo, la cantidad y el número de la cuenta. El sistema devuelve la tarjeta. El sistema muestra su mensaje de bienvenida. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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 Depto de Lenguajes y Sistemas Informáticos. AESI

Cliente reserva coche El 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. Depto de Lenguajes y Sistemas Informáticos. AESI

Cliente recoge coche Cuando 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 coche El cliente devuelve el coche a la agencia en el día establecido según el contrato de alquiler. Depto de Lenguajes y Sistemas Informáticos. AESI

Arquitectura y UML Componentes Clases, interfaces, colaboraciones Vista de diseño Vista de implementación Vista casos uso Casos de uso Clases activas Nodos Vista de proceso Vista de implantación Depto de Lenguajes y Sistemas Informáticos. AESI

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: Describe lo depositado El valor de cada item Total El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente: Cuantos ítemes han sido retornados en el día. 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: Información asociada a ítemes. Dar una alarma en el caso de que: Item se atora. No hay más papel. Depto de Lenguajes y Sistemas Informáticos. AESI

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: Depto de Lenguajes y Sistemas Informáticos. AESI

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba. Depto de Lenguajes y Sistemas Informáticos. AESI

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. Depto de Lenguajes y Sistemas Informáticos. AESI

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

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

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

Presentaciones similares

Presentación del tema: "Introducción al análisis y diseño orientado a objetos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

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

Presentaciones similares

Presentación del tema: "Introducción al análisis y diseño orientado a objetos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback