Ingeniería del Software - falconmarbella.com€¦Cada objeto tiene un identificador único ... UML...

1

Ingeniería del Software

El proceso simplificado de modelado, diseño e implementación orientado a objetos

06 de marzo de 2005José M. García - ESI 04/052

Índice

Conceptos de D.O.O.UMLProceso de desarrolloIdentificación y delimitación

Modelo de casos de usoClases del sistema

Modelado del sistemaDiagrama de clases

Diseño e implementación

2


Conceptos de D.O.O.

Clase:Abstracción que describe propiedades importantes para una aplicación.Abstrae dos tipos de propiedades:

• Atributos: datos que caracterizan a los objetos de la clase.

• Operaciones: comportamiento de los objetos de la clase.

Abstrae la estructura de datos (atributos) y el comportamiento (operaciones) de los objetos.


Conceptos de D.O.O.

Objeto:Instancia de una clase.Posee atributos (datos) y operaciones (comportamiento).Posee su propia identidad independiente del valor de sus atributos. Cada objeto tiene un identificador único asignado por el sistema cuando se instancia por primera vez

Operación:Acción o transformación que un objeto realiza o sufre. Una abstracción de comportamientos análogos de direrentes objetos.

3


Conceptos de D.O.O.

Mensaje:Forma de decirle a un objeto que realice una operación.

Polimorfismo:La misma operación se comporta de formas distintas para distintas clases.

Herencia:Relación de especialización entre diferentes clases.La subclase especializa los datos y el comportamiento de la superclase.

Ocultamiento:Los objetos son dueños de sus atributos: sólo se puede acceder a ellos a través de las operaciones.


UML

UML = Unified Modeling LanguageEs un sistema notacional destinado a los sistemas de modelado que utilizan conceptos orientados a objetos.Estándar de facto que nació en 1994 por iniciativa de Booch y Rumbaugh para combinar los métodos existentes hasta el momento, con el objetivo de definir un lenguaje y una notación estándar del lenguaje de construcción de modelos.

4


Proceso de desarrollo UML

Identificación y delimitación del sistemaUso del sistema: casos de uso.Operaciones del sistema: diagramas de secuencia.Principales clases y sus relaciones.

Modelado del sistemaDiagrama de clases y de objetos.Contratos y diagramas de colaboración.Diagramas de transición de estados.

Diseño e implementaciónModelar bases de datos y clases.Implementar el sistema final.


Identificación y Delimitación

Fase en la que se definen:Arquitectura preliminar del sistemaRequisitos del sistemaDiagrama de casos de usoClases y relaciones

5


Identificación y DelimitaciónArquitectura del sistema

Un sistema de información típico debe incluir una interfaz gráfica de usuario programada con algún lenguaje orientado a objetos y acceso a una base de datos.Debemos diferenciar y distinguir 3 niveles básicos en la arquitectura del sistema:

PresentaciónLógica de aplicaciónAlmacenamiento


Identificación y DelimitaciónRequisitos del sistema

Los requisitos son una descripción de las necesidades o metas que debe cumplir un producto software.Durante esta etapa tienen que definirse los siguientes elementos:

Descripción del sistema.Cliente que plantea la necesidad.Metas que debe cubrir el sistema.Funciones del sistema. Ej: realizar reintegroAtributos del sistema. Ej: facilidad de uso

6


Identificación y DelimitaciónDiagrama de casos de uso

Un diagrama de casos de uso contiene un conjunto de:

actores,casos de uso,relaciones,notas y restricciones.

Representa la interacción de los actores con el sistema y las relaciones entre los casos de uso.



Un actor es un conjunto de roles que los usuarios del sistema juega al interactuar con él. Son externos al sistema.Un caso de uso describe la secuencia de eventos de un actor que utiliza un sistema para completar un proceso.

7



Podemos clasificar las relaciones:Entre actor y casos de uso:

• Interacción o asociación: participación de un actor en un caso de uso.

Entre actores:• Generalización: un actor es más general que otro.

Entre casos de uso;• Inclusión (<<include>>): el caso de uso inicial

incluye el comportamiento del caso de uso final.• Extensión (<<extend>>): el caso de uso final se

puede extender con el comportamiento del caso de uso inicial en un punto concreto del primero.



Rellenar datos cliente Pedir productos Preparar pago

Rellenar datos cliente

Rellenar datos cliente

Rellenar datos cliente<<extend>>

<<include>><<include>><<include>>

Supervisor

Vendedor

8



Descripción de un caso de uso:Caso de uso: nombre del caso de uso.Actores: lista de actores, indicando cuál inicia el caso.Propósito: intención del caso de uso.Resumen: descripción breve del cometido del caso de uso.Curso normal de eventos: descripción del flujo normal de eventos que produce.Curso alternativo de eventos: descripción de los flujos de excepción de eventos.



Ejemplo de descripción de un caso de uso:

El socio puede cancelar en cualquier momento la operación, terminándose la sesión y devolviendo la tarjeta al socio.

CA de eventos:

El socio introduce la tarjeta de socio.El sistema identifica al socio y muestra las opciones.El socio consulta las películas existentes y elige uno.El sistema entrega la película deseada y termina la sesión, entregando la tarjeta al socio.

CN de eventos:

Un socio llega al cajero, éste muestra las opciones, el socio elige la película y el cajero se la entrega.

Resumen:Alquilar una cinta de vídeo a un socioPropósito:Socio(iniciador), selector de películas.Actores:Alquilar vídeoCaso de uso:

9


Identificación y DelimitaciónClases y relaciones

Se pretende identificar las principales clases del sistema y sus relaciones.A partir de los sustantivos y los verbos de los casos de uso obtendremos las clases y las relaciones entre ellos, respectivamente.No hay una correspondencia “mecánica”entre sustantivo y concepto porque el lenguaje natural es ambiguo.



Ejemplo:Este caso de uso comienza cuando un cliente llega a una caja de TPDVcon productos que desea comprar.El cajero registra el código universal del producto (CUP) de cada producto. Si el producto se repite, el cajero también puede introducir la cantidad de productos repetidos.

10



Relaciones entre clases. A partir de la siguiente lista de conceptos podemos extraer las relaciones.

A es miembro de B

A es una propiedad de BA se conoce / introduce / registra / presenta / captura en B

A está contiguo a BA es un elemento de línea en una transacción B

A es una transacción relacionada con otra transacción B

A es una descripción de BA se relaciona con una transacción BA está contenido lógicamente en BA se comunica con BA está contenido físicamente en BA usa o dirige BA es una parte lógica de B

A es una subunidad organizacional de BA es una parte física de B



Por último, los atributos de las clases se pueden extraer también de los sustantivos de los casos de uso.Todo lo que sea descartado como clase, puede que se pueda incorporar como un atributo.Ejemplo: Código de producto es un atributo de una venta.

11


Modelado del sistema

El objetivo es crear un modelo conceptual del sistema.Un modelo conceptual explica los conceptos significativos en un dominio del problema; es la etapa más importante del proceso de análisis orientado a objetos.Utilizaremos los diagramas de clases como modelo conceptual.


Modelado del sistemaDiagrama de Clases

Un diagrama de clases es un modelo estático, es decir, un modelo que refleja la estructura estática de las clases de objetos y sus relaciones.Frente a los modelos estáticos están los modelos de comportamiento que reflejan el comportamiento del sistema y de sus componentes. Ejemplo: contratos, diagramas de colaboración y diagramas de transición de estados.

12



Definiremos un diagrama de clases como un modelo de clases y relaciones entre clases.Es un modelo similar al entidad-relación, pero mucho más expresivo dada la riqueza de su representación.Contiene las clases del dominio del problema más importantes para la aplicación.



Los componentes fundamentales de un diagrama de clases son:

Clases (también llamados conceptos).Asociaciones entre clases.Atributos de las clases.

Representación de las clases:

+ Public- Private# Protected

13



Asociación: relación entre dos conceptos que indica alguna conexión significativa e interesante entre ellos.

Aparecen como verbos en la descripción del problema y/o casos de uso.Pueden ser n-arias. Casi siempre binarias relacionando dos clases.Se utilizan restricciones de cardinalidad.

Representación de las asociaciones:



Cardinalidad de las asociaciones

14



Atributos de enlace:Propiedad de un enlace en una asociación.Cada atributo tiene un valor para cada enlace.¿En asociaciones 1-N el atributo del enlace puede situarse en la clase N?



Agregación: expresa una relación parte-de.

15



Agregación vs. Asociación:Una agregación es una forma de asociación con un alto acoplamiento y ciertas propiedades:

• Transitiva y antisimétrica.• Las propiedades del agregado se propagan a los

componentes.• Se debe usar cuando hay propiedades de los

componentes que se pueden ligar al agregado.• Puede ser monocomponente, multicomponente o

recursiva.



Ejemplo agregación y asociación:

16



Ejemplo agregación recursiva:



Generalización: relación de herencia entre clases.

17



Navegabilidad: Es una propiedad del papel de una asociación.Indica la posibilidad de navegar unidireccionalmente en una asociación; desde la clase origen hasta la clase destino.


Diseño e implementación

El proceso de diseño implica transformar los diagramas creados anteriormente (fundamentalmente el de clases) en una base de datos y un programa orientado a objetos codificado en un lenguaje seleccionado previamente (C++, Java, Visual Basic).Podemos optar también por usar herramientas como Microsoft Access para simplificar la construcción de nuestra aplicación, ya que incluye la base de datos y los formularios en una sola aplicación.

18


Diseño e implementaciónImplementación OO: Transformación de las asociaciones

Una asociación bidireccional es implementada normalmente como un atributo de referencia dentro de cada objeto asociado.Si la asociación es unidireccional sólo se necesita añadir un atributo de referencia a una de las clases.Una asociación puede implementarse también como una clase.Los atributos de referencia de la clase “uno” son simplemente referencias a un objeto.Los atributos de referencia de la clase “muchos”necesitan un contenedor de objetos.



class Compañía {Persona * empleado;Compañía() {}

}

class Persona {Compañía empresarioPersona() {}

}

19



class Editorial {Libro * conjLibros;Editorial() {}

}

class Libro {Libro() {}

}


Diseño e implementaciónImplementación OO: Transformación de clase asociación

class Workstation {Autorizacion * autorizWorkstation() {}

}

class Autorizacion {Usuario miusuarioWorkstation miestacionAutorizacion() {}

}

class Usuario {Autorizacion * autorizUsuario() {}

}

20


Diseño e implementaciónImplementación OO: Transformación de atributos de enlace

Transformación de atributos de enlace:Asociación uno-a-uno: los atributos del enlace se pueden almacenar como atributos de cualquiera de los objetos.Asociación uno-a-muchos: los atributos del enlace se pueden almacenar como atributos del objeto “muchos”.Asociación muchos-a-muchos: se implementa la asociación como una clase.


Diseño e implementaciónImplementación OO: Transformación de agragación

class Teclado {Teclado() {}

}

class Monitor {Monitor() {}

}

class Computadora {Monitor * monitoresTeclado mitecladoComputadora() {}

}

21


Diseño e implementaciónImplementación OO: Transformación de herencia simple

class Incancescente : Lampara {

Teclado() {}

}

class Fluorescente : Lampara {

Fluorescente() {}

}

class Lampara {Lampara() {}

}


Diseño e implementaciónImplementación relacional: Transformación de clases

Cada clase se corresponde con una o más tablas.La tabla debe contener todos los atributos de la clase y un atributo más para identificar los objetos (primary key).Se asigna un dominio a cada atributo.Se especifica la clave primaria de la tabla.Se identifican los grupos de atributos a los que se accede con más frecuencia.

22


Diseño e implementaciónImplementación relacional: Transformación de clases

SstringDireccionNstringNombreNIDID-Persona

¿Nulo?DominioNombre atributo


Diseño e implementaciónImplementación relacional: Transformación de asociaciones

Cada asociación uno-a-uno se corresponde con una tabla distinta, o puede incluirse en forma de clave externa dentro de la tabla de cualquiera de las clases.Cada asociación uno-a-muchos se corresponde con una tabla distinta, o puede incluirse en forma de clave externa dentro de la tabla de la clase muchos.Cada asociación muchos-a-muchos se corresponde siempre con una tabla diferente.Las agregaciones siguen la misma regla que las asociaciones.Los nombres de rol se incorporan como parte del nombre del atributo de las claves externas.

23





Tabla Persona



SstringDireccionNstringNombreNIDID-Compañía


Tabla Compañía

SStringCargoNIDID-PersonaNIDID-Compañía


Tabla trabajaPara

24





Tabla Persona



SstringDireccionNstringNombreNIDID-Compañía


Tabla Compañía

SintnumAccionesNIDID-PersonaNIDID-Compañía


Tabla poseeAcciones

25


Diseño e implementaciónImplementación relacional: Transformación de herencia

SdoubleAreasuperficialSdoublePresiondescargaSdoublePresionsuccionNstringTipo-PiezaSintCosteNstringNombreNIDID-Persona


Ingeniería del Software - falconmarbella.com€¦Cada objeto tiene un identificador único ... UML...

Documents

Transcript of Ingeniería del Software - falconmarbella.com€¦Cada objeto tiene un identificador único ... UML...