INGENIERIA DE SOFTWARE II Trayecto III. Trimestre I

Slides:



Advertisements
Presentaciones similares
Diccionario de Datos (DD)
Advertisements

U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
Programación Orientada a Objetos
TECNICATURA UNIVERSITARIA EN INFORMATICA
SISTEMAS II TECNICATURA UNIVERSITARIA EN INFORMATICA Unidad N° 2
Entidad Cosa u objeto real (una persona) o abstracto (un préstamo) de interés en el mundo real (una organización). Es distinguible de todos los demás objetos.
Modelo Entidad Relación
Diagrama de Clases Por: Ing. Juan Carlos Contreras Villegas
DIAGRAMA DE CLASE.
Tomado de:
UML 1.4 Peter Emerson Pinchao Solis.
Matriz de Relación.
Modelo Entidad-Relación
Diagramas Definitivos
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA 2006.
DSOO - María Eugenia Valencia
INGENIERIA DE SOFTWARE II Clase Nº 7
Modelo de Datos Unidad II.
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.
Diagrama de CLASES Alfredo Rodríguez Rojas
Modelo Entidad Relación E-R
DIAGRAMAS ENTIDAD RELACIÓN
USO DE RELACIONES En esta clase se tratarán los siguientes temas:
MODELO RELACIONAL.
DIAGRAMA DE COMPONENTES INTEGRANTES Córdova Vásquez Giovanny Escobar Alvares Calixto Gomez Quinteros Adelaida Pinto Flores Yarmila.
Modelo Entidad-Relación
Diagramas de clases Modelan la vista estática del sistema
DIAGRAMA DE CLASE.
PROGRAMACION ORIENTADA A OBJETOS
Análisis y Diseño orientado a objetos con UML.
Introducción a la programación Orientada a objetos
Tema 10: Interfaces Antonio J. Sierra.
MÓDULO II: FUNDAMENTOS DE BASE DE DATOS
* FRAUSTO JIMENEZ GABRIELA * * HERNANDEZ TORRES ANA LAURA * * MANDUJANO JUAN CARLOS * * NOVA MARIN YARELI PAULINA * * ZAVALA CORTE JOCELYN ARELI *
Sistemas de Bases de Datos I
Diagramas de Clase Angela Carrillo R..

DIAGRAMA DE CLASE Ing. Christian Ovalle.
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
UML.
DIAGRAMAS ENTIDAD RELACIÓN
Diagrama de Clases ACI 570.
Diagrama de CLASES Alfredo Rodríguez Rojas
Introducción a UML DIAGRAMA DE CLASES Departamento de Informática
Bases de Datos.
TEMA 9: DIAGRAMA DE CLASE EN UML
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 de Requisitos
DIAGRAMA DE CLASES.
UML Casos de Uso (repaso) y Diagramas de Clase
Modelan la vista estática del sistema Elementos básicos: Clases Relaciones Objeto: Representación de una entidad discreta (real o abstracta) - Estado:
UNIDAD 2 Modelo Entidad-Relación
Integrantes: -Miguel Gisbert -Rayner Mendoza -Karem Salinas -Luis Callisaya -Brian Barrera.
Análisis y Diseño de Aplicaciones 3º Educación Media Tecnológica
UML – Lenguaje de Modelado Unificado
Diagrama de Clases.
PRESENTACION DE INGENIERIA ORIENTADA A OBJETOS
Fundamentos de Ingeniería de Software
Modelo de Entidad-Relación (Modelo Conceptual) Ing. Linda Masias Morales INTEGRACION DE LAS TECNOLOGIAS DE INFORMACION Y COMUNICACION.
Modelado UML Diagramas de Casos de Uso
1 Qué es UML Es un Lenguaje de Modelado Unificado basado en una notación gráfica que permite especificar,construir, visualizar y documentar los objetos.
Modelado UML Diagrama de Clases
Diagrama de clases Silvia Herzovich Rodrigo Aronas Matias Silversteyn.
Unified Modeling Language UML. Ejemplo a desarrollar La Universidad XXX desea computarizar su sistema de registración – El secretario establece el plan.
Modelos Entidad – Relación (E-R). El modelo entidad-relación Los MD soportados por los SGBD no suelen ofrecer, dado su bajo nivel de abstracción, los.
Estructura de Datos Departamento de Programación Universidad Metropolitana Contenido: UML. Envío de mensajes. Relaciones. Asociación. Agregación o composición.
Transcripción de la presentación:

INGENIERIA DE SOFTWARE II Trayecto III. Trimestre I © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Objetivo Adquirir habilidades en el modelado estructural de una aplicación, es decir, cuáles son los datos que la aplicación va a manejar. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Los Diagramas de Clase permiten representar aspectos de la estructura de un sistema o aplicación. Se usan para: Facilitar la identificación y modelado de los requisitos estructurales de una aplicación, es decir: Las clases que representan los objetos del negocio. Las relaciones entre estas clases. Esto establece que la Biblioteca Nacional debe garantizar que cada venezolano que visite las BP del país pueda sumarse a la autopista de la información, alternativas de comunicaciones de voz y data y transmisión conjunta de información de distinta naturaleza. Los Diagramas de Clase se pueden elaborar mediante el análisis de los diagramas de casos de uso. Cada sustantivo del nombre de un caso de uso representa un tipo o clase de negocio. Inscribir Alumno Alumno © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Un Diagrama de Clase en UML consta de: Una o más clases de objetos. Una o más relaciones entre clases. Alumno Nombre de la Clase + cedula + nombres + apellidos + genero + dirección + email + … + actualizarDatos() + obtenerDatos() + cambiarStatus() + …() Atributos (estructura) Métodos u operaciones (comportamiento) Una CLASE representa una colección de entidades u objetos que tienen un conjunto común de propiedades. Es un constructor que define la estructura (estado) y el comportamiento (operaciones) de un conjunto de objetos denominados INSTANCIAS. Esto establece que la Biblioteca Nacional debe garantizar que cada venezolano que visite las BP del país pueda sumarse a la autopista de la información, alternativas de comunicaciones de voz y data y transmisión conjunta de información de distinta naturaleza. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Una clase describe los atributos que sus instancias posee Los atributos son las propiedades comunes que las instancias de una clase tienen. Formato de un atributo: Visibilidad/nombre: tipo[multiplicidad]=valor por defecto {propiedad} La visibilidad puede ser pública (+), privada (-) o sólo para el paquete (-). Las propiedades pueden ser: {read/only}, {sequence}, {ordered}. / indica que el atributo es derivado o calculado a partir de otros Esto establece que la Biblioteca Nacional debe garantizar que cada venezolano que visite las BP del país pueda sumarse a la autopista de la información, alternativas de comunicaciones de voz y data y transmisión conjunta de información de distinta naturaleza. Ejemplos: - + capacidadMax:integer = 45 - + estado:string = “activo” - / edad:integer {read/only} © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Formato de una operación: Una clase describe también las operaciones (métodos) que se pueden aplicar a sus instancias. Formato de una operación: Visibilidad/nombre (lista de parámetros): valor de retorno {propiedad} La visibilidad puede ser pública (+), protegida (#), privada (-) o paquete o paquete (-). Las propiedades pueden ser: {isQuery}, {sequential}, {concurrent}. La lista de parámetros tiene el siguiente formato: dirección nombre: tipo[multiplicidad]=valor por defecto dirección indica si el parámetro es de entrada (in), salida (out) o ambos (inout) Esto establece que la Biblioteca Nacional debe garantizar que cada venezolano que visite las BP del país pueda sumarse a la autopista de la información, alternativas de comunicaciones de voz y data y transmisión conjunta de información de distinta naturaleza. Ejemplos: + obtenerEstado():string + actualizarDatos(in marca:string, in modelo:string) #cambiarCapacidad(in nueva:integer) {sequential} © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Entre las clases se establecen RELACIONES de varios tipos: Las RELACIONES representan asociaciones del mundo real entre dos o más clases. Generalización y herencia A B Asociación A +rol1 +rol2 B Agregación A B Composición A B Dependencia A B © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Generalización y Herencia Establece una relación de tipo “es_un” entre dos o más clases. Una o más clases específicas, denominadas subclases, heredan la estructura y comportamiento de una clase genérica. Las subclases tiene (heredan) los mismos atributos y operaciones que tiene la superclase. Estudiante Persona Profesor Superclase Subclases © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Asociación (1) Establece una relación funcional entre dos o más clases. Cada instancia de una clase se asocia a cero, uno o más instancias de la otra clase asociada. Nombre de la asociación Rol Estudiante +cursa inscribe +es_cursada Materia 1 1..* Multiplicidad El nombre de ROL indica el papel que una clase participante de un conjunto de clases desempeña en cada instancia de una relación y ayuda a explicar el significado de la relación © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Las asociaciones se caracterizan por: Asociación (2) Las asociaciones se caracterizan por: Nombre: Que es un verbo en singular. Ejemplo: Imparte, escribe, etc. Grado: Número de entidades que participan en la interrelación (Puede ser unaria o recursiva, binaria o ternaria) Multiplicidad: Expresa el número de entidades a las que otra entidad pueda estar asociada, por medio de un conjunto de relaciones. Roles: Indican el papel que juega una clase en una asociación © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Asociación (3) La multiplicidad se representa con: Un número fijo: 1 Un intervalo de valores: 2..5 Un rango en el cual uno de los extremos es un asterisco. Por ejemplo, 2..* significa 2 o más. Una combinación de elementos separados por comas: 1, 3..5, 7, 15..* Un asterisco: * . Indica cero o más. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

ASOCIACIÓN UNARIA O RECURSIVA Persona Casada con Materia Evaluación Estudiante Obtiene ASOCIACIÓN UNARIA O RECURSIVA Médico Paciente atiende ASOCIACIÓN TERNARIA ASOCIACIÓN BINARIA © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Asociación (4) Multiplicidad Es la especificación del número de ocurrencias de una entidad que se relaciona con ocurrencias de otra entidad. Define el número máximo de relaciones de entidades que pueden participar en una relación. No proporciona una indicación de si una entidad en particular debe o no participar en la relación. Es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Esto depende del entorno real dentro del que se esté modelando. Asociación (5) Tipos de Multiplicidad Uno a uno Uno a muchos Muchos a uno Muchos a muchos Esto depende del entorno real dentro del que se esté modelando. © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

MULTIPLICIDAD UNO A UNO Asociación (6) MULTIPLICIDAD UNO A UNO Esposo Pedro Martín Juan Esposa Rosa Juana Elisa Tiene Una instancia de una clase A se puede relacionar a una y sólo una instancia de una clase B © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

MULTIPLICIDAD UNO A MUCHOS Asociación (7) MULTIPLICIDAD UNO A MUCHOS Madre María Mercedes Laura Hijos Luis Manuel Luisa Ana Tiene Miguel Una instancia de una clase A se puede relacionar a una o muchas instancia de una clase B © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

MULTIPLICIDAD MUCHOS A UNO Asociación (8) MULTIPLICIDAD MUCHOS A UNO Sucursal a1 a2 a3 Empresa b1 b2 b3 a4 Pertenece a a5 Una instancia de una clase A se puede relacionar con sólo una instancia de B, mientras que una instancia de B se puede relacionar con una o más instancias de A © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

MULTIPLICIDAD MUCHOS A MUCHOS Asociación (9) MULTIPLICIDAD MUCHOS A MUCHOS Tío Pedro Manuel Antonio Mireya Sobrino David Luis Nelson Simón Tiene Una instancia de una clase A se puede relacionar a una o más instancias de una clase B, mientras que una instancia de B se puede relacionar con una o más instancias de A © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Agregación Establece una relación “todo-partes” en la cual una clase (el todo) está conformada por otra u otras clases (las partes) La existencias de las instancias de las partes no depende de la existencia de las instancias de la clases agregada. Equipo de Trabajo Estudiante © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Composición Establece una relación “es_parte-de” entre dos clases. Es un tipo particular de agregación en la cual la existencia de las instancias de las partes depende de la existencia de la instancia compuesta Curso Clase compuesta 1..* 1..* 0..* Objetivo Contenido Actividad Clases componentes © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Dependencia Establece una relación entre una clase dependiente de otra. No establece un tipo específico de dependencia. Simplemente se indica que hay una dependencia entre dos clases. Curso Institución © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Casos Especiales Clase de Asociación Clase Abstracta Equipo + id + nombre + marca + modelo + … Clase Abstracta Paciente + id + nombres + … Médico Citas + fecha + hora 0..* PDA PC Teléfono + memoria + tipoCPU + … + memoria + tipoCPU + capDD + protocolo © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Usos de los Diagramas de Clase En la fase de especificación de requisitos, se usan para elaborar modelos de objetos de negocio que representan: Los objetos de negocio del dominio de la aplicación y Las relaciones entre estos objetos © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Usos de los Diagramas de Clase Un objeto de negocio es un concepto que está asociado al dominio de la aplicación o sistema de negocio. Representa una entidad del dominio de la aplicación. Está relacionado con los procesos de negocio que ejecutan los usuarios de una aplicación. Son los objetos conocidos por los usuarios de la aplicación. Los objetos de negocio pueden representar: Entidades físicas (un producto, una planta, un empleado) Entidades de comunicación (una orden de pago, una factura, una orden de producción) Entidades de información (capacidad de producción, un inventario, una reservación) © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Ejemplo 1:Sistema de Reservaciones Aéreas Hacer Reservación <<extends>> Reservar Múltiples Destinos Modificar Reservación Actualizar Reservación Eliminar Reservación Consultar Itinerario Registrar Vuelo Usar Reservacion <<include>> Cliente Aerolínea <<include>> Consultar Promociones Registrar Aviones <<extends>> Consultar Promociones de CF Cliente Frecuente (CF) © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

c - Identificación de Relaciones Ejemplo 1:Sistema de Reservaciones Aéreas - Identificación de los Objetos de Negocio Cliente Cliente Frecuente Vuelo Avión Reservación Aerolínea - Identificación de Relaciones Un cliente realiza una o más reservaciones Una aerolínea coordina uno o más vuelos Un avión es asignado a un vuelo . c © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Modelo de Objetos de Negocio Ejemplo 1:Sistema de Reservaciones Aéreas Reservación + reserva Cliente + reservado_por Vuelo + coordinado_por + coordina Aerolínea 0..* 0..* 1..* 1 1 asignación 1 Avión Modelo de Objetos de Negocio c © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

c Ejemplo 1:Sistema de Reservaciones Aéreas Reservación +fecha +hora +localizador +estado Clase de Asociación Diagrama de Clases Vuelo +id +numero +origen +destino +cupoDisponible +estado Cliente +id +cedula +nombre +telefono +e-mail Aerolínea +id +nombre +e-mail +estadoActual +… roles + coordinado_por + coordina + reserva + reservado_por 1..* 1 0..* 0..* 1 Asociación multiplicidad asignación 1 Avión +id +nombre +marca +modelo +capacidadMax +estado Clases de Negocio c © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Ejemplo 2:Sistema de Ordenes de Compra Agregar Producto Modificar Productos Actualizar Productos Eliminar Productos <<include>> Colocar O/C <<include>> Cliente Pago Cheque <<extend>> Realizar Pago <<extend>> <<extend>> Pago Efectivo Pago Crédito © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

c - Identificación de Relaciones Ejemplo 2:Sistema de Ordenes de Compra - Identificación de los Objetos de Negocio Cliente Producto Orden de Compra Encabezado Líneas de pedido (items solicitados) Pago Pago en efectivo Pago a crédito Pago con Cheque - Identificación de Relaciones Un cliente coloca una o más Ordenes de Compra Una Orden de Compra está compuesta por un encabezado y una o más líneas de pedido. Una Orden de Compra es pagada en efectivo, cheque o a crédito c © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Modelo de Objetos de Negocio Ejemplo 2:Sistema de Ordenes de Compra Cliente Orden de Compra + Pago 0..* 0..* 1..* 1 Encabezado Línea de Detalle Modelo de Objetos de Negocio c

c Ejemplo 2:Sistema de Ordenes de Compra Diagrama de Clases Orden de + numero + fecha +status +id + nombre +direccion Cliente calcularIva() calcularTotal() Línea de Detalle +cantidad c © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

FIN DE LA CLASE © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"