Educación a distancia
Fundamentos de Ingeniería de Software
Ingeniería en Sistemas Computacionales Fundamentos de Ingeniería de Software Semana 7. Unidad 3. Modelo de Análisis. 3.3. Clases 3.4. Diagramas de secuencias.
Antología realizada por: M.C. Gricelda Rodríguez Robledo
Semana 7
Educaci贸n a distancia
Fundamentos de Ingenier铆a de Software
CONTENIDO 3.3. Clases ............................................................................................................................................. 4 3.3.1 Diagramas de Clases ................................................................................................................ 5 NOTACION .................................................................................................................................... 5 3.3.3. Construcci贸n de un Diagrama de Clases de Dise帽o.............................................................. 13 3.4.
Diagramas de secuencias. ....................................................................................................... 15
3.4.1 Elementos .............................................................................................................................. 15 Referencias ......................................................................................................................................... 19
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
Competencia específica a desarrollar Actividades de Aprendizaje Identificar a través de un modelo de requisitos Investigar los diferentes modelos orientado a la arquitectura de clases que participarán en el objetos como base para la identificación de diseño del producto. clases. • Desarrollar casos de uso y modelos CRC que permitan tener una comprensión de la manera en que el sistema se utilizará. • Aplicar el modelo objeto-relacióncomportamiento que indique como responderá el sistema OO a eventos. • Aplicar al menos una herramienta CASE para el análisis. • Parte 1 del proyecto: A. Identificación y delimitación del problema B. Propuesta de solución
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
3.3. CLASES En la programación orientada a objetos, una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto, por ejemplo, una instancia del objeto de la clase "Persona" sería del tipo "Persona".
Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a través de marcadores de datos llamados atributos (o variables miembro o variables de instancia), y encapsula el comportamiento a través de secciones de código reutilizables llamados métodos.
Más técnicamente, una clase es un conjunto coherente que consiste en un tipo particular de metadatos. Una clase tiene tanto una interfaz y una estructura. La interfaz describe cómo interactuar con la clase y sus instancias con métodos, mientras que la estructura describe cómo los datos se dividen en atributos dentro de una instancia. Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase. En el diseño orientado a objetos, una clase es el tipo más específico de un objeto en relación con una capa específica.
Semana 7
Fundamentos de Ingeniería de Software
Educación a distancia
3.3.1 DIAGRAMAS DE CLASES El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones. El mundo real puede ser visto desde abstracciones diferentes (subjetividad)
NOTACION Cada clase se representa en un rectángulo con tres compartimientos: Nombre de la Clase 1 Atributo 1 Atributo 2 ................. Operacion1( ) Operacion2( ) .................
Nombre de la clase Atributos de la clase Operaciones de la clase
Atributos: Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son: Privado (-): es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++). Protegido (#): Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original. Público (+): Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación).
Semana 7
Fundamentos de Ingeniería de Software
Educación a distancia
Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: Privado (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden acceder). Protegido (#): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). Público (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.
Ejemplos de Clases: Cliente Automóvil
Alumno
- Nombre
- Ruedas - Asientos - Puertas
- Nombre - Dirección - Carnet_Identidad
- Dirección
+ Arrancar ( ) + Acelerar ( ) + Frenar ( ) + Girar ( )
+ Estudiar( ) + Tomar_apuntes( )
+ Comprar ( )
- Teléfono
+ Devolver ( )
Relaciones entre clases: Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relación son: Asociación Agregación (vista como un caso particular de asociación) Generalización/Especialización. Las relaciones de Agregación y Generalización forman jerarquías de clases.
Semana 7
Fundamentos de Ingeniería de Software
Educación a distancia
Asociación: La asociación expresa una conexión bidireccional entre objetos. Una asociación es una abstracción de la relación existente en los enlaces entre los objetos. Puede determinarse por la especificación de multiplicidad (mínima...máxima) Trabaja_para
Persona
Compañía
Aeropuerto
Vuelo
Trabaja_en_proyecto
Proyecto_Software
Lenguaje_prog
Persona
Multiplicidad: Representa el número de objetos que pueden conectarse a través de una relación de asociación. Existen tres tipos de multiplicidad o cardinalidad.
Uno a Uno Uno a Muchos Muchos a Muchos
Semana 7
Fundamentos de Ingeniería de Software
Educación a distancia
Notación
Lectura
1
Exactamente Uno
*
Muchos
0…1
Cero a uno
0…*
Cero a muchos
1…*
Uno a Muchos (al menos uno)
M…N
De M hasta N (enteros naturales)
Ejemplos: Trabaja_para
Persona 1...* 1...*
Compañía
1…*
Aeropuerto
Vuelo
1…*
Roles:
Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. Ejemplo 1: *
Emplea 1…* Empresa
Contratante
Trabajador Empleado
Semana 7
Fundamentos de Ingeniería de Software
Educación a distancia
Ejemplo 2:
2
Persona
Padre Hijo
Es_padre_de
* Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol.
Clases Asociación:
Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea de la asociación por medio de una línea a trazos. Tanto la línea como el rectángulo de clase representan el mismo elemento conceptual: la asociación. Por tanto ambos tienen el mismo nombre, el de la asociación. Cuando la clase asociación sólo tiene atributos el nombre suele ponerse sobre la línea (como ocurre en el ejemplo de la Figura 11). Por el contrario, cuando la clase asociación tiene alguna operación o asociación propia, entonces se pone el nombre en la clase asociación y se puede quitar de la línea. Ejemplo: *
Emplea 1…* Empresa Contratante
Trabajador Empleado
Salario
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento). Un Ejemplo es el siguiente:
En donde se destaca que: Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente. La relación de agregación tiene cardinalidad o multiplicidad.
Semana 7
Fundamentos de Ingeniería de Software
Educación a distancia
Ejemplo: 2 Ordenador
Ejemplo: 3
CPU * * Universidad
Teclado Facultad
Monitor Carrera
Generalización: Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases, se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización. La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general. Los nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base clase derivada. Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas. La Generalización y Especialización son equivalentes en cuanto al resultado: la jerarquía y herencia establecidas. Generalización y Especialización no son operaciones reflexivas ni simétricas pero sí transitivas. La especialización es una técnica muy eficaz para la extensión y reutilización. La Notación para la Generalización/Especialización es un triangulo que conecta una superclase con sus subclases. La superclase se conecta a la parte superior del triangulo. La subclase se conecta mediante una línea a la base del triangulo.
Semana 7
Fundamentos de Ingenier铆a de Software
Educaci贸n a distancia
Ejemplo: Vehiculo - Ruedas - Puertas - Asiento + Arrancar( ) + Acelerar( ) + Frenar( ) + Girar( )
Autom贸vil
Cami贸n
- Deportivo
- Remolque
+ Correr( )
+ Cargar( )
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
3.3.3. CONSTRUCCIÓN DE UN DIAGRAMA DE CLASES DE DISEÑO Normalmente se tiene una idea de un Diagrama de Clases, con una asignación de responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases Borrador, puede seguirse la siguiente estrategia:
Identificar todas las clases participantes en la solución software. Esto se lleva a cabo analizando los Diagramas de Interacción.
Representarlas en un diagrama de clases. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual. Añadir los métodos, según aparecen en los Diagramas de Interacción. Añadir información de tipo a los atributos y métodos. Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos. Añadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos.
Algunos de estos pasos se van realizando según se vayan completando los Diagramas de Interacción correspondientes. No existe precedencia entre la realización del Diagrama de Clases de Diseño y los Diagramas de Interacción. Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja primero más en el de clases y otras veces se trabaja primero más en los de interacción.
No todas las clases que aparecían en el Modelo Conceptual tienen por qué aparecer en el Diagrama de Clases de Diseño. De hecho, tan solo se incluirán aquellas clases que tengan interés en cuanto a que se les ha asignado algún tipo de responsabilidad en el diseño del sistema. No hay, por tanto, un transición directa entre el Modelo Conceptual y el Diagrama de Clases de Diseño, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensión de un dominio, y el segundo en una solución software.
En el Diagrama de Clases de Diseño se añaden los detalles referentes al lenguaje de programación que se vaya a usar. Por ejemplo, los tipos de los atributos y parámetros se expresarán en el lenguaje de implementación escogido.
Semana 7
Educaci贸n a distancia
Fundamentos de Ingenier铆a de Software
Ejemplo de Aplicaci贸n
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
3.4. DIAGRAMAS DE SECUENCIAS. Este diagrama (también llamado diagrama de interacción) muestra las interacciones entre un conjunto de objetos (clases, actores), ordenadas según el tiempo en que tienen lugar. Es decir, muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama la secuencia de todas las llamadas posibles del sistema, es por ello que se escoge un punto de partida. El diagrama se compone con los objetos que forman parte de la secuencia, estos se sitúan en la parte superior de la pantalla, normalmente a la izquierda se sitúa el que inicia la acción. De estos objetos sale una línea que indica su vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando él esta activo. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. El diagrama de secuencia puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o desde el de Casos de Usos.
3.4.1 ELEMENTOS Los componentes de un diagrama de interacción son: Línea de vida
Un objeto (o actor) se representa como una línea vertical punteada con un rectángulo de encabezado y con rectángulos a través de la línea principal que denotan la ejecución de métodos (activación). El rectángulo de encabezado contiene el nombre del objeto y el de su clase.
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
Activación Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.
Mensajes
El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. Representa la llamada de un método (operación) de un objeto en particular.
También es posible visualizar llamadas a métodos desde el mismo objeto en estudio. El presente diagrama es útil para observar la vida de los objetos en el sistema, identificar llamadas a realizar o posibles errores del modelo estático, que imposibiliten el flujo de información o de llamadas entre los componentes del sistema.
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
Figura : Diagrama de Secuencia Las líneas verticales o “líneas de la vida” representan el tiempo de vida del objeto. La vida del objeto “carlos” no termina en este diagrama, sin embargo la del objeto “tosty” sí y esto viene representado mediante el aspa al final de su línea de la vida. Los rectángulos verticales son barras de activación y representan la duración de la ejecución del mensaje. El mensaje “Encender”, posiblemente implementado mediante la introducción del enchufe en una toma de pared, tiene una duración escasa y similar a la de “Apagar”. No ocurre lo mismo con la llamada al método “tostar()”, que dura desde la pulsación del botón de tostar hasta que el pan es retirado de la bandeja y además interviene la emisión de un aviso cuando el pan está lo suficientemente caliente, a fin de evitar que se queme. Como se puede observar, la acción tostar viene condicionada por la presencia de pan en la bandeja de la tostadora. En UML los corchetes “*+” expresan condición y si están precedidos de un asterisco indican interacción mientras se cumpla la condición. Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia pueden ser síncronos o asíncronos. Los mensajes asíncronos son aquellos tal que el emisor puede enviar nuevos mensajes mientras el original está siendo procesado. El mensaje asíncrono ocurre en el tiempo de manera independiente a otros mensajes. Los mensajes síncronos son todo lo contrario, el emisor debe esperar a que termine el tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. UML emplea los siguientes convenios para representar el tipo de mensaje.
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
Tabla : Tipos de mensaje en diagramas de interacción Los diagramas de colaboración son otro tipo de diagramas de interacción, que contiene la misma información que los de secuencia, sólo que se centran en las responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son enviados. Cada mensaje de un diagrama de colaboración tiene un número de secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la misma llamada a un método se numeran 1.1, 1.2 y así sucesivamente para tantos niveles como sea necesario.
Figura : Diagrama de Colaboración
Semana 7
Educación a distancia
Fundamentos de Ingeniería de Software
REFERENCIAS •
Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000.
•
Ingeniería de Software: Un enfoque práctico - Roger S. Pressman - Mc Graw Hill – 2002.
• El lenguaje unificado del modelado, Grady Booch, James Rumbaugh, Ivar Jacobson, Editorial, Addison Wesley, 1999.
Semana 7