DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE COLABORACION

Slides:



Advertisements
Presentaciones similares
Metodologías para el desarrollo de aplicaciones Web.
Advertisements

U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
METODOLOGÍA ORIENTADA A OBJETOS CARACTERISTICAS DEL PROCESO
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
TECNICATURA UNIVERSITARIA EN INFORMATICA
Diagrama de Flujo de Datos (DFD)
Tomado de:
Introducción a la Orientación a Objetos
Fundamentos de Ingeniería de Software
Prof. César Luza Montero
Etapas y actividades en el desarrollo OO basado en UML
CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS
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.
DESCRIPCION DEL PROBLEMA
Aspectos Avanzados de la Tecnología de Objetos
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.
DSOO - María Eugenia Valencia
Ingeniería de software Unidad II Ingeniería de Software Orientado a Objetos Principios Orientados a Objetos Tema Semana 7.
Ingeniería Software II
ESCUELA ACADEMICO PROFESIONAL DE INGENIERIA DE SISTEMAS
Modelado Arquitectónico
(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.
Actividad 6. Requisitos del software, referente a la estructura y base de datos. M.C. Juan Carlos Olivares Rojas Syllabus May,
Diagramas de Clase Angela Carrillo R..
Ingeniería de Software Orientado a Objetos
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
DISEÑO DE SOFTWARE 1ª. Parte
Fundamentos de programación
Diseño e Implementación
Poder Expresivo de UML 2.0 para especificar arquitecturas de Software
Análisis y Diseño Orientado a Objetos utilizando UML
ANALISIS Y DISEÑO DE SISTEMA Ing. Sanchez Castillo Eddye Arturo
Modelado del Negocio.
Clase 03 ELEMENTOS DE COMPUTACIÓN Contenidos Objeto Clase Atributo Método Instancia Herencia Polimorfismo UML.
Análisis de Sistemas.
Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
Organización y Estructuración de Datos
UML.
PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
Ingeniería de software
Diagrama de Clases ACI 570.
Algunas Herramientas de Apoyo al Diseño de Software Agustín J. González ELO329: Diseño y programación orientados a objetos.
Introducción a UML DIAGRAMA DE CLASES Departamento de Informática
Trainning DFD.
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.
DEFINICIÓN DE OBJETO Un objeto es aquello que puede ser observado, estudiado y aprendido CARACTERÍSTICAS nos permiten conocerlos mediante la observación,
Clasificación de Diagramas
Conceptos Fundamentales
Introducción a la Programación Orientada a Objetos (POO)
Ingeniería de Requisitos
Introducción a UML Ing. José Manuel Poveda.
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:
Sandra Muñoz Blanca González Patricia Lázaro
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Análisis y Diseño de Aplicaciones 3º Educación Media Tecnológica
UML – Lenguaje de Modelado Unificado
La Programación Orientado a Objetos
Diagrama de Clases.
PRESENTACION DE INGENIERIA ORIENTADA A OBJETOS
Fundamentos de Ingeniería de Software
Modelado UML Diagrama de Clases
Unified Modeling Language UML. Ejemplo a desarrollar La Universidad XXX desea computarizar su sistema de registración – El secretario establece el plan.
VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez.
Transcripción de la presentación:

DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE COLABORACION INGENIERIA DE SOFTWARE DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE COLABORACION Ing. Sanchez Castillo Eddye Arturo eddiesanchez0710@gmail.com www.ceneinnova/eddyesanchez Sesión 11

Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo Temario ... Diagramas de Clases de Análisis Diagramas de Colaboración Diagrama de Paquetes Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

Modelado basado en Clases ¿Qué se debe hacer para desarrollar los elementos basados en clases de un modelo de análisis: clases y objetos, atributos, operaciones, paquetes, y diagramas de colaboración? Identificación de clases de análisis Examinar el enunciado del problema (“análisis gramatical”) sobre las narrativas desarrolladas para el sistema que se va a construir o de los CdU. Las clases se determinan al reconocer cada sustantivo. Las clases se manifiestan en una de las siguientes formas: Entidades externas (como, otros sistemas, dispositivos, personas) que producen o consumen información que usará un sistema. Cosas (por ejemplo, reportes, despliegues, letras, señales) que son parte del dominio de la información para el problema. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Modelado basado en Clases Sucesos o eventos (como, una transferencia de propiedad) que ocurren dentro del contexto de la operación del sistema. Roles (por ejemplo, gerente, ingeniero, personal de ventas) que desempeñan personas que interactúan con el sistema. Unidades organizacionales (ejem, división, grupo) relevantes para alguna aplicación. Sitios (como, el piso de manufactura o el puerto de carga) que establecen el contexto del problema y la función global del sistema. Estructuras (por ejemplo, sensores, vehículos de cuatro ruedas o computadoras) que definen una clase de objetos o clases de objetos relacionadas. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Modelado basado en Clases Coad y Yourdon sugieren seis características de selección que se deben usar cuando un analista considera cada clase potencial para incluirlas en el modelo de análisis: Información referida. La clase potencial será útil durante el análisis sólo si la información acerca de ella debe recordarse para que el sistema pueda funcionar. Servicios requeridos. La clase potencial debe tener un conjunto de operaciones identificables que puedan cambiar el valor de sus atributos de alguna manera. Atributos múltiples. Durante el análisis de requisitos el enfoque debe estar en la información “importante”; una clase con un solo atributo puede, de hecho, ser útil durante el diseño, pero probablemente es mejor representarla como un atributo de otra clase durante la actividad de análisis. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Modelado basado en Clases Atributos comunes. Es posible definir un conjunto de atributos para la clase potencial, y estos atributos pueden aplicarse en toda las instancias de la clase. Operaciones comunes. Es posible definir un conjunto de operaciones para la clase potencial, y estas operaciones pueden aplicarse en todas las instancias de la clase. Requisitos esenciales. Las entidades externas que aparecen en el espacio del problema, y que producen o consumen información esencial para la operación de cualquier solución para el sistema, se definirán casi siempre como clases en el modelo de requisitos. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Modelado basado en Clases Especificación de atributos Los atributos describen una clase que ha sido seleccionada para incluirla en el modelo de análisis. En esencia, los atributos son los que definen la clase, lo cual clarifica qué significa la clase en el contexto del espacio del problema. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

operaciones que realizan un cómputo, Definición de operaciones Las operaciones definen el comportamiento de un objeto. Grandes categorías: operaciones que manipulan los datos de alguna manera (por ejemplo, al agregar, borrar, reformatear, seleccionar), operaciones que realizan un cómputo, operaciones que preguntan acerca del estado de un objeto, y operaciones que monitorean un objeto para la ocurrencia de un evento de control. Como una primera iteración en la obtención de un conjunto de operaciones para una clase de análisis, el analista puede estudiar otra vez la narrativa de un procesamiento (o caso de uso) y seleccionar aquellas operaciones que pertenezcan de manera razonable a la clase. Esto se logra estudiando de nuevo el análisis gramatical y aislando los verbos. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Clases Categorías de clases: Clases de entidad, también llamadas clases de modelo o negocios, se extraen de manera directa del enunciado del problema De manera típica, estas clases representan clases que se almacenarán en una base de datos y que persisten durante la aplicación. Clases de frontera. Se utilizan para crear la interfaz (por ejemplo, pantallas interactivas o reportes impresos) que el usuario ve y con la cual interactúa cuando se utiliza el software. Las clases de frontera están diseñadas para manejar la forma en que los objetos de entidad se presentan a los usuarios. Las clases de controlador manejan una “unidad de trabajo” desde el inicio hasta el final. Esto es, las clases de controlador se pueden diseñar para manejar: 1) la creación o actualización de los objetos de entidad; 2) la inmediatez de objetos de frontera conforme éstos obtienen información de objetos de entidad; 3) la comunicación compleja entre conjuntos de objetos; y 4) la validación de datos comunicados entre los objetos o entre el usuario y la aplicación. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Categorías de Clases: entidad, borde y control Una clase entidad es un modelo de la información perdurable. Ejm. La Clase Cuenta es una entidad porque la información sobre las cuentas tiene que permanecer en el S.I. Bancario. Una clase borde (límite) modela la interacción entre el S.I. y sus actores. Generalmente, se asocia con la entrada y la salida. Ejm. Una Interfaz de Usuario y los Reportes de Estado de Cuenta del cliente Una clase control es un modelo de los cálculos y algoritmos complejos. Ejms. Clase Calcular Monto de Préstamo, Clase Calcular Cuotas a Pagar Las clases control representan coordinación, secuenciado, transacciones y control de otros objetos. Estereotipos del UML para representar una Clase: Clase entidad Clase borde o límite Clase control

Diagrama de Clases Ejemplos Un diagrama de clases representa las clases y sus interrelaciones. Una clase representa un concepto discreto dentro de la aplicación que se está modelando: una cosa física, de negocios, lógica, de una aplicación, del computador, o una cosa del comportamiento. Son diagramas de clase válidos: Clase Cuenta Bancaria Clase Cuenta Bancaria saldoDelaCuenta depósito() retiro() Ejemplos Esta libertad de notación se hace extensiva a los objetos: Notación UML completa: cuenta bancaria : Clase Cuenta Bancaria cuenta bancaria es un objeto, una instancia de una clase denominada Clase Cuenta Bancaria Cuando no hay ambigüedad, UML permite usar, una notación más breve: cuenta bancaria

Diagramas de Colaboraciones Las colaboraciones identifican las relaciones entre clases.   Para ayudarse en la identificación de los colaboradores, el analista puede examinar tres relaciones genéricas diferentes entre las clases : la relación es-parte-de, la relación tiene-conocimiento-de, y la relación depende-de. Todas las clases que son parte de una clase agregada se conectan a ésta a través de una relación del tipo es-parte-de. Cuando una clase debe obtener información de otra clase se establece la relación tiene-conocimiento-de. La relación depende-de implica que dos clases tienen una dependencia que no se logra mediante las relaciones tiene-conocimiento-de o es-parte-de. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Relaciones entre Clases Asociaciones y dependencias En muchos casos, dos clases de análisis se relacionan entre si de alguna manera parecida a la forma en que se relacionan dos objetos de datos. En UML, estas relaciones se llaman asociaciones. En algunos casos, una asociación se puede definir en forma más extensa al indicar multiplicidad. En muchos casos existe una relación cliente-servidor entre dos clases de análisis. En tales casos, una clase de cliente depende de alguna manera de la clase de servidor y se establece una relación dependencia. Las dependencias se definen mediante un estereotipo. Un estereotipo es un “mecanismo de extensibilidad” dentro del UML que permite a un ingeniero de software definir un elemento de modelado especial cuya semántica define el cliente. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

Diagramas de Colaboraciones Agregación La agregación es el término del UML para la relación parte-todo. En la notación gráfica, el diamante se coloca en el extremo del todo. Clase Automóvil Ejemplos Clase Chasis Clase Motor Clase Llantas Clase Asientos “Un automóvil se compone de un chasis, un motor, llantas y asientos”

Diagramas de Colaboraciones Multiplicidad La agregación es el término del UML para la relación parte-todo. En la notación gráfica, el diamante se coloca en el extremo del todo. Clase Automóvil Ejemplos 1 1 1 1 1 1 1 1 4 .. 5 0 ..1 * 2 .. * Clase Chasis Clase Motor Clase Llantas Clase Techo Corredizo Clase Dados Clase Asientos “Un automóvil se compone de un chasis, un motor, 4 ó 5 llantas, un techo corredizo, cero ó más dados que cuelgan del espejo retrovisor y 2 ó más asientos”

Diagramas de Colaboraciones Clase Tablero de Ajedrez Composición La composición es una extensión de la agregación, pero más marcada. Cuando hay composición, es posible que cada parte pertenezca a un solo todo, y si el todo se borra entonces las partes también se borran. Ejemplos Clase Tablero de Ajedrez Clase Casilla 1 64

Diagramas de Colaboraciones Generalización La herencia es una función de la OO y es un caso especial de generalización. Clase Activo Ejemplos tipoDeActivo Clase Hipoteca Clase Inversión Ejemplo de generalización (herencia) con un discriminador explícito. La notación tipoDeActivo significa que cada instancia de la Clase Activo o sus subclases tiene un atributo tipoDeActivo

Ejemplos Generalización Es la relación en la que un elemento de un tipo específico (subclase o hijo) hereda los atributos y el comportamiento de un elemento general (superclase ó padre) Ejemplos

Diagramas de Colaboraciones Asociación Hay casos donde la asociación entre dos clases puede por si misma requerir que se modele como una clase. Ejm. Un cantante es atendido por un odontólogo en varias ocasiones, en cada una de ellas la atención es por diferentes servicios (curaciones, extracciones, implantes, otros). El modelamiento de la facturación por cada servicio requiere que la asociación servicios se convierta en una clase, la Clase Servicios, que es identificada como una clase de asociación, porque es tanto una asociación como una clase. Clase Cantante Clase Odontólogo servicio Clase Odontólogo Clase Cantante servicio Ejm. Una asociación Clase Servicios Ejemplos fechaDeServicio tipoDeServicio Ejm. Una clase de asociación

Asociación La clase Asociación se presenta cuando la propia relación de asociación entre dos clases tiene propiedades. Y, se representa con el símbolo de clase unido por una línea discontinua a una relación de asociación. Ejemplos

Diagrama de Paquetes Paquete de análisis Una parte importante del modelado del análisis es la categorización. Esto es, los diferentes elementos del modelo de análisis (por ejemplo, casos de uso, clases de análisis) se clasifican de una manera que los empaquete como una agrupación –llamada un paquete de análisis-, a la cual se le asigna un nombre representativo.

Diagrama de Paquetes Ejemplo. Considere el análisis de un video juego. Al desarrollar el modelo de análisis para el video juego se obtiene un gran numero de clases. Algunas se enfocan en el ambiente de juego, como las escenas visuales que el usuario ve mientras se desarrolla el juego. Otras se enfocan en los personajes dentro del juego al describir sus características físicas, acciones y restricciones. Además, otras describen las reglas del juego: como navega el jugador a través del ambiente. Pueden existir muchas otras categorías. El agrupamiento de estas clases pueden representarse como paquete de análisis. Y, el Diagrama de Paquetes como la visualización de estos paquetes

Hacia el Modelo de Diseño Arquitectura de aplicación del SW Interfaz con el usuario Funcionalidad general del sistema (aplicando SW, HW, Datos, Humanos) Modelo de Diseño Modelo de Análisis Estructura en el nivel de componentes Descripción del sistema (llena el vacío entre una descripción al nivel de sistemas y el diseño de software) Y, otros elementos del sistema (Ejm: seguridad, rendimiento)

Análisis y Diseño de Sistemas Fin de la Presentación GRACIAS Análisis y Diseño de Sistemas