Modelo de Análisis. Contenido Análisis Modelo de Análisis Modelo Conceptual.

Slides:



Advertisements
Presentaciones similares
Diccionario de Datos (DD)
Advertisements

Metodologías para el desarrollo de aplicaciones Web.
U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
CLASIFICACIÓN DE CLASES Orientación a objetos UNIVERSIDAD DEL VALLE DEL FUERTE Análisis y Diseño Orientado a Objetos Cañedo Encinas Fernando Onorat. Ingeniería.
Lenguaje Unificado de Modelado
TECNICATURA UNIVERSITARIA EN INFORMATICA
TECNICATURA UNIVERSITARIA EN INFORMATICA
Análisis y Diseño Orientado a Objetos.
DISEÑO ORIENTADO AL OBJETO
Tomado de:
UML 1.4 Peter Emerson Pinchao Solis.
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA 2006.
DSOO - María Eugenia Valencia
Introducción a la Orientación a Objetos
Modelos de Datos Modelado y Diseño de Bases de Datos
Prof. César Luza Montero
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
LENGUAJE UNIFICADO DE MODELADO UML
DIAGRAMAS DE CLASES Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando.
Análisis y Diseño O.O. Click to add notes Preguntas del diseño :
DIAGRAMA DE COMPONENTES INTEGRANTES Córdova Vásquez Giovanny Escobar Alvares Calixto Gomez Quinteros Adelaida Pinto Flores Yarmila.
DIAGRAMA DE CLASE.
Una Introducción a UML El Modelo de Proceso de Negocio
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Análisis y Diseño orientado a objetos con UML.
Profesor: Miguel Angel Vidal
DSOO - María Eugenia Valencia
Modelo de Análisis Centro ISYS Escuela de Computación
UML – Lenguaje de Modelado Unificado
DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
Análisis y Diseño Orientado a Objetos utilizando UML
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
* FRAUSTO JIMENEZ GABRIELA * * HERNANDEZ TORRES ANA LAURA * * MANDUJANO JUAN CARLOS * * NOVA MARIN YARELI PAULINA * * ZAVALA CORTE JOCELYN ARELI *
Diagramas de Clase Angela Carrillo R..
Viviana Poblete López Módulo: Modelo de Datos
IDENTIFICAR CONCEPTOS: ESTRATEGIAS Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados. Estrategia 1. Obtenerlos a partir.
Ingeniería de Software Orientado a Objetos
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
Fundamentos de programación
Bases de Datos Modelamiento.
Análisis y Diseño Orientado a Objetos utilizando UML
Modelos de Bases de Datos
Modelo de Dominio Angela Carrillo R..
Diagrama de Clases ACI 570.
PROYECTO EMPRESARIAL Clase # 2.
Introducción a UML DIAGRAMA DE CLASES Departamento de Informática
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
TEMA 9: DIAGRAMA DE CLASE EN UML
Curso de UML Actividad 4 Diagramas de Clases, de objetos y de Estructura compuesta Dra. Anaisa Hernández González.
Métrica v2.1 Técnicas: Modelado de datos (Parte 1)
Ingeniería de Software
I NGENIERÍA DE S OFTWARE L ABORATORIO VI Diseño - Diagrama de clases Eduardo Saavedra A. 07/10/2009.
Clasificación de Diagramas
Introducción a la Programación Orientada a Objetos (POO)
Ingeniería del Software 2002
Ingeniería de Requisitos
MODELAMIENTO VISUAL Y UML
DIAGRAMA DE CLASES.
UML.
Ilustra: E L M ODELO C ONCEPTUAL Conceptos (Objetos) en el dominio del problema. Es el instrumento (artefacto) más importante de crear en el AOO. Es la.
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Diagrama de Clases Uno de los mas importantes entre los diagramas UML
Análisis y Diseño de Aplicaciones 3º Educación Media Tecnológica
UNIVERSIDAD LATINA (UNILA) II.- MODELO DE IMPLEMENTACIÓN
Diagrama de Clases.
PRESENTACION DE INGENIERIA ORIENTADA A OBJETOS
Fundamentos de Ingeniería de Software
Modelado UML Diagrama de Clases
Entregables del Proyecto
Taller de Sistemas de Programas Clase 4 Dpto. de Computación y T.I.
Transcripción de la presentación:

Modelo de Análisis

Contenido Análisis Modelo de Análisis Modelo Conceptual

Análisis En el Workflow de Análisis se analizan, refinan y estructuran los requerimientos capturados con el propósito de estructurar el sistema completo. Los modelos que se desarrollan describen qué es lo que el sistema va a hacer.

Análisis Los modelos que se desarrollan están orientados al problema y no al ambiente en el que el sistema va a ser desarrollado e implementado.

Análisis El modelo de análisis proporciona una configuración conceptual del sistema que consiste de objetos de control, entidad e interfaces.

Modelo de Casos de Uso vs. Modelo de Análisis Use-Case Model Se describe usando el lenguaje del cliente. Es la vista externa del sistema. Analysis Model Se describe usando el lenguaje del desarrollador. Es la vista interna del sistema

Modelo de Casos de Uso vs. Modelo de Análisis Use-Case Model Se usa a manera de contrato entre clientes y desarrolladores para definir lo que el sistema debe y no debe hacer Analysis Model Se usa para que los desarrolladores comprendan como el sistema debe ser diseñado e implementado.

Modelo de Casos de Uso vs. Modelo de Análisis Use-Case Model Puede contener redundancias e inconsistencias en el enlace con los requerimientos. Captura la funcionalidad del sistema Analysis Model No debe contener redundancias ni inconsistencias en la interpretación de los requerimientos. Bosqueja como realizar la funcionalidad dentro del sistema.

Modelo de Análisis ¿Qué es? Clases Interfaz o Frontera Clases Entidad Clases de Control Diagrama de Clases de Análisis

¿Qué es? Es un modelo conceptual de objetos que ayuda a refinar los requerimientos y permite a los desarrolladores describir la estructura interna del sistema.

¿Qué es? Es una jerarquía de paquetes de análisis que agregan clases de análisis y realizaciones de casos de uso. Se describen las clases de análisis bajo sus tres estereotipos: Interfaz, Entidad y Control

¿Qué es? Analysis Model Analysis System Analysis Package 1 * ** ** Analysis Class Use Case Realization-Analysis

Clases Interfaz o Frontera Las Clases “Boundary” se usan para modelar la interacción entre el sistema y los actores. Esta interacción involucra recibir (y presentar) información y peticiones desde usuarios y sistemas externos.

Clases Interfaz o Frontera Representan la abstracción de de ventanas, formularios, paneles, interfaces de comunicación, impresoras, sensores, terminales o dispositivos.

Clases Interfaz o Frontera Ejemplo: La interfaz de pago es usada para soportar la interacción entre el actor cajero y el caso de uso de Registrar Pago. Cajero Interfaz Pago

Clases Entidad Las Clases Entidad (Entity) son usadas para modelar la información que tiene permanencia en el tiempo y es persistente. Modelan la información y el comportamiento asociado de algún concepto como una persona, evento u objeto del mundo real.

Clases Entidad Usualmente muestran la estructura de datos lógica que contribuye a la comprensión de la información que depende el sistema.

Clases Entidad Ejemplo: La clase entidad Pago permite mostrar la información de un pago en la interfaz de pago. Cajero Interfaz Pago Pago consulta

Clase Controladora Las clases “control” representan la coordinación, secuencia, gestión de transacciones y control de otros objetos. Usualmente se usan para encapsular el control relacionado con un caso de uso específico.

Clase Controladora También se usan para representar cálculos y derivaciones complejas, como la lógica del negocio que no se puede relacionar con ninguna entidad. La dinámica del sistema se modela en una clase controladora, que se encarga de delegar trabajo a otras clases.

Clase Controladora Ejemplo: La controladora de pagos es responsable de la coordinación entre la interfaz de pagos y la entidad pago. Cajero Interfaz Pago Registrar Controladora de Pagos Crear

Diagrama de Clases Es un diagrama que muestra las clases de análisis y sus relaciones. Cajero Interfaz Pago Registrar Controladora de Pagos Crear

Modelo Conceptual ¿Qué es? Conceptos Relacionados Relaciones Obtención del Modelo Conceptual Atributos.

¿Qué es? Es una vista que muestra los conceptos básicos del sistema: sus partes y relaciones. Se utiliza un diagrama de clases de UML simplificado. Es una representación de las relaciones entre clases entidad.

Conceptos Relacionados Correspondencia Tipo - Instancia Diagramas de Estructura Estática –Diagramas de Clase –Diagramas de Objetos Modelo Conceptual vs. Diagrama de Clases

Correspondencia Tipo- Instancia La dicotomía tipo-instancia –clase-objeto, asociación-link, parámetro-valor, operación-llamada, etc. En UML la distinción tipo-instancia emplea el mismo símbolo geométrico para cada par de elementos y subrayando el string del nombre.

Correspondencia Tipo- Instancia Punto x: Real y: Real rotar(angulo: Real) escala(factor: Real) p1: Punto x: 2.15 y: p2: Punto x: 2 y:

Diagrama de Clases Es una colección de elementos declarativos del modelo (clases y sus relaciones), conectados como un grafo.

Diagrama de Objetos Es un grafo de instancias de clase De modo Estático es una instancia de un Diagrama de Clases. De modo Dinámico muestra el estado detallado de un sistema en un periodo de tiempo.

Modelo Conceptual vs. Diagrama de Clases Ventana tamaño: Area visible: Boolean Ventana { abstract, autor = Joe, status=verificado} +tamaño: Area=(100,100) #visible: Boolean=false +default-size: Rectangle #maximum-size: Rectangle +desplegar ( ) +ocultar ( ) +crear ( ) subrayado: ámbito de clase

Relaciones Son vínculos que se establecen entre los conceptos o clases. En una primera etapa del análisis revisaremos las: –Asociaciones –Agregaciones

Relación de Asociación Representa una relación o conexión semántica entre objetos de diferentes clases

Relación de Asociación Pueden ser binarias, ternarias o de orden superior. Por defecto son bidireccionales

Relación de Asociación Asociación binaria Se denota gráficamente como un arco sólido conectando dos símbolos de clase.

Relación de Asociación Asociación binaria VUELO viaja TRIPULANTE

Atributos de las Relaciones Multiplicidad: Es indicada por un rango en el rol. Indicar el número de instancias vinculadas entre las clases. Rol: Cada final de la asociación es un rol (opcionalmente se documenta con un nombre).

Atributos de las Relaciones Navegabilidad: Indica el grado de visibilidad que tienen las intancias de una clase respecto de otra. Nombre: Cada asociación puede tener un nombre

Nombre de Asociaciones Legible y Entendible ASIENTO posee AVION

La Multiplicidad Define cuántas ocurrencias de un tipo A pueden ser asociados con una instancia de un tipo B. ASIENTO Posee 1 * VUELO

La Multiplicidad Exactamente uno Cero or muchos Uno o muchos Cero o uno Rango específico 1 0..* 1..* Muchos *

Relación de Asociación Empresa Persona *  Trabaja-para empleador empleado Trabajador salario jefe  gerencia 0..1 trabajador * Cuenta Persona Corporación Dirección de lectura del nombre de relación

Asociación N-aria Asociación entre 3 o más clases. La multiplicidad puede ser especificada pero es menos obvia.

Asociación N-aria Equipo Año Jugador Registro

Agregaciones Las agregaciones se identifican con relaciones entre tipos que impliquen que uno “tiene a” otro.

Agregaciones Aeropuerto Vuelo Avion El Vuelo está compuesto de Avión y Aeropuerto

Agregación Polígono Punto 3..* Contiene  {ordenado} Propiedad-Grafica color textura densidad 1 1

Composición Es una forma fuerte de agregación donde el tiempo de vida de la parte coincide con el todo. Las partes no deben sobrevivir fuera del todo. Operaciones de copia o eliminación al todo deben propagarse a las partes. Soporta encapsulamiento.

Agregación vs. Composición Círculo Polígono Punto Estilo

Obtención del Modelo Conceptual Explica los conceptos significativos en el dominio del problema. Procedimiento: –Los tipos o conceptos –Las asociaciones –La multiplicidad –Las agregaciones

Definir las clases o conceptos Hacer una lista de clases de acuerdo a categorías

Categorías Objetos físicos......Avión Descripciones de cosas Especificación de vuelo Lugares Aeropuerto Transacciones Venta Línea de transacciones......LineaProdVenta

Categorías Contenedores de cosas Avión Cosas dentro de un contenedor Pasajero Otros sistemas de cómputo o Dispositivos externos...ControlTráfico Abstractos Aerofobia Organizaciones DptoVentas

Categorías Eventos Aterrizaje Procesos ReservaciónAsiento Reglas PolíticaCancelación Catálogos CatálogodePartes Registros de Finanzas de trabajo, contratos legales Boleto Instrumentos y servicios financieros Línea de Crédito Manuales, y libros...ManualPersonal

Definición de las Asociaciones Deben registrarse las asociaciones en que el conocimiento de la relación se debe preservar durante algún tiempo No incluir asociaciones redundantes ni derivables

Lista de Asociaciones A es una parte física de B Ala A es una parte lógica de B LíneaVenta en Venta A está físicamente contenido en B Pasajero en Avión A está lógicamente contenido en B..... Vuelo en Descripción de Vuelo

Lista de Asociaciones A es una descripción de B Descripción de Vuelo y Vuelo A es una línea en una transacción o reporte LineaProducto y Venta A se conoce/introduce/registra/ presenta/ captura en B Reservación en ListaPasajeros

Lista de Asociaciones A es miembro de B....Piloto y Avión A es subunidad organizativa de B Mantenimiento y Linea Aerea A usa o dirige B Piloto y Avión A se comunica con B......Cliente y Vendedor

Multiplicidad Los extremos de una asociación pueden tener multiplicidad, nombre y navegación. Se define primero la multiplicidad.

Atributos Los atributos deben definirse de en correspondencia con los necesarios para representar los objetos del mundo real y no con componentes de software.

Atributos No utilizar atributos complejos (objetos). Utilice asociaciones Vuelo Destino Destino es complejo, modele como concepto sus posibles valores

Atributos No utilizar atributos que sean llaves foraneas. Utilice asociaciones Vuelo NumPiloto NumPiloto es una llave foránea, modele una asociación con Piloto