Diseños estructurales usando uml con clases de análisis y modelos de diseño

Facultad de Ingeniería

Diseño de software Diseños estructurales usando UML con

clases de análisis y modelos de diseño

1

Profesor: Juan José González Faúndez [email protected]

jjegonzalezf.wordpress.com

UNIVERSIDAD NACIONAL ÁNDRES BELLO FACULTAD DE INGENIERÍA ESCUELA DE INFORMÁTICA INGENIERÍA EN COMPUTACIÓN E INFORMÁTICA

Diseños estructurales usando

UML con clases de análisis y

modelos de diseño Diseño de software

Autor: Juan José González Faúndez [email protected] http://jjegonzalezf.wordpress.com

23/04/2013




2



Tabla de contenido Diseños estructurales usando UML con clases de análisis..................................................................................... 3

Problemas del OO en aplicaciones web ............................................................................................................ 3

Reglas generales para las clases de análisis ...................................................................................................... 5

Ejemplo: Sistema de administración de campeonatos de juegos de mesa ........................................................ 6

Organización del modelo de análisis ................................................................................................................ 8

Mejores prácticas de sintaxis para diagramas de clases .................................................................................... 9

Mapeando clases de UML al lenguaje Java ..................................................................................................... 13

Implementación en pseudo-código Java ..................................................................................................... 14

Propiedades derivadas ............................................................................................................................... 14

Enumeraciones .......................................................................................................................................... 15

Generalización (Herencia) .......................................................................................................................... 15

¿Cuándo evitar la generalización? .............................................................................................................. 16

Clasificación versus generalización ............................................................................................................. 16

Interfaces versus clases abstractas ............................................................................................................. 17

Atributos a nivel de clases (Static) .............................................................................................................. 18

¿Cómo expresar restricciones? ................................................................................................................... 18

Clases de análisis para la administración de campeonatos.......................................................................... 21

Tabla de Ilustraciones .................................................................................................................................... 25

Bibliografía y webliografía .............................................................................................................................. 26




3



Diseños estructurales usando UML con clases de análisis

Una clase encapsula:

• Atributos de una clase (instancia)

• Operaciones realizadas en una clase (instancia)

Apropiado para sistemas embebidos donde:

• Las clases están relacionadas fuertemente a objetos reales del sistema (Ej. OrdenCompra)

• Las operaciones están fuertemente relacionadas a una única clase. Ej. aprobarOrdenCompra()

• Las operaciones corresponden a operaciones reales. Ej. aprobarOrdenCompra() aprueba una orden de

compra real.

Las vistas del método tradicional Orientado a Objetos resultó ser un poco problemática (especialmente en

aplicaciones web).

Problemas del OO en aplicaciones web

¿Dónde ponemos la funcionalidad del negocio? ¿Dónde especificamos el comportamiento de las páginas web?

BCE (Boundary Control Entity) es una simplificación del patrón MVC (Model View Controller). BCE define el

sistema usando 3 tipos de clases: entities, controls y boundarys, estos son estereotipos oficiales de UML, y usa

iconos especiales para poder representarlos.

Ilustración 1, ejemplo de diagrama BCE

Entities




4



Las entidades son objetos que representan información del sistema: Cliente, Producto, Transacción, Cita,

Paciente, Médico,… Ejemplo: almacenamiento en base de dato.

Boundarys

Los límites son los objetos que interactúan con los actores del sistema: UserInterface, DataBaseGateway,

ServerProxy, etc. Ejemplo: un formulario de Windows, una página web, una entrada a través de un dispositivo

móvil, etc.

Controls

Los controles son objetos que median entre los límites y las entidades. Ellos orquestan la ejecución de

comandos que vienen desde los límites (boundarys), al interactuar con los objetos de entidad. Los controles

suelen corresponder a los casos de uso y se pueden relacionar o mapear con los controladores de casos de uso

(use case controllers) en el modelo de diseño. Encapsulan la funcionalidad del negocio.

Este tipo de modelo fue propuesto en la metodología de Rational RUP (Rational Unified Process).




5



Reglas generales para las clases de análisis

Restricciones estructurales para clases de análisis

Entity: solo atributos (Métodos get/set/find)

Control: solo métodos: (al menos) un método / Caso de uso

Boundary: ambos, métodos y atributos.

Relaciones entre clases de análisis (layers/capas)

• Los actores acceden solamente a través de las interfaces (boundaries)

• Una clase boundary para cada relación Actor-Caso de uso

• Las Entities son solamente accedidas por los objetos de control.

• Los objetos de control se pueden comunicar con todas las entidades, boundaries, y otros objetos de

control.




6



Ejemplo: Sistema de administración de campeonatos de juegos de mesa

Requerimientos verbales

• Diseñar un sistema para organizar los campeonatos de juegos de mesa (chess, go, backgammon, etc.)

• Requerimientos:

o Un jugador debe registrarse e iniciar sesión en el sistema antes de usarlo.

o Cada jugador registrado puede ver un campeonato.

o Cada jugador tiene solamente permitido organizar un único campeonato a la vez.

o Los jugadores pueden entrar a los campeonatos a través de una página web.

o Cuando un número suficiente de participantes está presente, el organizador comienza el

campeonato.

o Después de comenzar el campeonato, el sistema debería automáticamente crear los

emparejamientos usando un método de selección del tipo round-robin.

o Si el campeonato no ha comenzado aún (Ej.: el número de participantes no tiene el nivel

mínimo), el organizador puede cancelar el campeonato.

o El juego actual es jugado entre clientes existentes, los cuales está fuera del alcance del sistema.

o Ambos jugadores deberían reportar los resultados y las movidas después de cada juego usando

un formulario web. Una victoria obtiene 1 punto, un empate medio (1/2), y una pérdida 0.

o Si los jugadores reportan resultados contradictorios, el organizador debe juzgar quién es el

ganador. La organización debe penalizar al jugador por hacer trampas con una pena de 1 punto.

o Cuando todos los juegos se terminan, el organizador debe cerrar el campeonato con el anuncio

del ganador. Luego, él o ella puede comenzar a organizar un nuevo campeonato.

o Un juego debería estar terminado en un plazo determinado (límite de tiempo).

o Si ninguno de los dos jugadores han reportado el resultado dentro de este plazo, ambos

jugadores son considerados como perdedores.

o Si sólo un jugador ha informado el resultado, a continuación, su (o sus) versión se considera que

es el resultado oficial.




7



Ilustración 2, diagrama de casos de uso

Ilustración 3, BCE con algunas interfaces y el proceso de gestión de usuarios

uc Use case model

Sistema de gestión de campeonatos de juegos de mesa

Organizador

Jugador

Anunciar campeonato

Cancelar campeonato

Comenzar campeonato

Crear emparejamientos

Cerrar campeonato

Ingresar a un campeonato

GestionarCampeonato

«include»

«extend»

«extend»

«extend»

«extend»

analysis BCE

Formulario LoginUsuario

Formulario RegistroUsuario

Formulario deInicio/Bienvenida

Gestión del Usuario

registrarUsuario()loginUsuario()bienvenidaUsuario()

Jugador

Gestión del usuario

gestiona




8



Ilustración 4, organización de las vistas

Organización del modelo de análisis

• Package de administración de campeonatos

o Package de elementos de análisis

� Entity clases

� Control clases

� Boundary clases

� Enumerations

� Subpackages

o Colaboraciones

• Package de administración del juego

• Package de administración del usuario

analysis BCE_Boundaries

FormAdministracionCampeonatos

FormJugadorIngresaCampeonato FormOrganizadorCerrarCampeonato

VistaUsuarioParticipantes FormOrganizadorComenzarCampeonatoFormOrganizadorCancelarCampeonato

VistaUsuarioTablaPosiciones FormOrganizadorAnunciarCampeonato




9



Ilustración 5, organización del modelo de análisis

Mejores prácticas de sintaxis para diagramas de clases

1. Limitar el número de clases en un único diagrama. Es mejor dividir los grandes diagramas en algunos

más pequeños. MODULARIZACIÓN PUES! ☺

2. Nombrado:

a. Clases: nombre específico del DOMINIO.

b. Operaciones: con un verbo de acción fuerte.

c. Atributos: nombre descriptivo

3. Nivel de detalle

a. Analysis-level vs. Design-level

b. NO LOS MEZCLE! Son perspectivas distintas

4. Disposición preferible de relaciones

a. Asociaciones: horizontal

b. Generalizaciones: vertical

pkg Organizador

Administración de Campeonatos

Administración del juego

Administración del usuario




10



Ilustración 6, guía de notación para diagramas de clase

Propiedad = asociación + atributo

class DomainModel Basi...

Campeonato

Jugador

Propiedades como asociaciones

«primitive»String

Estas notaciones son formalmente equivalentes

+organizador

1

+campeonatos *

participantes

+jugadores *

+nombre




11



Mejor práctica: Propiedades de las clases versus clases definidas por el usuario

Ilustración 7, Propiedades de las clases versus clases definidas por el usuario

Una variable de un tipo de clase - como un String (no confunda con string – minúscula-) – almacena objetos de

su clase de forma distinta de cómo lo hacen las variables de tipos primitivos - como int o char – estos guardan

sus valores. Cada variable, en tanto si es de un tipo primitivo o de un tipo de clase, se implementa como una

ubicación en la memoria del ordenador. Para una variable de un tipo primitivo, el valor de la variable se

almacena en la ubicación de memoria asignada a la variable. Por lo tanto, si una variable entera se declara como

"int x = 3", entonces cuando vamos a mirar a la posición de memoria de la "x", habrá un "3" almacenado allí

justo como se esperaba.

Sin embargo, una variable de un tipo de clase sólo almacena la dirección de memoria donde se encuentra el

objeto - y no los valores dentro del objeto. Por lo tanto, si tenemos una clase llamada "Cliente", cuando se crea

un objeto como este: "Cliente unCliente", entonces cuando nos fijamos en "unCliente" en la memoria, veremos

que no almacena ninguna de las variables que pertenecen para ese objeto en la memoria. En cambio, la variable

"unCliente" sólo almacena una dirección de memoria en otro lugar en el que todos los detalles de "unCliente"

residen. Esto significa que el objeto nombrado por la variable se almacena en algún otro lugar de la memoria y la

variable sólo contiene la dirección de memoria de donde está almacenado el objeto. Esta dirección de memoria

se denomina una referencia al objeto, un apuntador.

Un valor de un tipo primitivo - como un tipo int - siempre requiere la misma cantidad de memoria para

almacenar un valor. Hay un valor máximo de tipo int - lo que significa que los valores de tipo int tendrán un

límite de su tamaño. Pero - la gran diferencia entre un tipo primitivo y un tipo de clase es que un objeto de un

tipo de clase, como un objeto de la clase String, puede ser de cualquier tamaño. La ubicación de memoria para

una variable de tipo String (un tipo de clase) es de un tamaño fijo, por lo que no puede almacenar una cadena

gigantesca como uno que es 3.000 caracteres. Pero, se puede y se almacena la dirección de cualquier cadena ya

que hay un límite para el tamaño de una dirección. Así, recuerda que una variable de un tipo de clase almacena

una dirección del objeto, y no el valor de ese objeto - que se almacenan en esa dirección en la memoria a través

de una referencia.




12



¿Qué es lo que huele a un mal diseño acá?

¿Y acá?


Campeonato

- organizador: Jugador

Jugador

+campeonatos *

participantes

+jugadores *


Campeonato

- organizador[]

ListaJugadores

Jugador

+campeonato 1

jugadores

+listaJugadores 1

+jugador *

contenidos

1

• Las propiedades de una clase definida por el usuario deben ser denotadas explícitamente.

- OK, si la multiplicidad es 1

• Nombres de las asociaciones: - Preferible usar verbos a sustantivos - OK: participaEn, participaDe

• Nombres de los roles: - 1: singular

- *: plural - OK: jugadores, campeonatos

• Arreglos en los atributos - Solución:

Una asociación organizado

• Listas Explícitas -Solución: Una única asociación juegaEn

• NOTA: Las listas y arreglos son construcciones de programación y no elementos de dominio!




13



Ilustración 8, Versión mejorada del modelo de dominio

Mapeando clases de UML al lenguaje Java

UML Java

Clase Class Atributo Atributo (Campo, Propiedad) Asociación 0..1 Atributo (Campo, Propiedad) Asociación 0..* Collection<<Class>>; List<<Class>>; ArrayList<>;etc. Agregación Atributo Operación Método (ej.: void) Restricciones Aseveraciones (Assertions)


Campeonato

Jugador

Juego

NOTA: El juego no está completamente definido en este diagrama

1

juegaComoBlack

+jugadorBlack

0..1

1

juegaComoWhite+jugadorWhite

0..1

+juegos

*

juegaEn+campeonato

1

+organizarCampeonato *

organizado

+organizador 1

+campeonatos

*

participaEn

+jugadores

*




14



Implementación en pseudo-código Java

class Campeonato { private String nombre; private Jugador organizador; private List jugadores; } ¿Cómo seteamos atributos normales?:

this.setNombre(nuevoNombre);

¿Cómo seteamos colecciones o listas?

this.getJugadores().add(player);

player.getCampeonatos().add(this);

¿Cómo automatizamos esto?

A investigar! ☺ tip: code generation

Propiedades derivadas

• Una propiedad derivada puede calcularse a partir de los demás (otros atributos)

• Consecuencia: no necesita ser persistido

• Ejemplo: añoActual – añoNacimiento. Para calcular la edad de una persona


Campeonato

- nombre: String- minParticipantes: Integer- maxParticipantes: Integer- Estado: EstadoCampeonato

Jugador

Juego+campeonatos

*

participaEn

+jugadores

*


organizado

+organizador 1

+juegos

*

juegaEn+campeonato

1

1


0..1

1

juegaComoBlack

+jugadorBlack

0..1

class Modelo de dominio

Jugador

- cumpleaños: Integer- /edad: Integer




15



Enumeraciones

Enumeración:

• un conjunto fijo de valores simbólicos

• representada como una clase con valores como atributos

Uso:

• Frecuentemente define posibles estados

• Usar enumeraciones en lugar de cadenas literales siempre que sea posible

Generalización (Herencia)


«enumeration»EstadoCampeonato

anunciado comenzado cancelado final izado


Usuario

- nombre: String

Organizador Jugador

La clase padre es más general que las clases hijas

Objetivo: Levantar atributos y métodos comunes a la superclase




16



¿Cuándo evitar la generalización?

Clasificación versus generalización

1. Fido es un Poodle

2. Un Poodle es un Perro

3. Los Perros son Animales

4. Un Poodle es una Raza

5. Un Perro es una Especie


Campeonato

CampComenzado CampFinalizado

Campeonato

- estado: EstadoCampeonato

«enumeration»EstadoCampeonato

anunciado comenzado finalizado cancelado

• ¿Qué sucede si un campeonato

comenzado es finalizado?

• Problema: Retipado

(modificación de un tipo) de un

objeto es requerido

• NOTA:

Usar un atributo de estado con valores

de enumeración para almacenar el

estado de un objeto que puede

cambiar.

� 1+2 = Fido es un Perro

� 1+2+3 = Fido es un Animal

× 1+4 = Fido es una Raza

× 2+5 = Un Poodle es una Especie

• Generalización (SupertypeOf) es

transitivo.

• Clasificación (InstanceOf) NO ES

transitivo.




17



Ilustración 9, clasificación versus generalización

Interfaces versus clases abstractas

Ilustración 10, Interfaces versus clases abstractas

class Domain Model

«interface»Collection

+ add()+ equals()

«interface»List

+ get()

Orden AbstractList

+ add()+ equals()+ get()

ArrayList

+ add()+ get()

Interface

Clase abstracta

get() -> Método abstracto

add() -> overridingLa orden REQUIERE lainterface

AbstractList IMPLEMENTA la interface

require




18



Atributos a nivel de clases (Static)

Ejemplo: como buscar un Jugador

¿Cómo expresar restricciones?

Un problema simple de modelamiento

• Un componente agrega puertos con las siguientes restricciones.

• Disjunción: un puerto puede ser

o Puerto de entrada o

o Puerto de salida

o Pero no ambos

• Integridad:

Todos los puertos son categorizados en estos dos grupos.

• Debemos ser capaces de recoger puertos de entrada y salida por separado de un componente

• Use atributos a nivel de clases para

almacenar todas las instancias.

• Aceptable en java puro

• NO en aplicaciones web

• Use un contenedor distinto

(Singleton)

o create

o find

o delete

• Content

o Get/Set




19



Restricciones con generalización

Restricciones con OCL (Object Constraint Language)

Ventajas:

• Los puertos de entrada y salida son

disjuntos.

• Revisión de tipado (type checking)

Desventajas:

• El tipo de un puerto no puede ser

cambiado después de haberse creado

• ¿Operaciones comunes para puertos de

entrada y salida?

Ventajas:

• Los tipos de un puerto pueden ser

cambiados dinámicamente

Desventajas:

• Las restricciones son necesarias para

expresar:

o Disjunción de los puertos de

entrada y de salida

o Integridad de los puertos de

entrada y de salida

• Falta de comprobación de tipos




20



Restricciones con enumeraciones + atributos

Ventajas:

• Disjunción

• Completo

• Cambios dinámicos

Desventajas:

• El tiempo de acceso de los puertos de

entrada/salida se incrementa

• Falta de comprobación de tipos




21



Clases de análisis para la administración de campeonatos

Casos de uso para la administración del usuario

Ilustración 11, CU administración de usuarios

Clases de análisis para la administración del usuario

Ilustración 12, administración de usuarios usando BCE

uc CU Usuarios

Usuario

Registrar usuario

Login usuario

Bienvenida usuario

Login falló

Login sin registrarse

Password mal escrita

«extend»

analysis Clases análisis Adm Usuarios

Form Login Usuario

Form Registro Usuario

Form BienvenidaUsuario

Administración usuario Jugador

inicia la funcionalidad del negocio

administra




22



Clases de análisis (usando un modelo de dominio estereotipado) para la administración del usuario

Ilustración 13, Clase de análisis usando un domain model estereotipado

Caso de uso Administración de los campeonatos

Ilustración 14, CU administración de campeonatos

class Clases análisis Adm Usuarios (Domain)

«UI»Form Login Usuario

«UI»Form Registro usuario

«UI»Form Bienvenida

Usuario

«Controlador»AdmUsuario

+ registrarUsuario() : void+ loginUsuario() : void+ bienvenidaUsuario() : void

«entidad»Jugador

- userName: String- password: String- realName: String- birth: Integer- /age: Integer

inicia funcionalidad de negocio

maneja/controla

uc CU Adm campeonatos

Jugador

(from Casos de uso)

Organizador

(from Casos de uso)

(from Casos de uso)

Anunciar campeonato

(from Casos de uso)

Cancelar campeonato

(from Casos de uso)

Comenzar campeonato

(from Casos de uso)

Crear emparejamientos

(from Casos de uso)

Cerrar campeonato

(from Casos de uso)

Ingresar a un campeonato

«include»




23



Modelo de dominio

Ilustración 15, Domain Model Administración de campeonatos

Caso de uso administración del juego

Ilustración 16, CU administración del juego

Clases de análisis Administración del juego


Campeonato

- nombre: String- minParticipantes: Integer- maxParticipantes: Integer- Estado: EstadoCampeonato

Jugador

Juego+campeonatos

*

participaEn

+jugadores

*


organizado

+organizador 1

+juegos

*

juegaEn+campeonato

1

1


0..1

1

juegaComoBlack

+jugadorBlack

0..1

uc CU Adm Juego

Jugador

Organizador

Reporta resultado del Juego

Juzga el resultado

Autoriza al organizador

Rev isa el juego

«include»

«include»

class Clases análisis Adm Juego

«UI»FormJugadorReportaResultado

«UI»FormOrganizadorJuzgaResultado

«Controlador»AdmJuego

+ reportarResultado() : void+ juzgarResultado() : void+ autorizarOrganizador() : void+ revisarJuego() : void

«entidad»Resultado

- movidas: String- resultado: TipoResultado

«entidad»Juego

- fechaTope: Date




24



Modelo de dominio Administración del juego

Ilustración 17, Domain Model reportar resultados en la administración del juego

class Clases entidad Adm Juego

Resultado

- movidas: String- resultado: TipoResultado

Juego

- fechaTope: Date

«enumeratio...TipoResultado

ganaBlanco ganaNegro Empate

+resultadoBlanco 0..1

reportadoPorBlanco

1

+resultadoFinal

0..1 reportadoPorOrganizador 1

+resultadoNegro 0..1

reportadoPorNegro

1




25



Tabla de Ilustraciones Ilustración 1, ejemplo de diagrama BCE ......................................................................................................................... 3

Ilustración 2, diagrama de casos de uso ......................................................................................................................... 7

Ilustración 3, BCE con algunas interfaces y el proceso de gestión de usuarios .................................................................. 7

Ilustración 4, organización de las vistas .......................................................................................................................... 8

Ilustración 5, organización del modelo de análisis .......................................................................................................... 9

Ilustración 6, guía de notación para diagramas de clase ................................................................................................ 10

Ilustración 7, Propiedades de las clases versus clases definidas por el usuario ............................................................... 11

Ilustración 8, Versión mejorada del modelo de dominio ............................................................................................... 13

Ilustración 9, clasificación versus generalización........................................................................................................... 17

Ilustración 10, Interfaces versus clases abstractas ........................................................................................................ 17

Ilustración 11, CU administración de usuarios .............................................................................................................. 21

Ilustración 12, administración de usuarios usando BCE ................................................................................................. 21

Ilustración 13, Clase de análisis usando un domain model estereotipado ...................................................................... 22

Ilustración 14, CU administración de campeonatos....................................................................................................... 22

Ilustración 15, Domain Model Administración de campeonatos .................................................................................... 23

Ilustración 16, CU administración del juego .................................................................................................................. 23

Ilustración 17, Domain Model reportar resultados en la administración del juego ......................................................... 24




26



Bibliografía y webliografía

http://www.inf.mit.bme.hu/sites/default/files/materials/category/kateg%C3%B3ria/oktat%C3%A1s/msc-

t%C3%A1rgyak/modellalap%C3%BA-szoftvertervez%C3%A9s/

MACIASZEK, L.A. (2007): Requirements Analysis and System Design, 3rd ed. Addison Wesley, Harlow England.

ISBN 978-0-321-44036-5

Diseños estructurales usando uml con clases de análisis y modelos de diseño

Education

Transcript of Diseños estructurales usando uml con clases de análisis y modelos de diseño