GUÍA DE CLASES PRÁCTICAS de Metodología Orientada a Objetos...

Universidad de Oviedo Escuela Universitaria deDepartamento de Informática Ingeniería Técnica en Informática de Oviedo

METODOLOGÍA DE LA PROGRAMACIÓN II

PROFESOR: Wenceslao López Enero- 2.001

GUÍA DE CLASES PRÁCTICASde

Metodología Orientada a Objetosv 1.01

GUÍA DE CLASES PRÁCTICAS DE MPII

EUITIO-WLM 09/04/03 2

La presente Guía tiene como objetivo definir de forma ordenada lasdiferentes tareas que es necesario realizar para construir unaaplicación utilizando la Tecnología Orientada a Objetos, a partir delos conocimientos teóricos adquiridos por el alumno en lascorrespondientes clases teóricas de la asignatura.

Esta Guía esta integrada por tres partes:1. Guía de aplicación de la MOO, con la descripción de cada uno de los

productos que el diseñador va generando de forma incremental en cadafase del ciclo productivo.

2. Ejemplos de casos utilizando la Guía expuesta.3. Guía resumida de la herramienta Rose y su relación con la metodología

expuesta.



INDICE.-1 DIAGRAMA DE ACTIVIDADES........................................................................................................5

2 INDICE DOCUMENTACIÓN..............................................................................................................7

3 R01: DESCRIPCIÓN DEL PROBLEMA............................................................................................9

3.1 DESCRIPCIÓN................................................................................................................................93.2 CONSTRUCCIÓN.........................................................................................................................10

4 R02: CASOS DE USO Y ESCENARIOS. ..........................................................................................11

4.1 DESCRIPCIÓN..............................................................................................................................114.2 DIAGRAMA DE CASOS DE USO:..............................................................................................134.3 DESCRIPCIÓN DE CASOS DE USO Y ESCENARIOS .............................................................164.4 EJEMPLOS. ...................................................................................................................................18

5 MODELADO ESTRUCTURAL:........................................................................................................24

5.1 COMPONENTES BASICOS.........................................................................................................245.2 RELACIONES BASICAS. ............................................................................................................25

6 A01: DIAGRAMA DE CLASES (ANÁLISIS)...................................................................................26

6.1 DESCRIPCIÓN..............................................................................................................................266.2 CONSTRUCCIÓN. ........................................................................................................................29

6.2.1 CLASIFICADORES:...............................................................................................................296.2.2 Relaciones: .............................................................................................................................32

6.3 EJEMPLOS. ...................................................................................................................................38

7 A02:DIAGRAMA DE INTERACCIÓN DE OBJETOS...................................................................41

7.1 DIO/DSS ........................................................................................................................................417.1.1 DESCRIPCIÓN. .....................................................................................................................417.1.2 CONSTRUCCIÓN ..................................................................................................................43

7.2 DIAGRAMAS DE COLABORACIÓN. ...................................................................................................457.3 EL CASO DEL PALE AUTOMATIZADO.- ................................................................................47

8 A03 : DIAGRAMA DE ESTADOS DE LAS CLASES .....................................................................49

8.1 DESCRIPCIÓN..............................................................................................................................498.2 CONSTRUCCIÓN.........................................................................................................................518.3 EJEMPLOS ....................................................................................................................................568.4 DIAGRAMAS DE ACTIVIDAD. ...........................................................................................................57

8.4.1 Ejemplos .................................................................................................................................588.4.2 Acciones..................................................................................................................................598.4.3 Subactividades........................................................................................................................598.4.4 Líneas de clasificación. ..........................................................................................................608.4.5 Estados de sincronización. .....................................................................................................608.4.6 Pasos para realizar un Diagrama de Actividad:...................................................................61

9 A04:DESCRIPCIÓN DE CLASES.....................................................................................................62

9.1 DESCRIPCIÓN..............................................................................................................................629.2 CONSTRUCCIÓN.........................................................................................................................63

9.2.1 Ejemplo: .................................................................................................................................63

10 A05: ANÁLISIS DIAGRAMA DE FLUJO IU ..............................................................................65


11 A06: ANÁLISIS DETALLADO IU. ...............................................................................................67


12 D01: MODELO DE SUBSISTEMAS .............................................................................................70



12.1 DESCRIPCIÓN..............................................................................................................................7012.2 CONSTRUCCIÓN.........................................................................................................................7212.3 EJEMPLOS ....................................................................................................................................7312.4 AMPLIACIÓN AL MODELADO DE SUBSISTEMAS:..............................................................75

12.4.1 Particionado Vertical:............................................................................................................7512.4.2 Particionado Horizontal: .......................................................................................................78

13 DO2: DISEÑO DEL MODELO DE OBJETOS. ...........................................................................79

13.1 DESCRIPCIÓN..............................................................................................................................7913.2 AMPLIACIÓN AL DISEÑO DEL MODELO DE OBJETOS: ......................................................................81

13.2.1 Representación de asociaciones. ............................................................................................8113.2.2 Restricciones: .........................................................................................................................84

14 D03: DISEÑO DEL DIAGRAMA DE SECUENCIA/DIO ...........................................................86

14.1 DESCRIPCIÓN..............................................................................................................................8614.2 CONSTRUCCIÓN.........................................................................................................................8714.3 EJEMPLO ......................................................................................................................................88

15 D04: DISEÑO DEL DTE .................................................................................................................89


16 D05: DESCRIPCIÓN DE CLASES................................................................................................91


17 D06: PLAN DE EMPAQUETAMIENTO. DIAGRAMA DE MÓDULOS .................................94


18 I01: DIRECTRICES DE CODIFICACIÓN ..................................................................................96


19 I02: CÓDIGO FUENTE ..................................................................................................................98


20 P01: PLAN DE PRUEBAS ............................................................................................................100

20.1 DESCRIPCIÓN............................................................................................................................10020.2 CONSTRUCCIÓN.......................................................................................................................101

21 P02: CASOS DE PRUEBA ............................................................................................................102

21.1 DESCRIPCIÓN............................................................................................................................10221.2 CONSTRUCCIÓN.......................................................................................................................103

22 TABLA DE IMPACTOS:..............................................................................................................104

23 GUÍA RESUMIDA DE ROSE.......................................................................................................105

23.1 INTRODUCCION.- .....................................................................................................................10523.2 CATEGORÍA DE CLASES :.......................................................................................................10623.3 COMENZAR CON ROSE: ........................................................................................................10723.4 EN ROSE : DIAGRAMA DE CASOS DE USO .........................................................................11423.5 EN ROSE : DIAGRAMA DE CLASES. ......................................................................................11623.6 EN ROSE : DIAGRAMA DE ESCENARIOS.............................................................................12123.7 EN ROSE : DIAGRAMA DE ESTADOS. ...................................................................................12523.8 EN ROSE : DIAGRAMA DE MÓDULOS ..................................................................................126

24 BIBLIOGRAFÍA.-..........................................................................................................................131



1 Diagrama de Actividades.

A continuación se presenta el Diagrama de Flujo de Actividades arealizar para el desarrollo de una Aplicación utilizando la MOO, en elcual distinguimos:

1. Actividades: Una actividad se corresponde con una fase del ciclo defabricación.Una actividad se divide en Tareas. Una actividad serepresenta por el simbolo:

2. Tareas: Es un proceso en el que obtenemos un producto que forma partede la solución del problema. Una tarea se realiza con método y técnica.Enuna tarea se produce al menos un documento. Una tarea la representamospor el simbolo:

3. Tareas no realizables: Por no corresponder al dominio de estaasignatura. Se representa por el simbolo:

4. Secuencia: Representa la secuencia de actividades y de tareas.

5. Complementos: Simbolo para representar las actividades y tareas que secomplementan.



ModeloDeRequisitos

Casos DeUso

RequisitosNoFuncionales

DescripciónDelProblema

AnálisisModelo Objetos

DiseñoModelo Objetos

Implementación

Analisis DeEscenarios

Diagrama DeClases

DiccionarioDatos

DescripciónClases

Diagrama deClases

DescripciónClases

DirectricesCodificación

CodigoFuente

DiagramaInteracción

DiagramaEstados

DTE

Entorno

ArquitecturaSistema

DIO/DSS

PlanEmpaquet.

Casos dePrueba

Plan dePruebas

Modelo IU

Subsistemas



2 Indice Documentación

La documentación de prácticas a presentar por los alumnos, estará integradapor los documentos que se exponen a continuación.

INFORMACION COMUN A TODO DOCUMENTO DE TRABAJO:

Identificador y nombre del documento:El valor del Identificador será único para cada documento. Estará formadopor : Un carácter de prefijo que indica la fase del ciclo. Un númerocorrelativo de dos dígitos, dentro de cada fase. Dos dígitos que indican laversión de un tipo de documento de una fase del ciclo.

Consideraremos cinco fases:

1. R: Requisitos2. A: Análisis3. D: Diseño4. I: Implementación5. P: Prueba.

Indice del Documento:R: Modelo de Requisitos:

R01-01: Descripción del Problema.R02-01: Casos de Uso y Escenarios.R03-01: Requisitos no funcionales.(no se hará).R04-01: Justificación del Proyecto (no se hará).R05-01: Plan de Aceptación.(no se hará).

A:Análisis del Modelo MVCA01-01 : Diagrama de Clases.(preliminar)A02-01 : Diagrama de Interacción de Objetos(DIO). (preliminar)A03-01 : Diagrama de Estados de Objetos.(preliminar)A04-01 : Descripción de Clases (preliminar)A05-01 : Diagrama de Flujo IU. (opcional)A06-01 : Detalle IU. (opcional)

D:Diseño del Modelo MVCD01-01: Modelo de Subsistemas (opcional).D02-01: Diagrama de Clases (Diseño).D03-01: DIO/DSS(Diseño).D04-01: Diagrama de Estados de Clases(Diseño).D05-01: Descripción detallada de clases(Diseño).D06-01: Plan de Empaquetamiento:Diagrama de Módulos del Sistema.



I:Implementación del Modelo MVCI01-01 : Directrices de Codificación.I02-01 : Codigo Fuente.

P:Prueba del Modelo MVCP01-01: Plan de Pruebas.P02-01: Casos de Prueba.

G:Glosario y Diccionario de DatosG01-01: Definición de términos.

A continuación se describe el proceso de generación de cada uno de losdocumentos de trabajo requeridos, con sus características fundamentales,técnicas y metodos aplicables y la exposición de casos ejemplo.



3 R01: DESCRIPCIÓN DEL PROBLEMA

3.1 DESCRIPCIÓN.

¿QUÉ ES? (Descripción):Describe los requisitos o necesidades de una parte del mundo real. No hablade soluciones, ni de la aplicación.

¿POR QUÉ SE HACE? (Propósito):Para comunicar a cada persona involucrada en el proyecto los objetivos delmismo.

¿QUIÉN LO HACE? (Participantes):El cliente, a nivel de dirección, que tiene el problema y esta dispuesto apagar por una solución.

¿CUÁNDO SE HACE? (Calendario):Antes de empezar el proyecto.

¿CÓMO SE HACE? (Técnica):Debe de responder a : ¿Que se quiere hacer (no como) y porque?.

PUNTOS FUERTES:• Común acuerdo con los objetivos.• Identificación de objetos y comportamientos candidatos.• Identificación de las fronteras del problema.

PUNTOS DÉBILES:• Normalmente incompleto.• Normalmente incorrecto.



3.2 CONSTRUCCIÓN

NOTACIÓN:Texto.

CONSEJO Y GUÍA:• Debe ser revisado por el equipo al iniciar el proyecto.• Completarlo y corregirlo.• Consensuado al iniciar el proyecto.• Su tamaño estará entre media pagina y dos paginas.

IMPORTANCIA:Esencial.



4 R02: Casos de Uso y Escenarios.

4.1 DESCRIPCIÓN.

¿QUÉ ES?:Expresa los requisitos funcionales al máximo nivel. Consiste en:Actores : Agentes externos al sistema que interactuan directamente con él.Una misma persona puede desempeñar varios roles, en cada rol es un actor.

Casos de uso: Formas especificas de usar el sistema por los actores oviceversa.Caso de Uso: Describe una conducta observable entre el usuario y elsistema. Una conducta Observable, es toda aquella que es visibleexternamente a través de la interfase del sistema. Es un conjunto dediálogos entre el actor y el sistema para alcanzar un objetivo. El conjunto delos casos de uso definen los requisitos funcionales.

Ejemplos de Casos de Uso: Consulta de cuenta bancaria, El avión entra en elespacio controlado. Ejemplos de Actores: Cliente y Radar.

El Modelo de Casos de Uso y el Análisis de Escenarios constituyen elconjunto completo de requisitos funcionales.Los Casos de Uso se detallan con los Escenarios ( se inician en Requisitos yse completan en Análisis) y se documentan de forma textual y gráfica.

Escenario: Un Caso de Uso puede tener N escenarios. Cada escenarioidentifica una ruta del caso de uso. Tendrá un inicio y un final. Puede tenerprecondiciones y postcondiciones.

¿POR QUÉ SE HACE?:Para expresar con claridad las fronteras del problema y la funcionalidadque se espera del sistema.Para que los requisitos funcionales sean entendidos fácilmente por elcliente, los expertos del dominio y los usuarios finales, y poder así verificar(casos de prueba) su cumplimiento.

Cuando se identifica un Actor, se esta identificando la frontera del sistema ylas interfaces necesarias para su uso.Cuando se identifica un Caso de Uso, se esta describiendo como se usara elsistema por uno o mas actores o viceversa.



¿QUIÉN LO HACE?:Es responsabilidad del Director de proyecto.

¿CUÁNDO SE HACE?:Forma parte del contrato entre el cliente y el equipo de desarrollo. Debehacerse antes de cualquier compromiso.

¿CÓMO SE HACE?:A partir de la Descripción del Problema y entrevistando a usuarios y expertosdel dominio.



4.2 DIAGRAMA DE CASOS DE USO:

• Muestra las relaciónes entre los actores y los casos de uso del problema.• Las relaciones son asociaciones entre los actores y los casos de uso,

generalizaciones entre actores, extensiones e includes a través de loscasos de uso.

• Los casos de uso se encierran en un rectángulo que representa lasfronteras del sistema.

• Los enlaces unidireccionales indican quien inicia la comunicación

Ejemplo:

Catalogo telefónica

Comprobar estado

pedido

Rellenar pedido

Asignar crédito

cliente empleado

supervisor

Vendedor



Representación de casos de uso.

• Un caso de uso se representa por una elipse conteniendo el nombre delcaso de uso.

• Una palabra clave que represente un estereotipo puede colocarse sobre elnombre y debajo pueden colocarse las propiedades.

• La conducta del caso de uso puede expresarse en texto, maquinas deestado, operaciones y métodos

• Un conjunto de elipses de casos de uso, dentro de un rectángulo, conconectores a símbolos de actores.

• Cada línea entre un actor y un caso de uso representa una asociación.• Una línea discontinua con la palabra clave <<extend>> o <<include>>

representa una include o una relación extend.• El estereotipo estándar de icono para un actor es la figura de un <hombre

delgado> con su nombre debajo. Un actor también puede representarsecon el rectángulo de una clase.

Relaciones de los casos de uso.

Semántica.Hay varios tipos de relaciones posibles entre casos de uso y entre actores ycasos de uso.

• Asociación. Entre una instancia de actor y una instancia de casosde uso. Es el único tipo de relación entre ambos.

• Extensión (extend). Entre una instancia de un caso de uso A y otrainstancia de otro caso de uso B. Indica que la conducta especificadaen A condiciona o afecta a la de B. En consecuencia B requierepara ser descrito una extensión (la conducta de A).

• Generalización. Una generalización del caso de uso A al caso deuso B, indica que A (subcaso de uso)es una especialización de B.

• Include. Una relación include desde el caso de uso A al caso de usoB, indica que una instancia del caso de uso A también contendrá laconducta especificada en B.

Notación.• Asociación. Se muestra como una línea entre un actor y un caso de

uso. Puede ser adornada, como con multiplicidad.• Extend. La relación entre casos de uso se muestra con una línea

discontinua con flecha apuntando al caso base que se suministra laextensión. Llevará la etiqueta <<extend>>.



• Include. Esta relación se muestra también con una líneadiscontinua, pero con la flecha hacia el caso no base.

• Generalización. Se muestra con una línea continua y la flechaapuntando al caso de uso padre.

Ejemplo.

Relaciones del Actor.

Semántica.Hay una relación estándar entre actores y una entre actores y casos de uso.

• Asociación. Es la participación de un actor en un caso de uso. Estaes la única relación entre actores y casos de uso.

• Generalización. Una generalización de un actor A a otro B, indicaque una instancia de A puede comunicarse con los mismos casos deuso que B.

Notación.• Asociación. Se muestra como una línea. Entre actor y caso de uso.• Generalización. Se muestra como una línea con flecha que apunta

al actor más general.

Suministrar datos delcliente

Realizar pedido

Requerircatalogo

<<include>>

<<extend>>

vendedor



4.3 DESCRIPCIÓN DE CASOS DE USO Y ESCENARIOS

Conviene definir la prioridad relativa de cada Caso de Uso, por parte delcliente y de los usuarios. Esta asignación de prioridades permitirá a losplanificadores construir El Plan de Desarrollo para optimizar el uso de losrecursos frente a los resultados.

Cada caso de uso debe de describirse de forma textual, en un formulario queal menos debe de contener:

Nombre del caso de uso 1:Definición:notas:

Prioridad.-Importancia(1:vital, 2:importante, 3:Conveniente):Urgencia(1:Inmediata, 2:Necesario, 3:Puede esperar):

Nombre de Actor:Definición:notas:

Cada Caso de Uso contendrá Nec Escenarios:Nombre de Escenario 1.1:Precondiciones:Iniciado por:Finalizado por:Post-condiciones:Detalle operaciones:Excepciones:

Como resumen se puede preparar una matriz con los casos de uso encolumnas y los actores en filas, marcando la intersección de la relación.

Los pasos a realizar son:1)Lista de actores. Número de actores: Na.2)Lista de casos de uso (puede haber caso principal y sub-casos).Número de casos de uso : Nc

3)Por cada actor identificar sus casos de uso.4)Por cada Caso de Uso identificar sus Escenarios.Número de Escenarios: Nec



5)Detallar secuencia de operaciones(normales y excepción) que ocurren deforma externa en cada escenario .6)Analizar el impacto de las excepciones en el caso de uso.7)Analizar si hay partes comunes en los diferentes Casos de Uso.(Los pasos 4 al 7 se pueden completar en el Análisis).

PUNTOS FUERTES:Es un prerrequisito del proceso de ingeniería, en especial del análisis deescenarios, así como de su claridad.

NOTACIÓN:Texto, Matriz y Diagrama.

GUÍA Y CONSEJO:• Involucrar al cliente, expertos del dominio y usuarios finales en la

formulación y revisión del Modelo de Caso de Uso.• Todo el proceso debe de apoyarse en el Modelo de Caso de uso, en

particular el análisis.• Elaborar pruebas de aceptación en base al Modelo de Caso de uso.• El Modelo de Caso de Uso y el Análisis de escenarios son

complementarios, no debiendo duplicarse información.• Cada caso de uso y actor no debe de llevar mas de una página y un día de

trabajo.

VERIFICACIÓN:• Actores y Casos de Uso deben de estar conectados correctamente,

considerando todos los roles de cada actor en los diferentes casos de uso.• Verificar que el Modelo representa las fronteras del sistema.• La descripción de cada Caso de Uso debe de centrarse en la

funcionalidad visible y no en la conducta interna del sistema.

IMPORTANCIA:Absolutamente esencial



4.4 EJEMPLOS.

EL CASO DE LA GESTION DE RECEPCION FAX:

R01-01.-Descripción del Problema.

Un Departamento de una empresa quiere automatizar la recepción,distribución y control de los faxes que se reciben. Desea que sus empleadossean informados de forma automática cuando han recibido un fax y quepuedan consultarlo, así como consultar si están recibiendo alguno en esemomento. El sistema sera controlado por un empleado administrador, quedebe ser informado de la actividad del sistema y de estadísticas de recepción,el cual tendrá además como responsabilidad el mantenimiento del registrogeneral de recepciones para su distribución y el de identificación deremitentes habituales.

R02-01.-Modelo de Casos de Uso.

Diagrama de casos de uso.



DESCRIPCIÓN DEL CASO DE USO:

Nombre del caso de uso 1:Recepción de Fax.Definición: La recepción de Fax intentara identificar el remitente, eldestinatario y el tema, (mediante la lectura óptica de la portada), paraproceder de forma automática a su clasificación, distribución y preparaciónde informes estadísticos. Cuando no sea posible realizar la identificación seraincorporado a una lista de pendientes de clasificación. Nombre de Actor: Fax.Definición: Máquina receptora de faxes que los envía al sistema.

Nombre de Escenario 1.1: Recepción completa con reconocimiento deremitente, destinatario y tema.Iniciado por: Fax.Finalizado por: Informe al destinatario.Detalle operaciones:- Almacenamiento clasificado del fax.- Incorporación a informes y estadísticas del administrador.- Informar al destinatario de la llegada del fax.

Nombre de Escenario 1.2: Recepción completa sin reconocimiento.Iniciado por: Fax.Finalizado por: Informe al administrador.Detalle operaciones:- Almacenamiento del fax en pendientes de clasificar.- Informar al administrador de la llegada del fax.

Nombre de Escenario 1.3: Recepción incompleta de fax.Iniciado por: Fax.Finalizado por: Informe al administrador.Detalle operaciones:- Almacenamiento del fax en incompletos.- Informar al administrador de la llegada de fax incompleto.



EL CASO DEL ALMACÉN AUTOMATIZADO.

R01-01.-Descripción del Problema.

En el almacén todas las cargas que hay están situadas en pales, los cuales semueven utilizando carros automáticos.Un técnico puede ordenar a un carro que mueva un pale a otra posición.Por otra parte Gestión de operaciones, tiene fijada la regla de que después de"n" movimientos de un pale, se tiene que comprobar la estabilidad de lacarga en una estación de comprobación. Este valor "n" es el mismo paratodos los pales y puede ser cambiado en cualquier momento.Si un carro quiere mover un pale por n+1 veces y el destino no es unaestación de comprobación, el pale no puede ser movido.Un pale puede ser movido antes de la n+1 vez a una estación decomprobación. En ese caso, la carga también tiene que ser estabilizada.

R02-01.-Modelo de Casos de Uso.

Diagrama de Casos de Uso

Tecnico Mover Pale(from Logical View)

Asignar "N"(from Logical View) Gestion

Operaciones



Descripción Caso de Uso:Nombre del caso de uso 1:El técnico manda al carro mover el pale a unaposición.notas: Gestión de Operaciones tiene asignado un valor a N.Nombre de Actor: Técnico.Definición: Empleado cuya función es controlar el carro que mueve lospales.

Nombre de Escenario 1.1: Destino no es estación de comprobación y elpale se ha movido < N veces.Iniciado por: Técnico.Finalizado por: Pale colocado en nueva posición.Detalle operaciones:- El técnico ordena al carro mover el pale a una cierta posición.- El carro se mueve hacia el pale.- Dado que el pale ha sido movido menos de N veces desde la ultimacomprobación, el pale puede ser movido.- El carro mueve el pale hacia la posición destino y lo deja allí.

Nombre de Escenario 1.2: Destino no es estación de comprobación y elpale se ha movido >= N veces.Iniciado por: Técnico.Finalizado por: Pale no puede ser movido.Detalle operaciones:- El técnico ordena al carro mover el pale a una cierta posición.- El carro se mueve hacia el pale.- Dado que el pale ha sido movido N veces o mas desde la ultimacomprobación, el pale no puede ser movido a una posición donde no hayauna estación de comprobación.

Nombre de Escenario 1.3: Destino es una estación de comprobación.Iniciado por: Técnico.Finalizado por: Pale colocado en estación de comprobación.Detalle operaciones:- El técnico ordena al carro mover el pale a una cierta posición.- El carro se mueve hacia el pale.- Dado que el destino es una estación de comprobación, el pale puede sermovido.

- El carro mueve el pale a la estación de comprobación y es chequeado.Nombre de Escenario 1.4: El origen es una estación de comprobación.Iniciado por: Técnico.Finalizado por: Pale colocado en nueva posición.



Detalle operaciones:- El técnico ordena al carro mover el pale a una cierta posición.- El carro se mueve hacia el pale.- La estación de comprobación libera el pale.- El carro mueve el pale hacia la posición destino y lo deja allí.



EL CASO DE LA BIBLIOTECA:

R01-01.-Descripción del problema.

Una biblioteca tiene lectores que son socios y pueden acceder a losdocumentos de la misma. Un documento puede estar directamente en unalibrería o en una carpeta, a su vez una carpeta puede estar contenida en otra oen una librería. cada socio tiene una capacidad de consulta determinada.Cuando un usuario desea acceder a un documento o a una carpeta, antes debede analizarse su cuenta de socio para determinar su capacidad de acceso, deacuerdo con las restricciones de seguridad establecidas para el documento ocarpeta. La capacidad de un socio puede ser abrir, borrar o copiar undocumento o una carpeta. Los documentos pueden también ser editados porun socio.



5 MODELADO ESTRUCTURAL:

5.1 COMPONENTES BASICOS.

Constructor Descripcion Sintaxis

clase Describe un conjunto de objetos quecomparten los mismos atributos,operaciones, metodos, relaciones ysemantica..

Interface Nombra un conjunto de operacionesque caracterizan la conducta de unelemento.

Componente Es una parte fisica y reemplazable delsistema que empaquetaimplementación y suministra larealización de un conjunto deinterfaces.

Nodo Un objeto fisico de tiempo deejecución que representa un recursocomputacional..

Limitacion Una condición o restricción semantica

<<interface>>



5.2 RELACIONES BASICAS.

Constructor Descripcion Sintaxis

Asociacion Relación entre dos o masclasificadores que involucranconexiones entre sus instancias.

Agregacion Una forma especial de asociaciónque especifica una relacion todo-parte, entre el agregado (todo) y elcomponente parte.

Generalizacion Relación de clasificación entre unelemento mas general y otroelemento más especifico.

dependencia Relación entre dos elementos delmodelo, en la que un cambio enun elemento(el independiente)afecta al otro elemento delmodelo(el dependiente)

Realización Relación entre una especificacióny su implementación



6 A01: DIAGRAMA DE CLASES (ANÁLISIS)

6.1 DESCRIPCIÓN

¿QUÉ ES?:Expresa en un Modelo Estático la descripción del problema. Al igual que elModelo de Objetos del Diseño, consiste en clases(métodos y atributos) yrelaciones entre clases. Se usan normalmente tres clases de relaciones:asociaciones, agregaciones y herencia (generalización /especialización).

Métodos de clase: Solo pueden ser invocados sobre una clase.Métodos de instancia: Solo pueden ser invocados sobre una instancia.Atributos de clase: Solo hay una copia para todas las instancias de la clase.Atributos de instancia: Cada objeto mantiene su propia copia.

Los métodos y atributos de clase llevan de prefijo el símbolo $.

¿POR QUÉ SE HACE?:Es la mejor forma de documentar los aspectos estáticos de los objetos delproblema y además es la Unidad que utilizaremos durante todo el proceso.

¿QUIÉN LO HACE?:Es tarea de arquitectos y analistas, con la participación del cliente y/oexpertos del dominio, para reducir errores en el modelo.

¿CUÁNDO SE HACE?:En primer lugar durante el análisis, pero puede ser mantenido durante eldiseño y/o la implementación si se producen cambios.

¿CÓMO SE HACE?:A partir de la Descripción del Problema, del Modelo de Casos de Uso y delos Escenarios se hace una clasificación de términos en : ROLES -SUCESOS - PROCESOS - CONTRATOS

para facilitar la identificación de objetos que satisfagan los criterios de :identidad, estado y conducta, los cuales tienen además ciclo de vida y suequivalente en el mundo real.Las tareas a realizar son:



1. Identificar las clases candidatas. (Lista de Clases Candidatas).

2. Definir cada Clase candidata con una pequeña descripción (diccionario).

3. Identificar responsabilidades. (Lista de responsabilidades).• atributos clave.• Conducta.• Agregaciones.

4. Asignar/distribuir las responsabilidades a las clases de forma equilibrada.

5. Definir Colaboraciones: Solicitud de un servicio que hace un objeto aotro. C/S.

6. Con toda la información anterior se construyen las fichas CRC. (en la tarea de Descripción de Clases, se completara la informaciónperteneciente a cada una de ellas)

CLASE:DEFINICION:

RESPONSABILIDADES COLABORACIONES

7. Conectar las Clases candidatas mediante la identificación de relaciones deasociación y especialización/generalización (herencia).(Contratos/Colaboraciones).

8. Mas adelante se comprobará su consistencia con DIO y Diagrama deestados.

9. Al final de las tareas de análisis:• Iterar hasta que el Modelo sea estable.• Actualizar las descripciones de clases.

Posteriormente puede ser necesario particionar el modelo enCategorías de clases (Booch) o Subsistemas (OMT), en cuyo caso se



realizara como paso previo al inicio del Diseño (Modelo deSubsistemas).

PUNTOS FUERTES:• Clave para capturar y comprender el dominio del problema.• Efectivo para la comunicación entre los miembros del equipo, cliente y

expertos del dominio.

PUNTOS DÉBILES:• Solo muestra relaciones estáticas.



Clase

atributos+ tributo1:entero=0

operaciones-oper1(n)

6.2 CONSTRUCCIÓN.

NOTACIÓN:

6.2.1 CLASIFICADORES:

1.- CLASES:Al ser su objetivo representar las clases y las relaciones existentes entre lasmismas en el sistema o aplicación, su mejor representación es mediante unDiagrama de Clases, que contendrá:

• Clases. (definidas en fichas CRC).• Relaciones.

- Generalización/especialización (es un tipo de).- Asociación (conocido por).- Agregación (es parte de).

• Atributos.• Conducta.

visibilidad atributo: tipo=valorvisibilidad operación( lista parámetros): retornovisibilidad: + public , - private , # protegido

Las responsabilidades u operaciones puedenordenarse:

• por orden alfabético.• por estereotipos (constructores,

destructores, actualizadores, consultores,,,)• por visibilidad:

Publico: +Privado: -Protegido: #



Clase

atributos

operaciones

n:entero=0c:carácter=a

<<interface>>

atributos+ tributo1:entero=0

operaciones+oper1(n)

2.-Interfaces:

Sirve para especificar las operaciones externas yvisibles de una clase, sin especificar suestructura interna, por consiguiente solorepresenta una parte de la clase.

Se representa en un rectángulo como la clase,pero añadiendo donde el nombre de la clase el estereotipo<<interface>> y solo se pondrán los nombres de las operaciones queson visibles externamente.

Si se usa en Diagramas de componentes entonces se representa conun circulo.

Una Interfase no tiene implementación.

3.-Clases Parametrizadas.(templates)

Es una plantilla a partir de la cual se creaninstancias de clases. Por consiguiente sirvepara definir una familia de clases. Cadaclase se obtendría asignando valores a lalista de parámetros.Se representa con la notación de clase,superponiendo en el vértice superior derecho un rectángulo con líneadiscontinua.

4.-Utilidad.

Representa un grupo de variables y/o operaciones globales.

Se representa como una clase, pero con el estereotipo <<utility>>.Pueden ser servicios comunes como SQL, API’s, etc.No se puede heredar de las utilidades.



5.-Objeto.

Se representa como una clase, sin operaciones. Se escribe elNombre del objeto en minúsculas seguido de dos puntos y el nombrede la clase.

objeto:Clase

atributos



6.2.2 Relaciones:

1,.ASOCIACIONES:

Es la relación mas simple. Representa el conocimiento de laexistencia de otros objetos, lo cual permite que un objeto use a otropara completar su tarea.

Si dos clases tienen la relación de asociación, sus ocurrencias deberánenlazarse. Estos enlaces deben verse como ocurrencias de la asociaciónentre las clases. En consecuencia estas ocurrencias de enlaces determinaranen muchos casos nuevas clases.

asociación = clase -------------> cardinalidadenlace objetoLas asociaciones tienen cardinalidad. La cardinalidad muestra como variasocurrencias de una clases pueden asociarse con una ocurrencia de otra clase.

Calificador en asociaciones.

Cuando en una relación de asociación hay multiplicidad en lacardinalidad, se puede usar un atributo o lista de atributos cuyosvalores sirvan para particionar las instancias.

La cardinalidad se representa con un rectángulo pequeño unido a laclase que tiene la cardinalidad múltiple.

Nombre asociación

Nota : en ambos extremos de la asociación: * 0..1

Banco Personacta



Clase asociación

Clase que representa una relación de asociación. La cual serepresenta como una clase unida a la relación de asociación de lasotras clases, mediante una línea discontinua.

Nombre asociación

Figurativamente hablando, la asociación es la conexión a través de la que sepasan mensajes para acceder a los servicios de otros objetos.A nivel de análisis una asociación es una relación binaria. Se recomienda nousar asociaciones de orden superior a dos.Una asociación de orden tres sepuede transformar en tres asociaciones de orden 2 (creando una nueva claseintermedia).

Banco persona

cuenta



Persona

Gestiona

TrabajaEmpresa

jefe

trabajador

empleadoempleador1..∗

∗

∗

0..1

Trabajo

Cuenta

Persona

Corporación

{Xor}

salario



2.-ESPECIALIZACIÓN.

Se conoce como una jerarquía de sub (ESPECIALIZACIÓN) /super(GENERALIZACION) relación donde las clases(sub) heredan laspropiedades (atributos y servicios) de las clases(super)

Ejemplo:

Coche "es un tipo de" vehículo, del cual hereda atributos y servicios.

3.-AGREGACIÓN.

Es una forma especial de asociación y muestra otro punto de vista enel que los objetos que representan los componentes se agregan enun objeto que representa el objeto ensamblado entero.

Si durante el análisis no se esta seguro de si una relación es asociación oagregación, dejarla como asociación.

Las agregaciones pueden clasificarse también por la cardinalidad.

Agregación1 * 1 *

1 *

Composición

El rombo se pone en la componente a dividir en partes.

VEHICULO

FURGONETACOCHE CAMION

DOCUMENTO PARRAFO FRASE

EMPRESA DEPARTAMENTO

PERSONA



Composición.

Es una relación de agregación fuerte, donde las partes existen si existe eltodo y si el todo se destruye se destruyen las partes. Se representa con elrombo en negrita. El caso de agregación típico (las partes y el todo sonindependientes) se representa con el rombo hueco.

0..1

0..*

GUÍA Y CONSEJO:• Procurar usar una notación simple y no sobrecargada. Los modelos de

objetos deberán poder ser leídos por expertos y neófitos.

• El modelo no contendrá decisiones de diseño.

• Llamar a los objetos con nombres familiares al dominio.

• Llamar las clases con sustantivos, los servicios que modifican objetos converbos en activo, los servicios que consultan objetos con verbos indicandoconsulta.

• Evitar objetos de control los cuales controlan al resto, van contra ladistribución de la funcionalidad del sistema.

• Evitar herencia múltiple.

• Eliminar objetos desconectados del Modelo de Objetos.

• Descomponer los objetos en los mas primitivos componentes que tengansignificado para el usuario.

• Dejar cualquier árbol de herencia tan limitado como sea posible, parareducir el impacto en las subclases de mas bajo nivel, de cualquiermodificación en los métodos de una superclase. Gran parte de los diseñospueden hacerse con un máximo de tres niveles.

Ventana

Barramenu

Cuerpo



• Cuando se determine la propiedad de una operación, el servicio debeasociarse con el servidor no con el cliente.

• Es mejor tener muchos objetos simples que pocos y complejos.

• El número de responsabilidades por clase deben de ser <=7+-2

VERIFICACIÓN:• Verificar que los nombres de clase son apropiados y que todas tienen:

identidad, estado y conducta.

• Verificar que la herencia siempre implique especialización.

• Verificar la simetría de las asociaciones. Que las asociaciones estén almismo nivel en la jerarquía de herencia.

• Verificar la corrección de todas las cardinalidades unitarias.

IMPORTANCIA:Absolutamente imprescindible en el análisis.



6.3 EJEMPLOS.

EL CASO DE LA GESTIÓN DE RECEPCIÓN DE FAXES

1)Clasificación términos.

2)Lista de clases candidatas.

fax

portada fax

contenido fax

registro general o almacén de faxes..

remitente.

directorio

destinatario.

temas.

estadística.

3), 4) y 5)Lista de responsabilidades, asignarlas a las clases e identificarcolaboraciones.

Clasificar faxes. --------------> portada fax-------------------->remitenteAlmacenar/recibir fax.----------> faxinformar a destinatario.--------> portada fax-------------------->directorioinformar a admin. ---------------> registro generalpreparar estadística.------------> portada fax -------------------> estadística.

6)Fichas CRC.



EL CASO DEL ALMACÉN AUTOMATIZADO

1)Lista de Clases candidatas:

carga : no tiene comportamientos diferenciados.

almacén: hay uno solo.

técnico: es agente externo.

destino: es atributo.

origen: es atributo.

movimiento: es una operación, solo seria necesario si se quisiera unhistórico.

operación.

N (nº. limite) : atributo de clase (común para todos los objetos pale).

Pale.

Carro.

Estación de comprobación.

Posición: hay diferentes alternativas, se mantiene como candidata.

2)Diccionario de datos.

Pale: Un medio para almacenar cargas que están apiladas en un almacén.Unpale puede ser movido fácilmente de una posición a otra por un carro.

Carro: Un vehículo que puede ser programado por un técnico para moversede forma autónoma de una posición a otra en un almacén. También puedemover pales de una posición a otra.

Estación de comprobación: Un dispositivo que puede recolocar una cargasobre un pale para su estabilización.



3), 4) y 5)Lista de responsabilidades, asignarlas a las clases e identificarlas colaboraciones.

mover pale a otra posición. ------------------------------->Carro------->Palecomprobar estabilidad carga.------------------------------> ECconocer el nº. limite N.---------------------------------------->Paleconocer el nº. de veces que se ha movido el pale.-->Paleconocer si en destino hay EC.------------------------------>EC o Posición.conocer posición de pale.------------------------------------>Paleconocer posición de EC.-------------------------------------->ECconocer posición de carro.---------------------------------->Carro.decidir si el pale puede ser movido--------------------->Pale---------->EC

6)Fichas CRC

Elemento almacen

Posicion

Crear ()Conocer posicion()Destruir()

Carro

Mover pale()

Estacion de comprobacion

Comprobar pale()Liberar pale()

Pale

num. de mov imientosN

Conocer num. de mov imientos()Decidir mov imiento()Anular num. de mov imientos()Acumular num. de mov imientos()



7 A02:DIAGRAMA DE INTERACCIÓN DEOBJETOS

Antes de iniciar esta tarea es necesario realizar una revisión de losEscenarios del Modelo de Requisitos, para asegurar que recoja todas lassituaciones.

7.1 DIO/DSS

7.1.1 DESCRIPCIÓN.

¿QUÉ ES?:

Los Diagramas de Interacción se presentan de dos formas diferentesy alternativas: Diagramas de Secuencia y Diagramas deColaboración.Los Diagramas de Secuencia son muy adecuados paraespecificaciones de procesos en tiempo real y que además seanescenarios complejos.En ellos se representa la secuencia temporal de las Interacciones entre losdiferentes objetos, mediante mensajes, y la duración relativa de lasoperaciones.Hay también los Diagramas de Colaboración.

Es una representación gráfica de cada escenario descrito en el Modelo derequisitos, expresado mediante la interacción de los objetos del Modelo.El DIO representa la visión dinámica del Escenario, mostrando como losdiferentes objetos que participan en el escenario colaboran para conseguir elresultado.El DIO tiene como objetivo colaborar en la comprensión del problema, nopretende definir su solución (corresponde a OOD).

¿POR QUÉ SE HACE?Suministra una visión de alto nivel de como los objetos identificados en elModelo de Objetos, interactuan entre si para hacer frente a los requisitos yverificar si se cumplen. Se usan para ayudar a descubrir clases yresponsabilidades y asignar estas a aquellas. En concreto enlaza losEscenarios con el Modelo de Objetos, facilitando además su validación.



¿QUIÉN LO HACE?:Es tarea del equipo del proyecto liderado por una analista. Es importante laparticipación del cliente y/o expertos del dominio, para facilitar lacomprensión del problema y reducir errores.

¿CUÁNDO SE HACE?:Durante la fase de Análisis, una vez que se disponga de un primer Modelo deObjetos. Tendrá que someterse a refinamiento si se producen cambios.

¿CÓMO SE HACE?:Un DIO se crea por cada Escenario, registrando como las clases del Modelode Objetos cooperan para resolver el escenario. Se registra como unasecuencia de mensajes entre objetos, que nos obliga a decidir lasresponsabilidades de cada clase o a verificar decisiones anteriores.Es frecuente que el DIO "rompa" el Modelo de Objetos, obligándonos amodificarlo.

PUNTOS FUERTES:• Es muy intuitivo y expresivo, por su facilidad para expresar la evolución

de los objetos en un escenario.• Es muy eficaz expresando los aspectos dinámicos y funcionales del

sistema.

PUNTOS DÉBILES:• Cada DIO describe solo un Escenario y puede haber cientos, en cuyo caso

habrá que hacer escenarios clave o conjunto .



7.1.2 CONSTRUCCIÓN

NOTACIÓN:Los pasos a realizar para construir un DIO son:

1)Objetos: Se identifican los objetos involucrados en el Escenario. Se ponenen la parte superior de cada línea de tiempo en minúsculas. Si es necesariorepresentar una clase se escribirán sus iniciales con mayúsculas.

2)Línea de Tiempo: Son líneas verticales, una para cada objeto. Se usan pararepresentar la secuencia de mensajes entre objetos.

3)Mensaje: Son líneas horizontales que representan las interacciones entreobjetos. Cada mensaje tiene un "emisor" y un "receptor". Los mensajespueden requerir información a un objeto o cambiar su estado. Un objetopuede enviarse a si mismo un mensaje, en cuyo caso hará las veces de"emisor" y "receptor".

Un mensaje puede ser sincrono o asíncrono.Mensaje Sincrono: El objeto emisor queda a la espera de un mensajerespuesta, que se representa por una línea de puntos con un parámetro derespuesta.Mensaje Asíncrono: El objeto emisor no queda a la espera de una respuesta.

4)Parámetro de mensaje: Un mensaje puede llevar parámetros, en cuyocaso figuraran entre paréntesis.

5)Condición: Se representa entre corchetes y significa un punto de decisiónpara un objeto. Si la condición es verdad, el mensaje relacionado se envía.En cualquier caso el objeto continua. El uso de condiciones y bucles puededeterminar usar varios DIO's.

6)Bucle. Se usan para realizar de forma repetida acciones. Se refleja en lalínea de tiempo de un objeto y tendrá una condición de loop.

7)Actividad interna: Es toda conducta interna que sea relevante para unalínea de tiempo, pero cuyos detalles de comportamiento se pueden definirmas adelante en el Diseño. El nombre de la actividad se representa entrellaves en un punto de la línea de tiempo o bien mediante un rectángulo querepresenta el ámbito del método.



GUÍA Y CONSEJO:

• Verificar que el DIO es consistente con el Modelo de Objetos. Porejemplo si la clase A envía un mensaje a la clase B, esta relación debeestar reflejada en el Modelo de Objetos (CRC) al igual que lasresponsabilidades y las colaboraciones.

• Evitar DIO excesivamente detallados, no olvidar que se esta en la fase deanálisis.

• El DIO tiene que ser consistente con su Escenario.

• No entrar en el detalle de la interfase de usuario, representarla medianteuna barra frontera.

VERIFICACIÓN:• Un rastreo de cada DIO es una técnica eficaz para verificar que el

modelo refleja la realidad.• Que hay una distribución equilibrada del sistema.• Que se producen los resultados previstos en cada DIO.• Que el proposito de cada escenario es suficiente para cada DIO.• Que no hay objetos pasivos.• Que un DIO no sobrepasa la descripción de su escenario y que no

se invaden tareas a realizar en el diseño.


Ejemplo:

interfase socio : Cuenta de Socio

libreria : Libreria

comprobar cuenta( )conectarse( )

bloquear( )

contabilizar conexion( )



7.2 Diagramas de Colaboración.

Representan las interacciones que se producen basándose en los roles quedesempeña cada objeto. Su objetivo es mostrar las interacciones en base a losroles que desempeñan los objetos. En estos no se representa el tiempo y lasecuencia debe representarse usando números.Usando Rhose, los Diagramas de Colaboración se generan automáticamentea partir de los Diagramas de Secuencia o viceversa.

Ejemplo:

Objeto1: Objeto2: Objeto3: Clase1 Clase2 Clase3

Mensaje1()

[condicion]Mensaje2(param)

Mensaje3(param)

{actividad1}

Retorno(param)

Devolucion()

{actividad1}:describe lo que hace el Objeto3 cuando recibe el Mensaje3

Socio : Cuentade Sociointerfaz

socio : Cuentade Socio

libreria :Libreria

3: contabilizar conexion( )

1: comprobar cuenta( )5:

2: conectarse( )

4: bloquear( )



EJEMPLO DE CONSTRUCCIÓN DE DIO: Una compañia de Segurosdispone de un Help-desk, al que llaman los clientes que requieren un ambiode dirección.

Escenario 2: Cliente cambia de dirección.Definición: El cambio de dirección solicitado por el cliente suponemodificar el fichero de clientes y notificarselo al agente comercial.

Precondiciones(Asumimos):El cliente que solicita el cambio existe como tal.La modificación debe de aplicarse de inmediato.

Iniciado por: El clienteFinalizado por: Dirección modificada.Operaciones:

Rosa: Carlos: FicheroCliente: Ramon: Cliente Dependiente Fichero AgMktg

CambioDirecc(nombre)

BuscaCliente(nombre)

Devolver(info)

confirmar

confirmación(info)

perdirNueva(info)

nuevainfo actualInfoCli(direccion, fecha)

actualizaCliente(nombre,



7.3 EL CASO DEL PALE AUTOMATIZADO.-

DESTINO ES EC:

EL DESTINO NO ES EC Y EL PALE SE HA MOVIDO N VECES.

carro : Carro pale : Pale ec : Estacion de comprobacion

v ista : Vista

1: Mov er pale (Pale, Posicion)

2: Decidir mov imiento (Posicion)

3: Acumular num. de mov imientos (argty pe)

4: Comprobar pale ( )


v ista : Vista

1: Mov er pale (Pale, Posicion)

2: Decidir mov imiento (Posicion)


4: Comprobar pale ( )



EL DESTINO NO ES UNA EC Y EL PALE SE HA MOVIDO < NVECES

EL ORIGEN ES EC:

carro : Carro pale : Palevista : Vista

2: Decidir movimiento (Posicion)

3: Acumular num. de

1: Mover pale (Pale, Posicion)

4:

5:


v ista : Vista

1: Mov er pale (Pale, Posicion)2: Decidir mov imiento (Posicion)


4: Liberar pale ( )

3: Anular num. de mov imientos (Pale)

5:

7:

8:



8 A03 : DIAGRAMA DE ESTADOS DE LASCLASES

8.1 DESCRIPCIÓN.

¿QUÉ ES?:Sirve para describir el ciclo de vida de una clase. Describe el estado que unaclase puede alcanzar y las transiciones que causan el cambio de estado.

Las transiciones de estado, representadas por estímulos o eventos, muestranlos cambios de estado de los objetos. El Modelo de Estados de Objetos serepresenta por un Diagrama de Transición de Estados (DTE) o por unaMatriz de Transición de Estados( una fila por estado y una columna porevento, indicando en la intersección el nuevo estado) o Tabla de Transiciónde Estados (Tiene tres columnas: Estado actual, Evento, Nuevo Estado).

Según su estado el objeto responderá de una forma u otra al mismo mensaje.

¿POR QUÉ SE HACE?:Da una visión de como un objeto reacciona ante sucesos externos, sin entraren detalles de código.Un modelo de estados es mas fácil de comprender que una descripción tipotexto y facilita conocer la naturaleza interna de una clase.

¿QUIÉN LO HACE?:Es tarea del equipo del proyecto liderado por una analista. Es importante laparticipación del cliente y/o expertos del dominio, para facilitar lacomprensión del problema y reducir errores.

¿CUÁNDO SE HACE?:Durante la fase de Análisis, una vez que se disponga de un primer Modelo deObjetos y DIO's. Se hará para aquellas clases que en el DIO se observe quetienen una significación dinámica.

¿CÓMO SE HACE?:

1. Se selecciona una clase a modelar.Aquellas que tengan un interesante y activo ciclo de vida.



2. Identificar como se inicia el objeto. Este sera un estado de transiciónprevio a un estado inicial.

3. Añadir todas las transiciones que puedan ocurrir, a partir del estadoinicial, y los estados que alcanzan.

4. Repetir este proceso para todos los estados identificados.

5. Tener en cuenta, que es valido incluir transiciones que dejan al objeto enel mismo estado (ejemplo: bucles).

6. Es aconsejable revisar si hay transiciones principales entre varios estadosen el modelo.

PUNTOS FUERTES:Aporta una visión completa de la vida de una clase y en consecuencia de suconducta.

PUNTOS DÉBILES:Solo se representa una clase de cada vez y es difícil de mostrar cambios deestado simultáneos en varias clases (ejemplo: por colaboración).



8.2 CONSTRUCCIÓN

NOTACIÓN:El DTE sirve para representar el patrón de estados y transiciones que puedenocurrir dentro de un objeto.

Inicio o creación del objeto:

Destrucción del objeto:

Flujo de cambios de estado:

Men()recibido/enviado

NO cambia el estado---->

• Se puede poner como etiqueta de la flecha: mensaje recibido o enviado,separados por /.

• Cada estado de un objeto se representa por un rectángulo con los vérticescurvos.

Representación de un mensaje o respuesta enviado a un objeto diferente:

Men()enviado[condicion]

• El mismo mensaje o respuesta pueden desencadenar una transición deestado diferente dependiendo de una cierta condición.La condición seescribe entre corchetes al fina del mensaje.

ESTADO1 ESTADO2

ESTADO1 ESTADO2

CLASE B



Relación entre los DIO's y los DTE's:

Caso de mensaje o respuesta entrante en un DIO:

Objeto DTE de clase A DTE de clase A Amensaje o

respuesta

( el mensaje entrante para el Objeto A en el DIO, se corresponderá con unode los dos casos del DTE para la Clase A ).

Caso de mensaje o respuesta saliente en un DIO:

Objeto Objeto DTE de clase DTE de clase A B A A

(en todos los casos las flechas de mensaje llevaran su etiqueta, en estosejemplo seria: "mensaje o respuesta").

Estado1

Estado2

Estado1

Estado1

Estado2

Estado1

claseB

claseA



Relación del Modelo Dinámico con las tarjetas CRC:

a)Relación de la tarjeta CRC con el DIO:

En la tarjeta CRC, la Clase A es colaboradora de la Clase B si:

A B mensaje1(arg1,...) recibido

mensaje2(arg1…)enviado

b)Relación de la tarjeta CRC con el DTE:

En la tarjeta CRC, la Clase A es colaboradora de la Clase B si:

DTE de la Clase A

Mensaje1(arg1..) recibido o respuesta mensaje2(arg1..)enviado recibida

CONSEJO Y GUÍA:• A cada estado del objeto le debe de corresponder una conducta única.• Diferenciar entre Estado de datos: que define un único valor para un

atributo y Estado de conducta: que define una única conducta expresadaen sus respuestas a un servicio.

• La transición de un estado a otro se produce por: Un suceso externo/Un sucesointerno/Una operación del sistema/Una responsabilidad del objeto.

• En cada estado hacerse la pregunta ¿Que puede ocurrir ahora?.

claseB

ESTADO1

ESTADO2



• En muchos casos una buena táctica es ponerse en situación de simular alobjeto.

• Los diagramas de estado no son necesarios para todas las clases, las habrácon poquisimos estados dependiendo del tipo de problema.

Ejemplo:

1)El objeto GestorVentanas, puede tener:

servicios/responsabilidades: abrir, cerrar, mover, minimizar y maximizar.

Estados de datos: #VentanasAbiertas =0, =1 ........... =maxEstados de conducta:

servicios disponibles:VENTANAS_NO_ABIERTAS: abrirVENTANAS_ABIERTAS: abrir, cerrar, mover, minimizar, maximizarVENTANAS_ABIERTAS_M+XIMO: cerrar, mover, minimizar, maximizar

2)Un objeto Cuenta en una aplicación bancaria:servicios/responsabilidades: retirar, depositar

Estados de datos: #saldo = 0, 1000, 20000, .......Estados de conducta: servicios disponibles:CUENTA_SIN_FONDOS: depositarCUENTA_CON_FONDOS: depositar, retirar

VERIFICACIÓN:• En cada estado, cerrar los ojos y preguntarse: "¿que me puede ocurrir

ahora?" asegurando que todas las transicciones de estado posibles estanrepresentados.

• Desde cada estado, preguntarse si es posible visitar los otros estados.• Si dos estados presentan la misma conducta, fusionarlos.

IMPORTANCIA:Opcional y muy conveniente en sistemas de tiempo real.



Ejemplo de Matriz de Transición de Estados para la clase Cuenta:

EVENTOS

ESTADOS

EMPLEADOCIERRA

CLIENTECIERRA

DepositoSaldo +

DepositoSaldo -

RetirarSaldo +

RetirarSaldo -

Abierta CERRADA CERRADA ACTIVA --------- ----------- -------

Activa CERRADA CERRADA ACTIVA ------------ ACTIVA EXCEDIDA

Excedida -- -------- ACTIVA EXCEDIDA ---- -----

Cerrada ----------- ----------- -------- --------- -------- -------

Nota: El depositar y retirar lo realiza siempre el cliente

Ejemplo de Tabla de Transición de Estados para la clase Cuenta:

ESTADOACTUAL

EVENTO NUEVOESTADO

Abierta Empleado cierra CerradaAbierta Cliente cierra CerradaAbierta Cliente deposita ActivaActiva Cliente cierra CerradaActiva Cliente deposita ActivaActiva Cliente retira(saldo-reintegro=>0) ActivaActiva Cliente retira(saldo-reintegro<0) ExcedidaExcedida Cliente deposita(saldo+deposito<0) ExcedidaExcedida Cliente deposita(saldo+deposito>=0) Activa



8.3 EJEMPLOS

DTE del Pale:

DTE CARRO:

pale movido <= N pale yendo a EC

pale en EC

mover(a)/anular N

mover(a)

falso(n>=N) verdad/aumentar N

falso(N<n)/aumentar N

carro disponible

carro ocupado

mover pale(pale,a)respuesta

frontera del sistema

pale



8.4 Diagramas de Actividad.

SemánticaDiagrama de Actividad es un gráfico que representa una secuencia deacciones o subactividades y las transiciones de estados que se disparan por larealización de aquellas.Es un caso especial de un Diagrama de Estado(aplicable a una clase), en estas el objetivo central del diagrama esrepresentar los estados(los cuales son consecuencia de acciones) y en losDiagramas de Actividad el objetivo central es reflejar las accionesactividades que son la causa de los cambios de estado.

NotaciónEl propósito es representar el flujo interno de operaciones que correspondena un Caso de Uso o a una Clase.Los Diagramas de Actividad son una alternativa a los Diagramas de Estado,estos últimos son más útiles cuando los sucesos ocurren de forma asincrona.Los Diagramas de Actividad son mas útiles en flujos de control de procesossincronos.



8.4.1 Ejemplos

Caso de uso:Persona:: Preparar bebida

[no hay café] [no]

[hay café]

[si ]

Localizar bebida

Poner café en elfiltro

Añadir Aguaal deposito

Coger tazas

Poner el filtro a lamaquina

Coger vaso decola

Hervir cafe

encender lamaquina

beber

Servir cafe

¿cola?



8.4.2 Acciones.

1 Semántica.Es un paso en la ejecución de un algoritmo o en un flujo de procesos.Es una acción de entrada y una transición de salida.

2 Notación.

Se muestra con un rectángulo con sus vértices convexos. La expresión de laacción se escribe en el interior.

3 Presentación.La acción puede describirse con lenguaje natural, pseudocódigo o código delenguaje de programación.

4 Ejemplo.

Nota: En Rose 2000 esta notación de acción se aplica a “estado” y la acciónse denomina actividad y se representan con un rectángulo con sus doslados laterales redondeados. El flujo de actividades es entre actividades yestados.

8.4.3 Subactividades.

1 Semántica.Una subactividad invoca un gráfico de actividad.Por tanto supone un anidamiento de actividades.La subactividad se finalizacuando lo es la actividad que incluye.Un gráfico de actividad puede ser invocado por varias subactividades.

2 Notación.Se muestra igual que una actividad, incluyendo un icono en el vértice inferiorderecho indicando que tiene una actividad anidada.El nombre de lasubactividad se escribe en el interior.

Presentación.La acción puede describirse con lenguaje natural, pseudocódigo o código delenguaje de programación.Decisiones

Arrancar motor



8.4.4 Líneas de clasificación.

1 Semántica.Las acciones se clasifican verticalmente de acuerdo con quien realiza cadaacción, con lo que realmente a nivel vertical las acciones de un Diagrama deactividad estarán clasificadas por los objetos que las realizan.Las líneas verticales sirven para fijar las calles o pasillos donde se realizanlas actividades de un mismo objeto o actor del caso de uso que se estarepresentando.

2 Ejemplo.

8.4.5 Estados de sincronización.No son obligatorios en los Diagramas de Actividad.

1 SemánticaPermiten establecer puntos de sincronismo entre diferentes actividades quese pueden realizar en paralelo.Permiten sincronizar las bifurcaciones y las uniones de acciones que se van arealizar en paralelo.

Cliente Vendedor Almacén

Pedir unservicio

Recoger lapetición

Preparar yEnviar el pedido



8.4.6 Pasos para realizar un Diagrama de Actividad:

1. Identificar el objetivo del flujo de trabajo ( es el caso de uso).2. Establecer la pre- (antes del inicio de la actividad) y las post-condiciones

( al finalizar la actividad), facilita clarificar la amplitud del flujo del casode uso.

3. Identificar las operaciones( actividades) y estados necesarios paraconseguir el objetivo establecido en el caso de uso.

4. Identificar quien es el responsable de hacer cada cosa. (líneas verticales).5. Conectar todos los elementos.6. Establecer decisiones en puntos donde el diagrama puede partirse en

flujos alternativos (escenarios).

Hacercimientos

Hacerestructura

Instalarsaneamiento

Hacertabiques



9 A04:DESCRIPCIÓN DE CLASES

9.1 DESCRIPCIÓN

¿QUÉ ES?:Es la suma de toda la información de cada clase producida hasta ahora en lasdiferentes tareas realizadas del análisis.

¿POR QUÉ SE HACE?:- Un documento para recoger toda la información de la clase.- Un único punto de contacto.

¿QUIÉN LO HACE?:El analista propietario de la clase.

¿CUÁNDO SE HACE?:Durante el análisis, el diseño y la implementación. Una clase podrá tener lostres niveles de información, habrá tres descripciones para la clase.La descripción de clases se inicia claramente con las CRC.

¿CÓMO SE HACE?:Se trata básicamente de diseñar un modelo para recopilar la información deuna clase.

PUNTOS FUERTES:Facilita el análisis y diseño y en especial la implementación.

PUNTOS DÉBILES:El formato.



9.2 CONSTRUCCIÓN

NOTACIÓN:Una aproximación de la información a registrar, para el ejemplo de la claseCuenta de una entidad bancaria, podría ser:

9.2.1 Ejemplo:

Nombre: Cuenta

Definición: Representa un acuerdo entre un banco y un cliente, que permiteal cliente depositar fondos en el banco, y dentro de ciertos limites retirarlos.

Responsabilidades:* Retirar fondos.* Transferir fondos a/desde la cuenta.* Mantener datos del cliente.* Consultar saldo.* Consultar rendimiento.(para cada una de las responsabilidades, en la fase de diseño, se detallaransus operaciones y aquí también se indicara las que se heredan).

Atributos clave:* Datos del cliente (nombre, dirección, etc.).* Saldo.(En esta lista de atributos también se reseñaran los que se heredan,indicándolo).

Relaciones:* Superclases: ninguna.* Subclases : CuentaAhorro, CuentaCorriente.* Asociaciones: propiedaddel(Cliente).

Estados:* Abierta.* Activa.* Excedida.* Cerrada.

Documentación:Las reglas para retirar fondos dependen del tipo de cuenta.



CONSEJO Y GUÍA:Conveniencia de disponer de herramientas para no tener que duplicar eltrabajo.

VERIFICACIÓN:- La descripción de la clase debe referirse a su proposito y no a su estructurainterna.- Que figuren todas las responsabilidades de cada clase.- Que figuren todas las relaciones y atributos de cada clase.

IMPORTANCIA:Es opcional aunque muy útil.



10 A05: ANÁLISIS DIAGRAMA DE FLUJO IU

10.1 DESCRIPCIÓN.

¿QUÉ ES?:Describe la secuencia de pantallas que el usuario espera ver para cumplir lasfunciones requeridas.Tiene una estrecha relación con los casos de uso.

¿POR QUÉ SE HACE?:Es necesario para diseñar la interfase de usuario y debe ser amigable uorientada al usuario como opuesta a orientada al programador.

¿QUIÉN LO HACE?:Analistas y usuarios finales.

¿CUÁNDO SE HACE?:Antes, durante o después del análisis. Si el componente de interfase deusuario no es muy significativo puede demorarse hasta el momento deldiseño.

¿CÓMO SE HACE?:

Una forma es:

1. A partir de la lista de escenarios, seleccionar aquellos que representan lalínea funcional principal.

2. Organizarlos por las tareas que realizan.

3. Organizar estos grupos de escenarios atendiendo a los que corresponden asesiones habituales.

4. Por cada sesión, dibujar una versión simplificada de la pantalla.

PUNTOS FUERTES:Facilita la comunicación entre el analista y los usuarios.El diseño del flujo de pantallas es un aspecto diferente al resto del diseño,que además permite desarrollo en paralelo.



10.2 CONSTRUCCIÓN

NOTACIÓN:Estará representado por el conjunto de pantallas que representan los diálogos,conectadas secuencialmente mediante una estructura de árbol.

CONSEJO Y GUÍA:

Usar el flujo de ventanas para:

• En el análisis y diseño identificar las entradas y salidas requeridas por elusuario.

• Verificar consistencia con Casos de Uso, Escenarios y Modelo deEstados.

VERIFICACIÓN:• El flujo y el retorno entre ventanas debe de ser obvio.• No debe de existir ninguna ambiguedad en los flujos y retornos.• Todas las ventanas debe de tener etiqueta.

IMPORTANCIA:Es esencial.



11 A06: ANÁLISIS DETALLADO IU.

11.1 DESCRIPCIÓN

¿QUÉ ES?:Describe cada una de las pantallas del diagrama de flujo.Cada pantalla contendrá el conjunto de información requerida por el usuariopara realizar cada una de sus tareas. La información sera presentadautilizando los diferentes tipos de texto, iconos, controles (botones, listas,cajas, etc), para cada ventana el usuario dispondrá de botones para activareventos.

¿POR QUÉ SE HACE?:La usabilidad del sistema depende mucho del diseño y flujo de la interfase deusuario.Deben de tenerse en cuenta normas de diseño (normalización de símbolos, decolores, posición o estructura de contenido, etc) y factores humanos.

¿QUIÉN LO HACE?:Por expertos en IU y revisado por usuarios entendidos para recoger lausabilidad (comprensible, intuitivo y eficiente) del sistema.

¿CUÁNDO SE HACE?:Durante o después del análisis, en cualquier caso siempre antes del diseño delos componentes de software que dirigen o controlan la IU.

¿CÓMO SE HACE?:A partir del diagrama de flujo IU, los productos obtenidos durante el análisisy de las entrevistas con los usuarios, el experto en diseño IU determinara:

1)La información a presentar al usuario.2)La información que se necesita solicitar al usuario.3)Las acciones que pueden realizarse desde cada vista.

Y utilizara para el diseño:



1. Mecanismos tales como : campos de entrada, botones, barras dedesplazamiento horizontal y vertical, etc.

2. Facilidades de presentación (títulos, etiquetas, imágenes, iconos, etc.)3. Terminología habitual del usuario.4. Facilidades de entrada (campos, listas, botones spin y radio, etc).5. Organización de grupos de IU. Barra de acciones, desplegar, etc.6. Fuentes, estilos y tamaños de texto.7. Color.8. Estética.

PUNTOS FUERTES:Facilita la comunicación entre el equipo de desarrollo y los usuarios.

PUNTOS DÉBILES:Si no se usa una herramienta de programación visual o de interfase deusuario.

11.2 CONSTRUCCIÓN

NOTACIÓN:Para el desarrollo de las pantallas lo normal sera utilizar herramientas deprogramación visual tales como Visualbasic, Visualage, Ezwindow,Hipercard, etc.

CONSEJO Y GUÍA:• Proceso incremental con la estrecha participación de los usuarios.• Usar herramienta de programación visual.• El tiempo dedicado a cada pantalla estará en relación directa con la

importancia que tenga para el usuario.

VERIFICACIÓN:• ¿Concuerdan las ventanas diseñadas con las existentes en el Diagrama de

Flujo.?• ¿Se han aplicado los estandares en el diseño?• ¿Los diferentes estados de una ventana, reflejados en el flujo, se han

identificado en el diseño?.

IMPORTANCIA:Es opcional aunque muy importante.



PRODUCTOS DEL DISEÑO.-En resumen, se trata de transformar el modelo de análisis en un diseño deuna solución de software, diseñando todos los objetos del sistema :*definiendo los atributos de datos y operaciones de cada objeto.*diseñando los algoritmos para implementar la conducta de los objetos .En este momento sera de ayuda construir una tabla que contenga encolumnas : clases y en filas servicios, indicando en la intersección si esresponsabilidad y/o colaboración.



12 D01: MODELO DE SUBSISTEMAS

12.1 DESCRIPCIÓN

¿QUÉ ES?:Consiste en diseñar la Arquitectura de la Aplicación, suponiendo que ya sedispone de la Arquitectura Técnica o de Sistemas (configuración hardware ysoftware).Describe la partición de un sistema en subsistemas y la delegación en ellosde sus responsabilidades. Ejemplo de subsistemas pueden ser el Sistema deBD o el de IU.En OOT se considera subsistema a un grupo lógico de clases (Categoría declases). Sin embargo consideramos que este último enfoque es mas bienpropio de la fase de análisis que de la de diseño.Por eso es preferible distinguir entre los dos tipos de particiones.El Modelo de Subsistemas debe referenciar tanto los subsistemas que sepueden reusar como los que son necesarios construir.

¿POR QUÉ SE HACE?:Porque el sistema sea demasiado grande y/o complejo para comprenderlo opara construirlo como un todo.Si se particiona, cada subsistema tendrá su propio modelo de objetos, suspropios escenarios y sus propios DIO's. Esto no impide que una clase puedaaparecer en mas de un subsistema, pero sera propiedad de uno solamente.Por otra parte la división en subsistemas puede incrementar la reusabilidad.

¿QUIÉN LO HACE?:El arquitecto y también estará involucrado el director de proyecto, porqueafectara a la distribución de trabajo en los equipos y sus dependencias.

¿CUÁNDO SE HACE?:Puede hacerse antes del análisis, en cualquier caso siempre antes de iniciar eldiseño.

¿CÓMO SE HACE?:Depende del momento en que se haga.Si es antes del análisis, será porque es un sistema grande del que ya se tienenlas ideas claras de como realizar una primera partición. Ejemplo: reingenieríade una aplicación.



Si es el primer paso del diseño, el punto de partida sera el Modelo delAnálisis, a partir del que se pueden definir las clases candidatas paraencapsular dentro de cada subsistema.

Debe de documentarse la dependencia entre subsistemas y agrupar lasresponsabilidades de cada subsistema en contratos para mostrar los enlacesentre los subsistemas. Un contrato es una colección coherente deresponsabilidades.

Un subsistema es dependiente mediante un contrato de otro subsistema, siemplea las responsabilidades del contrato para resolver su funcionalidad. Enel diagrama de subsistemas se mostraran estas conexiones vía contratos.

Cada subsistema identificado se tratara como un sistema, con todos y cadauno de los documentos de trabajo especificados para el mismo.

PUNTOS FUERTES:Es un documento muy importante de diseño. Sumariza la arquitectura de laaplicación y es un elemento básico de comunicación entre los componentesdel equipo.

PUNTOS DÉBILES:



12.2 CONSTRUCCIÓN

NOTACIÓN:Cada subsistema tiene el mismo conjunto de documentos que corresponden aun sistema.

Adicionalmente, cada subsistema incluirá las API's que definen las interfacesdel subsistema, sus modelos de objetos, código, etc. y en el Modelo deSubsistemas, por cada subsistema identificado se registrara:

Nombre del subsistema:Descripción:Contratos:Por cada contrato:Nombre del Contrato:Descripción:Clase Cliente:Lista de servicios requeridos.Clase Servidora:Lista de servicios prestados.

CONSEJO Y GUÍA:• Reducir todo lo posible las dependencias entre subsistemas.• Cuanto mas independientes serán mas reusables.• Las particiones pueden cambiar como consecuencia del descubrimiento

de nuevas responsabilidades.

VERIFICACIÓN:• Comprobar el particionamiento para una mayor autonomia de los

subsistemas.• Comprobar la frecuencia y tamaño de las comunicaciones entre ellos.• Comprobar que el particionamiento facilite la posible reusabilidad a nivel

de subsistema.• Verificar que las fronteras del sistema estan suficientemente claras en el

Diagrama del Modelo de Subsistemas.

IMPORTANCIA:Esencial



12.3 EJEMPLOS

Ejemplo de los subsistemas de una tienda de videos:

Ejemplo de Diagrama de subsistemas para una Arquitectura de Procesode Imágenes:

Objetivo: desarrollar subsistemas reusables en diferentes aplicaciones deproceso de imágenes.El Subsistema de Funciones de imágenes consiste en varias complejas ygrandes funciones que se pretenden reusar sin cambios.Para conseguirlo, el Subsistema de Proceso de imágenes tiene comoresponsabilidad extraer las imágenes de la BD de imágenes y colocarlas enmemoria tal como espera el subsistema de Funciones, invocar a estesubsistema e interpretar las respuestas.

Subsistema de Clientes

Cliente (5) ()Socio (6)()Nosocio (1)()Interfase()

Subsistema de Alqui leres

Alquiler (5)()Alqui lerporVideoCopia (2)()AlquilerporCl iente (2)()ReciboAlquiler (2)()Caja (2)()Interfase()

Subsistema de Tienda

Tienda (3)()Persona (3)()Empleado (1)()Gestor (4)()Proveedor (2)()interfase()

Subsistema de Reservas

Reserva (7)()ReservaporVideoCatalogo (3)()ReservaporSocio (3)()interfase()

+revisa Subsistema de Inventario

Catalogo (2)()VideoCatalogo (4)()VideoCopia (5)()PrecioCategoria (1)()Videocategoria (2)()Estante (1)()Interfase()



Nombre del subsistema: BD de Imágenes.Descripción: es una BD distribuida.Contratos: Mantenimiento de Imágenes

Nombre de Contrato: Mantenimiento de Imágenes.Descripción: Es un API para mantener una BD distribuida de imágenes.Notas:Por defecto las imágenes están almacenadas en el nodo local.Las imágenes pueden accederse desde cualquier nodo.

Interfase Usuario

Proceso de Imagenes

Funciones de imagenes

BD Imagenes

Proceso deimagenes

Mantenimientode imagenes

Invocar funciones



12.4 AMPLIACIÓN AL MODELADO DE SUBSISTEMAS:

La arquitectura de la aplicación puede diseñarse a partir de dosparticionados. Un primer particionado que dependen de la Estrategia deControl elegida, que será fundamentalmente un particionado vertical y ensegundo lugar un particionado que dependen de la cohesión y elacoplamiento existente entre las diferentes funciones de la aplicación y queen este caso será fundamentalmente un particionado horizontal.

12.4.1 Particionado Vertical:La Estrategia de Control puede ser:

a)Control basado en objetos GUI:Es la interfase de usuario quien dirige el trabajo de la aplicación.Es unabuena solución para prototipos y para pequeñas aplicaciones. La lógica decontrol puede llegar a tener una dependencia excesiva del flujo GUI.

b)Control basado en objetos de Negocio:Son los objetos de la lógica de procesos los que dirigen el trabajo de laaplicación. Puede dar lugar a objetos complejos y difíciles de mantener.Todos los objetos se corresponden con objetos del mundo real.

d)Control centralizado:Hay un único punto de control que interactua con objetos pasivos.Facilita loscambios pero el Controlador puede ser muy complejo, llegando a ser unmegaobjeto y además requiere una comunicación intensa con todos losobjetos, cuyos componentes mas relevantes serán estructuras de datos.

e)Control delegado:Se basa en Objetos Coordinadores de conjuntos de objetos, que gestionanprocesos concretos del negocio. Interactuan con pocos objetos y facilita lacomprensión del modelo, pero requiere un análisis de distribución.

Modelo M-V-C:Tomando como referencia el estado de la tecnología C/S y la necesidad deportabilidad, elegiremos el modelo M-V-C (modelo-vista-controlador) quetiene su mas claro referente en el caso e).En el modelo MVC cada nivel solo se comunica con el inmediato inferior,reduciendo así la visibilidad y en consecuencia la dependencia.



VISTA

CONTROLADOR

MODELO

Objetos de la IUNo conoce nada sobre el Modelo, Conoce unpoco sobre el Controlador

Objetos de ControlConecta la interfase con el Modelo, Conoce muypoco sobre la Vista.

Objetos del Modelo(lógica negocio)No conoce nada sobre la Vista.No conoce nada sobre el Controlador

Independizaalmacenamientode losobjetos

El Controlador tiene como misión dirigir la interfase de usuario y traducir loseventos de la Vista a mensajes del Modelo, por tanto por cada objeto Vistahabrá un objeto de Control.

Todo sistema, un arbol, una casa, una ciudad, una persona, estaintegrado por componentes y tiene al menos tres capas odimensiones.

La capa más externa, la más pública, la que vemos todos, conforma la partevisual. Si modelamos esta capa tendremos el Modelo Visual del sistema enestudio.

GESTOR DEPERSISTENCIA

BASE DE DATOS



Las capa mas interna, mas privada, mas especifica y propia del sistema enestudio, conforma su Modelo de Objetos. Para elaorar este Modelo serequiere tener conocimiento y dominio del problema.

Entre esa dos capas o Modelos de un mismo sistema, se requierecomunicación, tráfico, mensajes y respuestas, para que el Modelo puedafuncionar. Ese conjunto de interacciones, de tráfico, es tan intenso querequiere un control para evitar el caos del propio sistema, de hay surje latercera cada o Modelo Controlador.

Para comprender, dominar y poder implementar el sistema, es necesariointegrar los tres modelos en uno: M-V.C.

Ventajas del Modelo:• El Modelo es la parte mas estable, cambia poco de versión a versión.• El Controlador cambia poco entre versiones.• La Vista cambia muy rápido.• La estructura M-V-C se adapta al nivel de actividad de las partes, aislando

el impacto de los cambios.• Divide el proyecto en capas que requieren skills diferentes.• Facilita la portabilidad.



12.4.2 Particionado Horizontal:

El criterio será formar conjuntos de clases que funcionando conjuntamenterealicen un conjunto homogéneo de responsabilidades (Categorías deClases ).El particionado horizontal se hace sobre el Modelo.

Un buen Subsistema:• Presenta una interfase clara y estrecha• Oculta los detalles de las clases que encapsula• Proporciona un conjunto de funcionalidades cohesivas• Representa una parte del sistema.

Los pasos a realizar son:1. Jerarquías de herencia:Se deben crear jerarquías de herencia que maximicen la reusabilidad, paraello( se empieza de abajo a arriba):• Identificar conjuntos de clases con responsabilidad común.• Subir esa responsabilidad al nivel mas alto para que se herede.

2. Identificar Contratos:Las responsabilidades cohesivas y usadas por el mismo conjunto de clientesse agrupan en contratos (se empieza de arriba a abajo).

3. Diagrama de Colaboraciones:Se construye para facilitar la identificación de los subsistemas.Existe el acuerdo de que el número máximo de contratos públicos que puedesoportar un Subsistema es 3.

Consejos:

• Un contrato es siempre una relación cliente/servidor.• Un contrato agrupara siempre responsabilidades públicas.• Muchas clases soportan solo un contrato.• Una clase soportara varios contratos cuando: - Tiene múltiples roles.

- Sus servicios pueden ser divididos en conjuntos usados por clientesdistintos.

• Los contratos aparecen siempre en las clases servidoras.



13 DO2: DISEÑO DEL MODELO DE OBJETOS.

13.1 DESCRIPCIÓN

¿QUÉ ES?:Ver documento A01.

¿POR QUÉ SE HACE?:En Análisis representa la estructura del problema, en Diseño representa laestructura de la solución software.Una clase del Modelo en el análisis puede corresponderse a una o mas en elDiseño. Por ejemplo la clase Carpeta, ahora podrá ser clase Carpeta y claseVistaCarpeta.El mecanismo de la arquitectura es ahora Modelo-Vista para un sistema coninterfase gráfica de usuario.Esta es una de las fases mas creativas del proceso de desarrollo de unproyecto OO, en el que además se descubrirán nuevas clases.

¿QUIÉN LO HACE?:Es una tarea de arquitectos, diseñadores y desarrolladores.

¿CUÁNDO SE HACE?:Al inicio del diseño, aunque sera necesario mantener durante laimplementación.

¿CÓMO SE HACE?:Lo mejor es partir del Modelo de Objetos del análisis y expandirlo. Lospasos son:

1. Añadir nuevas clases, como por ejemplo clases de utilidad y vista.2. Asignar responsabilidades a partir DIO y DTE.3. Expresar las responsabilidades en términos de:

• Atributos.• Métodos u operaciones, (no tiene porque haber una correspondencia

1:1 entre responsabilidades y operaciones, un conjunto de operacionesdarán lugar a un método) Refinar con DIO y DTE.

4. Por cada clase y asociación del modelo, considerar las operaciones quepueden necesitarse para crear o eliminar una ocurrencia.

5. Para optimizar el acceso introducir nuevas asociaciones o modificar lasexistentes.



6. Añadir metaclases si el lenguaje de implementación es Smalltalk oCOObol.

7. Determinar que clases serán persistentes.8. Especificar la accesibilidad de operaciones:

• Public : Cualquier clases puede invocar la operación.• Protected: Solo subclases pueden invocar la operación.• Private: Ninguna otra clase puede invocar la operación.

9. Especificar la implementación de las asociaciones:• Dirección (en análisis se reflejaron como bidireccionales).• Nombre y visibilidad de los atributos que implementan la asociación.

10. Determinar la implementación de los destinos en las asociaciones:• Un atributo de tipo colección.• Una clase separada.• No se implementa.

11. Determinar la propiedad (quien crea, elimina, etc. los objetos).12. Establecer la clase de referencia que usaran los atributos que implementan

las asociaciones y las agregaciones:• By reference : contiene un puntero o una referencia.• By value: contiene un objeto (aplicable solo para agregaciones).• By key: contiene una clave que puede ser convertida en una

referencia (por ejemplo un mecanismo de resolución de nombres).13. Determinar el ámbito de las asociaciones:

• Ambito operación (referencia dinámica): Cuando un objeto Aobtiene una referencia para un objeto B a través de un parámetro deun método o por una variable local del método.

• Ambito clase (referencia persistente): Referencia desde un objeto Aa un objeto B necesita persistir entre las llamadas de métodos.

14. Determinar los tipos de todos los atributos.



13.2 Ampliación al Diseño del Modelo de Objetos:

13.2.1 Representación de asociaciones.

1.1)Asociaciones unarias.Las asociaciones unarias son las que se recorren solo en una dirección.Las asociaciones unarias del Análisis se transforman en punteros en elDiseño.Regla General: Se implementan como atributos punteros.* multiplicidad "uno" ---------------------------> puntero sencillo.* multiplicidad "muchos" ---------------------> conjunto de punteros.* ordenados + multiplicidad "muchos"----> lista de punteros

empleado

1 *

La solución es incorporar el atributo Empresa en la Clase Persona, existiendoasí un puntero en persona que apunta a empresa y desaparece la notación deasociación.

Si la multiplicidad fuese N, entonces tendría acceso a una colección deobjetos. La colección de objetos se implementa mediante una matrizunidimensional, con un puntero a cada objeto. Añadir un objeto a lacolección es añadir un puntero a la matriz, destruir un objeto es poner unpuntero a null.

1.2)Asociaciones binarias.Asociaciones binarias son las que se recorren en ambas direcciones.

Alternativa 1:• Puntero solo en una dirección.• Cuando se requiera el recorrido inverso se hace una búsqueda.

empleado

1 *

EMPRESA PERSONA

empresa

EMPRESA PERSONA

empresa



Esta solución es factible cuando:• El recorrido inverso es muy infrecuente.• Es importante minimizar los costes de almacenamiento y

actualización

Si se necesita saber cuales son los empleados de una empresa, habría queiterar sobre la clase persona, para obtener el subconjunto.

Cuando un empleado cambie de empresa, hay que poner un puntero, quitarun puntero y actualizar la clase persona.

Alternativa 2:• Punteros en ambas direcciones.• La actualización de un puntero requiere la actualización del otro.• Es factible cuando el numero de accesos supera al de actualizaciones.

empleado

1 *

Set es un tipo de colección que no admite duplicados

Alternativa 3:• Objeto asociación distinto.• Util para:

• extender librerías de clases predefinidas que no pueden sermodificadas

• asociaciones poco densas.

empleado

1 *

EMPRESA

Set de personas

PERSONA

empresa

EMPRESA PERSONA

empresa

EMPLEADOS

Diccionario(persona,empresaDiccionario(empresa,persona)



Esta alternativa convierte la asociación en una clase distinta. La clasediccionario tiene una sola ocurrencia. El atributo de tipo diccionario es untipo de colección que se corresponde con una tabla de dos columnas(clave yvalor), en donde la clave puede ser persona o empresa.

1.3)Asociaciones clasificadas.

Regla general:

m1 m2

Solución:

m2 m1

1.4)Atributos de la asociación.

Para las asociaciones que tienen atributos proceder:

• Si la multiplicidad de ambos lados es 1 (asociación 1:1), el atributo semueve a cualquiera de los lados.

• Si la multiplicidad de un lado es muchos (asociación 1:n), poner elatributo en el lado de la clase muchos.

• Si la multiplicidad en ambos lados es muchos (asociación n:n), se procedecomo en el caso 1.3 (clasificando la asociación).

Para la Agregación se hace igual que en la Asociación.

Para la herencia si implementa con la ayuda de los lenguajes, que si losoportan.

A B

R

A BR



13.2.2 Restricciones:

En el caso del almacén, una restricción podría ser : no puede haber doscargas en la misma posición.

Los primero que debemos hacer es analizar los métodos que al ejecutarsepueden dar lugar a una violación de la restricción. En este ejemplo serian :New y Mover.

Los pasos a realizar para su implementación, serian:

1)Alternativa 1: Consultar precondición.La solución es ejecutar previamente unos métodos precondición: si nos davalor positivo podemos ejecutar los métodos críticos, si es negativo no.Se implementa un método de clase (se ejecuta antes del new, por tanto nohay instancia) : $comprobar.posición: el argumento sera la nueva posición.Se itera en todas las instancias de clase carro para ver si están en la posición.

2)Alternativa 2: Consulta postcondición.También puede implementarse, pero en este caso como un método deinstancia. Ver si ha habido violación, si la ha habido, entonces hay quedeshacer lo hecho, lo cual supone mayor coste y dificultad.Siempre que sea posible, la solución es a través de precondición.

3)Alternativa 3: Método prerrequisito.Se vincula el éxito a varios métodos.

4)Persistencia

(pendiente de desarrollar)



PUNTOS FUERTES: Ver A01.

PUNTOS DÉBILES: Ver A01.

NOTACIÓN:Es básicamente la misma que la utilizada en el análisis del Modelo deObjetos, con las siguientes excepciones:

• Direccionamiento.• Adornos de clases (por ejemplo parámetros).• Adornos de atributos (por ejemplo constantes).• Adornos de accesibilidad (por ejemplo protected).• Adornos de agregaciones y asociaciones (por ejemplo by reference).

CONSEJO Y GUÍA:• Usar como base una copia del Modelo de Objetos del análisis.• Si los objetos de una clase envían mensajes a los de otra, se define una

dependencia de clases entre estas dos clases.Sin embargo, no todas las dependencias de clase son asociaciones, puesen algunos casos solo se envían parámetros para operaciones.

• En análisis hay "clase asociación" y en diseño no, en diseño serán enalgunos casos convertidas en clases normales.

• Extraiga conductas y atributos comunes en superclases.• Los atributos que implementan asociaciones en superclases, se declaran

normalmente como protected.

VERIFICACIÓN:Ver A01.• Comprobar que la representación interna de cada clase puede cambiarse

independientemente dee otras clases, excepto cuando exista unadependencia explicita.

• Comprobar que todas las asociaciones tienen nombre, dirección ycardinalidad.

• Comprobar que estan definidos los tipos de todos: los atributos,parametros y retornos de funcion.

IMPORTANCIA:Es absolutamente esencial.



14 D03: DISEÑO DEL DIAGRAMA DESECUENCIA/DIO

14.1 DESCRIPCIÓN

Ver A02.¿QUÉ ES?:Es el resultado de transformar el DIO del Análisis, si se hizo. Se hace masénfasis en las clases que sera necesario implementar, resultando masdetallados que los del Análisis.

¿POR QUÉ SE HACE?:Implementa la estrategia de control que se seleccione, pudiendo añadirseobjetos coordinadores para soportar la estrategia (C/S).Facilita la expresión del impacto de la arquitectura del sistema, visualizandola distribución de las responsabilidades del sistema en objetos. Es muyposible que en esta fase se creen más objetos.

¿QUIÉN LO HACE?:Arquitectos, diseñadores y desarrolladores. Es importante la participación deprogramadores seleccionados, para reflejar las limitaciones de los lenguajes autilizar.

¿CUÁNDO SE HACE?:Tan pronto como exista el Modelo de Objetos del Diseño (D02).

¿CÓMO SE HACE?:A partir de una copia de los DIO obtenidos en el análisis.Ahora sera necesario considerar fundamentalmente la arquitectura delsistema, patrones de diseño y limitaciones del sistema y la estrategia decontrol elegida en el Modelo de SubsistemasSi se usa la arquitectura Modelo-Vista, una clase del análisis se transformaen dos clases en el diseño, una clase del modelo (lógica de negocio) y otraclase vista (interfase de usuario). Cuando se utiliza una capa de persistenciaen una arquitectura de múltiples capas, una clase del análisis puedetransformarse en dos clases en el diseño: una clase persistente (para lagestión de la base de datos) y la clase del modelo.

Los pasos a seguir de desarrollar el DIO en diseño, son:1. Como información básica de entrada usaremos los Escenarios de los

Casos de Uso y los DIO's del análisis.



2. Localizar las responsabilidades de los objetos, en el Modelo de objetosdel Análisis.

3. Analizar las interacciones entre objetos. Examinar las responsabilidades ysus dependencias. Por ejemplo, si un objeto es responsable de una acciónespecifica, pero no posee todos los conocimientos necesarios pararealizarla, debe de colaborar con objetos de otras clases que posean elconocimiento necesario. Dos objetos cualquiera que tenga que colaborardirectamente, tendrán una asociación direccional o una dependencia devisibilidad entre sus correspondientes clases.

4. Identificar colaboraciones, haciendo la siguiente pregunta por cadaresponsabilidad de cada clase : "¿Son los objetos de la clase capaces derealizar por si mismos totalmente esta responsabilidad?".

5. Asegurarse de que los parámetros están definidos para aquellos mensajesque incluyan métodos que devuelven valores, de tal forma que el flujo dedatos y la memoria estén documentados.

6. Se añade la creación y destrucción de objetos.

PUNTOS FUERTES:Intuitivos y expresivos.

PUNTOS DÉBILES: Ver A02..

14.2 CONSTRUCCIÓN

NOTACIÓN:Es prácticamente la misma que en el análisis, solo opcionalmente puedeañadirse "estados de objetos" y "fronteras de procesos".

CONSEJO Y GUÍA:• Mantener la consistencia con el Modelo de Objetos del diseño.• Verificar que cada mensaje tiene su etiqueta y los parámetros requeridos.• Diseñar en DIO's solo aquellos escenarios críticos.• Expresar el impacto de la arquitectura en el DIO.

VERIFICACIÓN:Ver A02.• Comprobar que la navegación de objeto a objeto implicado, es posible por

usar los atributos, parametros y operaciones apropiados.• Verificar que la frecuencia de inter-comunicación es aceptable.

IMPORTANCIA:Es esencial.



14.3 EJEMPLO

• Se representan puntos de control para poner en evidencia cuando unobjeto esta activo(mediante un rectangulo), es decir en ejecución oesperando por una respuesta.

• Se representan las fronteras del sistema(vista, lógica y servidor).

VISTA LOGICA NEGOCIO SERVIDORObjeto1: Objeto2 Objeto3: Objeto4: Objeto5Clase1 Clase2 Clase3 Clase4 Clase5

Mensaje1()

Mensaje2() [condicion]mensaje3()

[condicion]mensaje3()

[condicion-bucle]

Mensaje4(par)

{actividad1}

devolver(par)



15 D04: DISEÑO DEL DTE

15.1 DESCRIPCIÓN

Ver A03.

¿QUÉ ES?:Es la representación dinámica de la conducta de un objeto.Solo clases con estados complejos requieren su representación.

¿POR QUÉ SE HACE?:Cuando se envía un mensaje de un objeto a otro, ocurren dos cosas. Primero,el objeto que envía el mensaje realiza una acción en su estado para enviar elmensaje. Segundo, se forma un suceso y llega al objeto receptor del mensaje,lo cual hará que cambie de estado.

¿QUIÉN LO HACE?:Arquitectos y diseñadores. Es importante la participación de programadoresseleccionados, para asegurar que el diseño se implemente eficientemente.

¿CUÁNDO SE HACE?:De forma iterativa, conjuntamente con el diseño del Modelo de Objetos y losDIO's.

¿CÓMO SE HACE?:Durante las fases de diseño e implementación puede ser necesario construirestos modelos para algunas clases, para facilitar la comprensión de suconducta.

PUNTOS FUERTES:Capacidad para describir el ciclo de vida y la conducta dependiente delestado. Es tambien el lugar donde se ve de forma centralizada la conducta deun objeto.

PUNTOS DÉBILES:En unos casos puede ser tediosa y en otros trivial, por ello la construcciónsera selectiva.



15.2 CONSTRUCCIÓN

NOTACIÓN:La misma que la del análisis.

VERIFICACIÓN:• Comprobar los "pozos negros", grupo de estados en los que si se entra no

se puede salir. Un "pozo negro" no es necesariamente un error.• Habra un estado inicial y un estado final.• Por cada estado no-inicial, habra al menos una transición de entrada.• Por cada estado no-final, habra al menos una transición de salida.• Habra etiqueta para cada transición, el nombre sera el del suceso que la

dispara.• Para cada nodo verificar si puede darse otro suceso.• Comprobar la consistencia entre los DIO's y sus correspondientes Modelo

de Estados de cada objeto. Todo mensaje representado en el DIO estarareflejado como un suceso en el Modelo de Estados, que da lugar a uncambio de estado.

IMPORTANCIA:Opcional.



16 D05: DESCRIPCIÓN DE CLASES

16.1 DESCRIPCIÓN

Ver A04.¿QUÉ ES?:Es la representación de toda la información conocida de cada clase, a nivelde diseño. Lo indicado para la Descripción de Clases en en Análisis esaplicable también aquí.Una de las diferencias de diseño respecto al análisis es que muyposiblemente lo que era una clase en el análisis, sea ahora una clase delModelo y otra clase de la Vista, para separar ambos aspectos.Normalmente este documento de trabajo se genera de forma automática porla herramienta que se utilice, a partir de toda la información acumulada hastaeste momento para cada clase.

¿POR QUÉ SE HACE?:Es el punto de partida para las tareas de implementación de cada clase.

¿QUIÉN LO HACE?:El desarrollador que tiene una clase en propiedad, tiene la responsabilidad demantener su descripción.

¿CUÁNDO SE HACE?:Tan pronto como se identifique la necesidad de diseño de la clase. A partir deese momento la descripción de la clase es el almacén de toda la informaciónque le concierne.

¿CÓMO SE HACE?:Podemos asumir que gran parte de las clases del análisis llegaran a ser clasesen el diseño. La actualización de las descripciones de las clases sera una delas actividades a realizar después de cada sesión de diseño del modelo.

PUNTOS FUERTES:Son un punto vital en el arranque de la implementación.

PUNTOS DÉBILES:Existe el riesgo de que se produzca redundancia de información con otrosdocumentos, tales como el modelo de objetos y el de estados, de ahí unarazón mas para utilizar una herramienta, que además nos asegura laconsistencia.



16.2 CONSTRUCCIÓN

NOTACIÓN:A continuación se presenta un ejemplo de contenedor de la descripción:

Clase Superclase: Subclases:

Descripción:

Estados Descripción

Atributos Valores Relacion Clase Vi/vc

Metodos Retorno Argument Privado/prot/publico

Vi/vc

CONSEJO Y GUÍA:La descripción debe de suministrar información suficiente para podercodificar cada clase de forma autónoma.Se definirá de forma independiente a sus subclases, aunque en la descripciónestaran incluidas las relaciones.



VERIFICACIÓN:Ver A04.• Verificar que todos los métodos están descritos con detalle suficiente.• Verificar que los atributos, parámetros y retornos tienen tipo.• Verificar que están identificados los atributos clave y las relaciones.• Comprobar que todas las asociaciones "n" se implementan por una clase

colección del tipo apropiado.




17 D06: PLAN DE EMPAQUETAMIENTO. Diagramade Módulos

17.1 DESCRIPCIÓN.

¿QUÉ ES?:Se decide sobre la estructura fisica que van a tener los productos fabricados.Tambien contiene decisiones sobre la estructura fisica de los datos a utilizaren el proceso de construcción de los ejecutables.

Los productos pueden ser:• Ejecutables (ejemplo: ficheros tipo .exe)• Librerias (ejemplo: ficheros tipo .dll)• Mensajes (ejemplo: ficheros tipo .msg)• Imagenes (componentes visuales de ventanas ejecutables).

Los datos desde que se construyen los productos, pueden ser:• Ficheros fuente (ejemplo: ficheros .cpp y .h)• Ficheros de control de Link (ejemplo: ficheros .def)• Fuente de ventanas (ejemplo: ficheros .rc)• Visual builder (ejemplo ficheros: .vbb, .cpv y hpv)• Ficheros de construcción (ejemplo: ficheros makefile)

¿POR QUÉ SE HACE?:Permite normalizar el empaquetamiento, no dependiendo la estructura de loscriterios de cada desarrollador y se dispone de unos componentes tipificadosen cada paquete construido.

¿QUIÉN LO HACE?:Se aconseja que un miembro del equipo coordine la aplicación de lanormativa.

¿CUÁNDO SE HACE?:Igual que las directrices de codificación.

¿CÓMO SE HACE?:Teniendo en cuenta las plataformas de desarrollo y ejecución elegidas y lasexperiencias en otros proyectos.



PUNTOS FUERTES:Son un punto vital en el arranque de la implementación y facilita su control ypuesta en explotación.

PUNTOS DÉBILES:Existe el riesgo de que se produzca redundancia de información con otrosdocumentos, debiendo de evitarse.

17.2 CONSTRUCCIÓN

NOTACIÓN:Puede utilizarse formato texto o Diagrama Gráfico de Componentes.

CONSEJO Y GU+A:La descripción será simple y reseñara las razones de la arquitectura, almismo tiempo que tratara de evitar interdependencias, en especial entresubsistemas.

VERIFICACIÓN:Verificar que todos los tipos de productos a fabricar disponen de suestructura de componentes fuente.

IMPORTANCIA:Opcional.



18 I01: DIRECTRICES DE CODIFICACIÓN

18.1 DESCRIPCIÓN

¿QUÉ ES?:Es un documento en el que se recogen un conjunto de reglas yrecomendaciones que dirigen el estilo de programacón en el proceso dedesarrollo del software. En general son cosas que no son detectadas por loscompiladores, pero que causan errores o problemas asociados con elmantenimiento, la portabilidad, el rendimiento, la simplicidad, la claridad,etc.Los tópicos que normalmente cubren estas directrices son:

• Convenciones sobre nombres de ficheros.• Estructura de ficheros.• Seguridad y tecnología de ficheros.• Convenciones sobre nomenclaturas.• Nombres globales, locales, visuales.• Estructura de clases.• Inicialización.• Uso de tipos en el lenguaje.• Convenciones sobre llamadas y retorno de funciones.• Gestión de memoria.• Cohesión, encapsulamiento y vinculación.• Manejo de excepciones y de errores.• Uso de funciones o componentes especificos del lenguaje.• Rendimiento.• Portabilidad.

Aspectos que en gran medida estan relacionados con la tecnología yherramientas utilizadas en cada entorno de desarrollo.

¿POR QUÉ SE HACE?:Permite reducir los errores de programación, incrementa la calidad delproducto, normaliza el desarrollo, facilita la documentación, elmantenimiento y la ampliación.

¿QUIÉN LO HACE?:El lider del proyecto con las aportaciones de los desarrolladores.



¿CUÁNDO SE HACE?:Al menos antes del inicio de la Implementación.

¿CÓMO SE HACE?:Se hace una primera versión al inicio del primer Proyecto, siendo reusadoposteriormente e incluso puede ser revisado para introducir las mejoras quese consideren necesarias.

PUNTOS FUERTES:Son un punto vital en el arranque de la implementación.El disponer de estadocumentación hace mas facil el proceso de implementación y facilita laincorporación de nuevos desarrolladores al proyecto.

PUNTOS DÉBILES:Resistencia de los desarrolladores a incorporar en sus habitos de trabajodirectrices comunes, en especial cuando no existe una cultutra madura detabajo en equipo.

18.2 CONSTRUCCIÓN

NOTACIÓN:Texto.

CONSEJO Y GU+A:Antes de iniciar la implementación revisar las directrices con todos losdesarrolladores y confirmar que han sido comprendidas perfectamente.No aceptar ninguna implementación que no cumpla las directrices.

VERIFICACIÓN:Verificar la guía con desarrolladores que tengan demostrada experiencia enlos lenguajes y en el entorno de desarrollo a utilizar en la implementación.




19 I02: CÓDIGO FUENTE

19.1 DESCRIPCIÓN

¿QUÉ ES?:Es la implementación del Diseño en un lenguaje de programación.Dependiendo del lenguaje de programación elegido y del entorno dedesarrollo, puede haber diferentes tipos de ficheros de codigo para una clase.Estos ficheros contendran lineas del codigo del programa y uno o variosficheros conteniendo una definición de los atributos y metodos de la clase.

¿POR QUÉ SE HACE?:Finaliza la implementación del diseño, para a continuación comprobar que lapieza construida cumple los requisitos.

¿QUIÉN LO HACE?:El desarrollador propietario de cada clase.

¿CUÁNDO SE HACE?:De acuerdo con la ejecución del Plan de Fabricación y siemprel despues de larevisión del diseño de la clase.

¿CÓMO SE HACE?:La funcionalidad de la clase se implementa con el lenguaje de codificación,normalmente el codigo se crea de una de las tres formas:

• Todo a mano usando un editor de texto.• Parte del codigo y de los componentes de interfase usando una

herramienta de diseño y el cuerpo de las funciones con editor detexto.

• Todo el código se genera de forma automática con un juego deherramientas (Herramientas de Programación Visual y Lenguajesde cuarta generación). Hoy todavia no es posible lograr el 100%.

PUNTOS FUERTES:Depende del lenguaje de programación seleccionado.

PUNTOS DÉBILES:Depende del lenguaje de programación seleccionado.



19.2 CONSTRUCCIÓN

NOTACIÓN:Depende del lenguaje de programación seleccionado.

CONSEJO Y GUÍA:Conviene disponer de un almacen de código que gestione las diferentesversiones, con objeto de facilitar la gestión y el control de cambios. Asícomo el control de la versión o versiones en explotación, mantenimiento yampliación, en especial cuando la fabricación se realiza en un sistemadistribuido.

VERIFICACIÓN:La verificación aquí realizada se completara posteriormente con los casos deprueba.

Algunas de las cosas que se pueden verificar en este momento son:

• Si hay algun atributo de tipo puntero en la clase, comprobar:• La "regla de tres": Si hay un destructor, o un copy constructor o

una operación de asignación, existen los tres.• Propiedad: ¿Que objeto crea el objeto aludido y que objeto lo

borra?• ¿Hay excepciones que pueden eludir la destrucción del objeto?.

• Por cada función, comprobar:• Que se devuelve: ¿puntero/referencia/valor? ¿Debería ser

constante?.• Que se pasa: ¿puntero/referencia/valor? ¿Debería ser

constante?.• Si hay una conducta dependiente del estado, debe documentarse.• Si el metodo tiene precondiciones, deben documentarse y probarse.¿Que

ocurre si son violadas?.• Las postcondiciones deben de documentarse.• ¿Puede el objeto quedar en un estado ilegal si hay un fallo?• Si hay ejecución concurrente del codigo: ¿hay serialización? sino se

puede ¿hay protección?.



EUITIO-WLM 09/04/03 100

20 P01: PLAN DE PRUEBAS

La prueba es tan importante en el proceso de desarrollo del software OO,que es una parte importante de la actividad de cada una de las fases hastaaqui descritas, por lo que en cada una de ellas se ha incluido un apartadodedicado a la VERIFICACIÓN.

Además, al final de la implementación de cada clase se haran pruebasunitarias y de integración.

Las técnicas y métodos a utilizar en los casos de prueba se describen en elmanual de "Técnicas y Métodos de Prueba".

20.1 DESCRIPCIÓN

¿QUÉ ES?:Es un documento en el que se responde a las preguntas: Quien, Cuando, Quey Como se hacen las pruebas. Especificando las clases de prueba y el ordende las mismas. Si para alguna prueba especifica se necesita algun entornoconcreto de hardware y software, tambien se describira.

El referente de la prueba será el nivel de calidad exigido al producto

Este Plan de Prueba especificara las pruebas especificas que se deban dehacer en cada fase de fabricación del producto (las señaladas en estedocumento en cada fase, en el apartado de Verificación) y las que se vayan arealizar como una fase especifica dedicada a las pruebas.

¿POR QUÉ SE HACE?:El Plan se hace para asegurar que la prueba se realiza en cada momento y deforma completa y fiable.

¿QUIÉN LO HACE?:La prueba especifica de cada fase la haran los constructores del producto enesa fase. La prueba especifica que se realiza despues de la implementación larealizaran personas diferentes a los desarrolladores de ese producto.

¿CUÁNDO SE HACE?:De acuerdo con la ejecución de cada una de las fases del Plan de Fabricación.


EUITIO-WLM 09/04/03 101

¿CÓMO SE HACE?:Por cada fase será necesario prever un tiempo para la revisión y verificaciónde lo producido en la fase.La prueba del codigo requerira definir Casos de Prueba especificos para cadaclase, para cada escenario, para cada caso de uso y para cada subsistema.

PUNTOS FUERTES:Permite planificar el uso de los recursos a utilizar en el proceso defabricación. Coste y duración.

PUNTOS DÉBILES:

20.2 CONSTRUCCIÓN

NOTACIÓN:

CONSEJO Y GUÍA:• Determinar el nivel de calidad requerido para el producto.• Identificar todas las dependencias software y hardware y en que momento

los recursos son necesarios para realizar las pruebas.• Segun el nivel de calidad requerido, estimar los siguientes tiempos para el

proyecto.• Alto : Prever un uso adicional de todos los recursos del

proyecto en torno al 95% para la prueba.• Medio: Prever un uso adicional del 20% al 50%.• Bajo: Prever un uso adicional del 10% al 20%.

VERIFICACIÓN:Verificar que se realizan todas las pruebas, registrando las desviaciones entrelos resultados esperados y los obtenidos y las acciones previstas y /orealizadas para eliminar las desviaciones.



EUITIO-WLM 09/04/03 102

21 P02: CASOS DE PRUEBA

21.1 DESCRIPCIÓN

¿QUÉ ES?:Son unidades de prueba que se usan para verificar el codigo.

¿POR QUÉ SE HACE?:Para asegurar la corrección del código en relación a los requisitosestablecidos por el nivel de calidad exigido para el producto.Potencialmente serian necesarios infinitos casos de prueba para probar elcodigo de forma exhaustiva, como es imposible, se requiere un plan basadoen técnicas y metodos, que nos permitan seleccionar un numero de Casosaceptables para asegurar el nivel de calidad exigido.

¿QUIÉN LO HACE?:Los Casos de Prueba son desarrollados y ejecutados por personal dedicadoespecificamente(al menos en ese momento) a la prueba en colaboración conlos desarrolladores del código.

¿CUÁNDO SE HACE?:De acuerdo con la ejecución de cada una de las fases del Plan.

¿CÓMO SE HACE?:Siguiendo las técnicas y metodos descritos en el manual.

PUNTOS FUERTES:Determina la calidad del código. Los Casos de Prueba son reusables.


EUITIO-WLM 09/04/03 103

21.2 CONSTRUCCIÓN

NOTACIÓN:Se suelen escribir en el mismo lenguaje de programación a no ser que se useuna herramienta especifica de testing, para generar de forma automatica loscasos de prueba.

CONSEJO Y GUÍA:• Por cada producto de las fases de Anaisis, Diseño e implementación

definir un conjunto de Casos de Prueba.• En la implementación, en un primer nivel, separar los Casos de Prueba de

la interfase de usuario de los Casos de Prueba de las funciones.

VERIFICACIÓN:Por cada caso de prueba registrar lo esperado y el resultado.



EUITIO-WLM 09/04/03 104

22 TABLA DE IMPACTOS:Se reflejan los probables efectos que cualquier modificación en uno de losdocumentos de trabajo expuestos, produce sobre el resto.

IMPACTADO

IMPACTA

R01

R02

A01

A02

A03

A04

A05

A06

D01

D02

D03

D04

D05

R01:Descripción del Problema

X

R02:Modelo Requisitos

X X X X

A01:Modelo de Objetos

X X X X

A02:Diagrama Secuencia

X X X X

A03:Diagrama de Estados

X X X

A04:Descripción de Clases

X

A05:Diagrama de Flujo IU

X X X X

A06:Diseño detalle IU

X X X X

D01:Modelo de SubsistemasD02:Modelo de Objetos

X X X X

D03:Diagrama Interacción

X X X

D04:Diagrama de Estados

X X

D05:Descripción de Clases


EUITIO-WLM 09/04/03 105

23 GUÍA RESUMIDA DE ROSE

23.1 INTRODUCCION.-

Este anexo contiene una breve descripción de las tareas a realizarpara la utilización de la herramienta ROSE, en la elaboración de losdiferentes diagramas que se exponen en la Guía de Clases Prácticasde MPII.

Pretende ser una introducción en el uso de la herramienta ROSE,para una información mas detallada será necesario recurrir a lostutorial y ayudas integrados en la propia herramienta, que comopodrá observar cuando utilice ROSE, para facilitar su aprendizajedispone ademas de una ayuda sensitiva.

La mayoría de los métodos y técnicas expuestos en la Guía dePrácticas podrán ser desarrollados utilizando ROSE, en estadescripción del uso de la herramienta se seguirá el mismo orden detareas que se expone en la citada Guía.

Aquellos documentos o diagramas expuestos en la Guía y nocubiertos con ROSE, podrán ser editados con cualquier herramientade texto o de dibujo, que incluso pueden ser enlazados desde lapropia herramienta ROSE.

El resultado del proceso de análisis y diseño de una aplicaciónutilizando ROSE es un Modelo, en el que se almacenan losproductos resultantes.

Los componentes que integran un Modelo son: Casos de Uso,Categorías de Clases, Clases, Objetos, Subsistemas, Módulos,Procesos, Dispositivos y Relaciones.

Subsistema:Contiene Diagramas de Módulos con sus componentes (uncomponente puede ser un subsistema anidado).


EUITIO-WLM 09/04/03 106

23.2 CATEGORÍA DE CLASES :

Es un contenedor de clases del mas alto nivel.

En ROSE una aplicación, para su análisis y diseño se particiona enCategorías de Clases.

Una Categoría de Clases puede contener a su vez Categorías deClases.

Una Categoría de Clases, es un grupo de clases cohesivas y quecolaboran entre si y que se representan en Diagramas de Casos deUso, Diagramas de Clases y Diagramas de Escenarios(DIO).

Una Categoría de Clases contiene siempre Diagramas de Clases ypuede contener Diagramas de Casos de Uso y Diagramas deEscenarios.

Una Categoría de Clases contiene siempre al menos un Diagramade Clases del máximo nivel llamado MAIN.

En el caso de que una Categoría de Clases contenga a su vezCategorías de Clases, entonces el Diagrama de Clases de máximonivel (MAIN), contendrá sus Categorías de Clases que serepresentan por un icono que es un rectángulo cuyas lineas sondiscontinuas.

Por ejemplo la Categoría de Clases logical view, su Diagrama deClases hidroponics, es realmente un diagrama de Categorías deClases. En este diagrama la Categoría de Clases greenhouse es asu vez un diagrama de clases que contiene dos categorías de clases:controller y nutrionist.

Estas dos ultimas categorías de clases contienen finalmenteDiagramas de Clases cuyos componentes son clases.


EUITIO-WLM 09/04/03 107

23.3 COMENZAR CON ROSE:

• Arranque el programa: Rational Rose Modeler.(elija Inicio,despliegue Programas y elija Rational Rose Modeler alsegundo nivel).

• En la barra de menú elija file, y abra el fichero uMLtutor.

• En la barra de menú elija browse y luego class diagram.

Se visualiza una ventana con dos columnas : Class Category yClass Diagrams.

• Seleccione diferentes Class Category y observe como a cada unale corresponde una lista diferente de Class Diagrams, teniendo almenos una Main.

• Elija la categoría logical view y de su lista de diagramas, elijahidroponics y pulse el botón ok : Se le presentara una ventanacon un Diagrama de Clases, integrado por Categorías de Clases(observe que son rectángulos de lineas discontinuas).

• Posicione el puntero en el icono de greenhouse (Categoría deClases) y pulse dos veces el botón izquierdo, se visualiza unaventana con las dos categorías de clases que contiene: controllery nutrionist.

• Posicione el puntero sobre la Categoría de Clases controller ypulse dos veces el botón izquierdo: se visualiza una nuevaventana que contiene su Diagrama de Clases.

DIAGRAMAS ROSE:ROSE nos permite construir los siguientes Diagramas:

* Diagramas de Casos de Uso.* Diagramas de Clases.* Diagramas de Escenarios.* Diagramas de Estados.* Diagramas de Módulos.* Diagramas de Procesos.

con todas las especificaciones necesarias que corresponden a cadauno de ellos.


EUITIO-WLM 09/04/03 108

Verifiquelo:Seleccione browse en la barra de menús. Observe la listadesplegada.

A continuación se da una lista básica de normas para la gestión deiconos, QUE SON VALIDAS PARA CUALQUIER CLASE DEDIAGRAMA, de los que veremos mas adelante.

Seleccionar icono de un Diagrama:• Llevar el puntero al interior del área del icono.• Presionar el botón izquierdo.• Se visualizaran cuatro pequeños cuadros en negrita en los vértices

del icono.

Verifiquelo:Con la clase actuator.Observe que el icono de Clase tiene tres zonas: la primera para elnombre de la clase, la segunda para los atributos y la tercera para lasoperaciones.

Modificar tamaño del icono:De un icono seleccionado(según el procedimiento anteriormenteexpuesto) se puede modificar su tamaño.

• Se sitúa el puntero sobre uno de los vértices en negrita que lodelimitan.

• Se presiona el botón izquierdo y manteniendo la presión sedesplaza el puntero hasta que el icono alcance el tamañodeseado.

Verifiquelo:Con la clase actuator.

Consultar el uso de un icono:De un icono seleccionado se puede consultar su uso.• En la barra de menú seleccione Report.• De la lista seleccione Show usage.



EUITIO-WLM 09/04/03 109

Observe la ventana que se presenta con todas las relaciones de laclase actuator en diferentes Diagramas de Clases.

Borrar, cortar, copiar, pegar...un icono.De un icono seleccionado también se pueden hacer tareas deedición.• En la barra de menú seleccione Edit.• ¡atención!: delete borra el icono del diagrama pero no del modelo.¡delete from model: borra el icono del modelo!

Verifiquelo:Haga delete de actuator. (¡no from model!)

Añadir un icono a un Diagrama:La clase actuator no esta en el Diagrama de Clases controller/Main,porque en el procedimiento anterior la ha borrado del Diagrama, perono del modelo.Una clase definida en el modelo puede ser añadida a un Diagrama deClases.

Verifiquelo• En la barra de menús seleccione Query.• Seleccione add classes, aparecerá una ventana con la lista de

clases que puede añadir al diagrama.• De la lista de clases seleccione actuator, después >>>> y

finalmente ok.

Observe que no solo se añade la clase actuator, sino también todaslas relaciones que tiene en este diagrama.

Mover un icono:• Situar el puntero dentro del área del icono.• Presione el botón izquierdo y manteniendo la presión desplace el

puntero hasta que el icono alcance la posición deseada.

Otra forma de mover un icono es, una vez seleccionado, moverlo conlas teclas de flechas de desplazamiento. Y si ademas se pulsa latecla ctrl, se desplaza más rápido.

Verifiquelo con cualquier icono.


EUITIO-WLM 09/04/03 110

Selección de un conjunto de iconos de un Diagrama:Manteniendo presionado el botón izquierdo, dibujar un rectángulo queintegre el conjunto de iconos que se desea seleccionar.

El conjunto seleccionado se puede mover al igual que se mueve unicono.

Especificaciones de un icono:Hasta este momento hemos manipulado la parte externa de un icono,en cualquier Diagrama cualquier tipo de icono tiene unasespecificaciones. Las especificaciones de un icono dependenevidentemente del tipo, es decir de lo que represente el icono.

Para crear, consultar, modificar las especificaciones de un icono:• Sitúe el puntero en el área del icono.• Haga doble pulsación el botón izquierdo.

Se presentara una ventana con diferentes paginas (general, detalle,operaciones, atributos, relaciones, etc.etc......), según la clase deicono, para en cada una de ellas realizar las especificaciones quecorrespondan al icono (actor, caso de uso, clase, relación deasociación, relación de agregación, etc., etc.).

Habrá iconos que no dispongan de especificaciones, en cuyo caso laacción de doble pulsación sobre el mismo no tendrá respuesta.

Las paginas de la ventana de especificaciones, pueden disponer dediferentes formas de introducir los datos: radio, check box, listas deselección, campos de entrada, listas de atributos, de operaciones, derelaciones, etc..

Para manipular las filas de las listas de atributos y de operaciones, alsituar el puntero en el área de la lista donde no haya filas y pulsar elbotón derecho, se desplegaran las acciones que podemos realizar,en este caso insertar una fila.

Si se quiere manipular una fila existente se coloca el puntero sobre lafila y se pulsa el botón derecho, desplegandose las acciones quepodemos realizar contra la fila.Para introducir las especificaciones de una fila de una lista deoperaciones, atributos o relaciones, colocar el puntero sobre la fila y


EUITIO-WLM 09/04/03 111

hacer doble presión en botón izquierdo o pulse botón derecho y elijade la lista de acciones..

Verifiquelo:• Haga doble pulsación sobre la clase actuator.Observe la información de la clase en sus diferentes apartados:General, Detalle, Operaciones, Atributos, Relaciones.• Observe que en estas tres últimas especificaciones, existe un

botón denominado:show inherited. Si esta activado, indica que en la lista estánincluidas las operaciones y atributos heredadas de otros.

• En la página de operaciones, pulse el botón derecho sobre laoperación startup.

• De la lista de acciones, elija especificación.

Como puede observar cada operación dispone de sus propiaspaginas de especificaciones (general, detalle, precondiciones,postcondiciones, etc.).

Lo mismo ocurrirá con las demás especificaciones básicas de unaclase (atributos y relaciones), los cuales tendrán sus propias páginas.

En resumen, para entrar en las especificaciones de un icono, haydos caminos :a)Doble pulsación botón izquierdo.b)Boton derecho y de la lista de acciones elegir especificación.

Pruebe insertar una operación en la lista de operaciones, porejemplo: fallo.No se olvide de las especificaciones de la operación.

Haga lo mismo con un atributo.

No se olvide de consultar las especificaciones de los tres tipos derelaciones que hay en el diagrama.

Visibilidad de un icono:Una vez que hemos dibujado e introducido las especificaciones quecorrespondan a un icono, podemos definir el nivel de visibilidadgráfica.


EUITIO-WLM 09/04/03 112

Ya hemos visto que al situar el puntero sobre la superficie del icono ypulsar el botón derecho, se despliega una ventana con las accionespermitidas.

La primera acción será casi siempre : especificación (es otra vía paraintroducir las especificaciones).

Las demás se refieren en general a las especificaciones quequeremos que se visualicen de forma gráfica.

Las operaciones se representan por un rectángulo inclinado de colorrosa.

Los atributos se representan por un rectángulo inclinado de colorazul.

En ambos casos, si son públicos solo el rectángulo, si son protegidosles acompaña una llave, si son privados les acompaña un candado ysi son de implementación les acompaña un martillo.


Dibujar un icono:• Situar el puntero sobre el icono en la paleta de iconos y presionar

botón izquierdo.• Llevar el puntero a la zona de la ventana del diagrama que se esta

dibujando y se visualizara una cruz.• El icono se dibujara en la posición de la ventana que se desee, al

presionar el botón izquierdo.

Verifiquelo:Añada la clase entrylog.

Dibujar n veces el icono seleccionado:Una vez elegido el icono, al llevar el puntero a la zona de la ventanadel diagrama que se esta dibujando y se visualizara una cruz.

El icono se dibujara tantas veces como se desee, al presionar elbotón izquierdo mientras se mantiene presionada la tecla shift.


EUITIO-WLM 09/04/03 113

Reordenar los iconos de un Diagrama:Los iconos que forman parte de un Diagrama, cuya ventana estaactiva, se pueden reordenar.• Seleccione en la barra de menú Tools y a continuación Layout

Diagram.

Zoom de un Diagrama:En la barra de iconos del menú, hay cuatro con el símbolo de lupaque le permiten aumentar o disminuir el tamaño del diagrama. El quetiene detrás un rectángulo le ajusta el diagrama al tamaño de laventana.


EUITIO-WLM 09/04/03 114

23.4 En ROSE : DIAGRAMA DE CASOS DE USO

R02 : MODELO DE REQUERIMIENTOS: Casos de Uso yEscenarios.

• Una vez arrancada la herramienta ROSE, en la barra de menússeleccionar: browse.

• De la lista de opciones desplegadas, seleccionar : use casediagram.

• En la nueva ventana abierta iniciar la definición de los casos deuso.

Para dibujar los casos de uso utilizar la paleta de iconos que se havisualizado, correspondiente a los Diagramas de Casos de Uso(actor, caso de uso, relación de asociación entre actor y caso de uso,notas y relaciones de generalización, estas últimas son para el casoen que dos o mas casos de uso o actores, compartan el mismo comportamiento).

Normalmente utilizará los iconos de:

Actor:

caso de uso

relación deasociación.:

Ademas, en el caso concreto del Diagrama de Casos de Uso, a lasespecificaciones que corresponden a cada uno de los iconos querepresentan un caso de uso, se podrán vincular ficheros de textoconstruidos con la herramienta que se disponga, con la que ROSE se


EUITIO-WLM 09/04/03 115

conectara directamente (Página file de las especificaciones del casode uso).

Por tanto, los ficheros de texto que describan cada caso de uso ysus escenarios, de acuerdo con el formato establecido en la Guía dePrácticas, se vincularan a este icono para disponer de toda ladocumentación integrada en ROSE.


EUITIO-WLM 09/04/03 116

23.5 En ROSE : DIAGRAMA DE CLASES.

A01 : ANÁLISIS DEL MODELO DE OBJETOSA04 : DESCRIPCIÓN DE CLASESD02 : DISEÑO DEL MODELO DE OBJETOSD05 : DESCRIPCIÓN DE CLASES.

Vuelva a presentar la ventana del Diagrama de ClasesController/Main.

Recuerde los pasos:a)En barra menú: browse.b)De la lista: Diagrama de clases.c)Categoria: Controller, Diagrama de Clases: Controller/Main.

Observe la paleta de iconos correspondiente a los Diagramas deClases.

La mayoría ya los conoce.

En especial observe que en ROSE hay cuatro iconos de clase:

Clase simple.

Clase simple parametrizada.

Clase utilidad.

Clase utilidad parametrizada.

Editar Clases:En las normas generales, se le indico el procedimiento para dibujarun icono.

Recuerde que añadió al Diagrama de Clases una nueva clasedenominada entrylog.


EUITIO-WLM 09/04/03 117

Recuerde que también borro la clase actuator(edit + delete) ydespués la añadió (query + añadir clase + seleccionar claseactuator).

Reordenar Operaciones:La lista de operaciones de una clase puede cambiarse de orden.

• Posicione el puntero sobre una operación de la lista (recuerdedoble pulsación sobre una clase para visualizar susespecificaciones y después elija la pagina de operaciones)

• pulse el botón izquierdo y manteniendolo pulsado• desplace el puntero a la posición de la lista a la cual quiera llevar

la operación.

Experimente con alguna clase.

Borrar una operación.• Seleccione una operación de la lista, pulsado sobre ella con el

botón izquierdo.• Pulse la tecla suprimir.

Editar relaciones:Supongamos que la clase entrylog “es parte de” la claseSystemlog.

Represente la relación anterior:• De la paleta de iconos, elija el icono de agregación. (pulsando

botón izquierdo).• Lleve el puntero hasta la clase entrylog,• pulse el botón izquierdo.• Mantenga el botón izquierdo pulsado y desplace el puntero hasta

la clase Systemlog.• Suelte el puntero.

Observe que el origen y destino del desplazamiento del puntero, aldibujar la relación, tiene el sentido de “entrylog es parte desystemlog”. En concreto el dibujo de relaciones contiene lógica. No loolvide.


EUITIO-WLM 09/04/03 118

Una relación puede borrarla del diagrama, una vez seleccionada, dedos maneras:a)Como se indico en las normas generales.b)Pulsando la tecla supresión.

Ya ha añadido una clase y una relación al Diagrama de Clases.

Ahora consulte las especificaciones de ambas clases: entrylog ysystemlog.Observe en la página de relaciones, que en la lista de relaciones estala que Vd. a incorporado.

Consulte las especificaciones de la relación:Recuerde que puede hacerlo de dos maneras:

a)Doble pulsación con el botón izquierdo, sobre la relación: Sepresenta un conjunto de páginas con las especificaciones de larelación con respecto a cada una de las clases relacionadas.

b)Pulse con el botón derecho sobre un extremo de la relación.Se despliega una lista de acciones y atributos. Los atributosvisualizados son los que corresponden a la relación con respecto a laclase más próxima. Para visualizar las especificaciones de la relaciónrespecto a la otra clase tendrá que repetir la operación en el otroextremo de la relación.

Verifiquelo:Experimente con la relación que ha creado, modificando atributos dela relación respecto a cada clase.

Observe que las relaciones pueden ser:a)Pública: Todos los clientes tienen acceso.b)Protegida: Solo tienen acceso subclases, friends o ellas mismas.c)Privada: Solo tienen acceso los miembros de la clase o friends.d)Implementación: Solo tiene acceso el paquete que contiene laclase.

Recuerde que si selecciona una clase de un Diagrama de Clases, ydespués selecciona en la barra de menú la opción report y despuésshow usage, le da la lista de relaciones en las que participa la clase.Editar Diagramas:


EUITIO-WLM 09/04/03 119

Supongamos que quiere crear un nuevo Diagrama de Clases,aprovechando parte de Diagramas existentes.

• En la barra de menús elija browse y después Diagramas de clase.• Continuamos con la Categoría de Clases controller.• En la columna de Diagrama de clases seleccione new.• Asigne un nombre al nuevo Diagrama de Clases.

Ya dispone de la ventana del nuevo Diagrama de Clases a construir.

Añadir Clases:Añada una clase existente al nuevo Diagrama de Clases, por ejemploactuator.Ya debe saber hacerlo, sino lo recuerda experimente.

Muy bien.

Expandir Clases:Ahora va a expandir la clase actuator hasta un primer nivel.• Seleccione query en la barra de menú y a continuación expandir

clase.• Observe la ventana visualizada. Puede expandir la clase

seleccionada hasta el nivel que quiera y también las relaciones(pulse en relaciones).Deje los valores por defecto y pulse ok.

Copiar clases de otro diagrama:Para moverse entre dos diagramas puede usar el icono de la barrade menú que esta representado por un cuadrado con la punta de unaflecha en color azul.• Vuelva al Diagrama de clases controller y seleccione un conjunto

de clases.• En la barra de menú seleccione edit y después copiar.• Vuelva a su diagrama de prueba.• Selecciones edit y después paste.

Reordenar los iconos de un Diagrama:• En la barra de menú seleccione tools.• De las acciones desplegadas seleccione layout diagram.


EUITIO-WLM 09/04/03 120

Moverse entre los Diagramas:Para moverse entre Diagramas también puede utilizar browse en labarra de menú.

Hagalo y observe que tiene tres opciones : parent (es el Main) / toplevel / previus.

Experimente.

Ver referencias en DIO’s:Se puede consultar en que Diagramas de Escenarios, participa unaclase.

• Seleccione una clase, por ejemplo environment controller.• En la barra de menú, seleccione report.• De la lista desplegada selecciones : show instances.


EUITIO-WLM 09/04/03 121

23.6 En ROSE : DIAGRAMA DE ESCENARIOS.

A02 : ANÁLISIS DEL DIAGRAMA DE INTERACCIÓN DEOBJETOSD03 : DISEÑO DEL DIAGRAMA DE INTERACCIÓN DE OBJETOS

Recuerde que el Diagrama de Clases nos daba una visión estáticadel Modelo.

El Diagrama de Escenarios (DIO en la Guía de Prácticas) nos da unavisión dinámica.

En ROSE los escenarios se representan gráficamente comoDiagrama de Escenarios y/o como Diagrama de Seguimiento deMensajes.

Un Diagrama de Escenarios se asocia con una Categoría de Clases,por tanto cada Categoría de Clases podrá tener sus Diagramas deEscenarios.

Suponemos que tiene activada la herramienta ROSE y abierto elModelo ULMTTUTOR. Si no es así hagalo. Si no recuerda comohacerlo, vaya al inicio de este documento y revise el apartado“Comenzar con Rose”.

Vamos a revisar los Diagramas de Escenarios de la Categoría deClases Controller.

Recuerde los pasos:a)En barra menú: browse.b)De la lista: Diagrama de escenariosc)Categoria: Controller,Observe que tiene dos Diagramas de Escenarios.Elija por ejemplo el de “arranque del aire acondicionado”.

Observe sus componentes: objetos, mensajes y enlaces y la paletade iconos que corresponde a este tipo de diagrama.

Ahora visitelos:(El procedimiento es el mismo que con los diagramas anteriores)


EUITIO-WLM 09/04/03 122

a)Objetos:• Doble pulsación botón izquierdo----> especificaciones. (se trata

básicamente de asignar un nombre al objeto de la clase queinterviene en el escenario).

• Pulsación botón derecho-----> adornos.

b)enlaces:Haga lo mismo.Observe que en sus especificaciones, se trata básicamente de daropcionalmente un nombre, definir el nivel de visibilidad y las lista demensajes asociados.

c)mensajes:Referencias a un objeto:

Consulte las especificaciones del objeto “temperature controller”(doble pulsación botón izquierdo).En la primera página (general) seleccione browse.

La lista desplegada, le da dos opciones:a)Ir a ver las especificaciones de la clase del objeto seleccionado.b)Ir a ver las especificaciones del padre de la clase del objetoseleccionado (en este caso de la Categoría de Clases: controller).

Experimente con ambas opciones.

Vuelva al Diagrama de Escenarios.

Otra forma de ver las referencias de un Objeto es:• Seleccione un objeto del Diagrama, por ejemplo “Temperature

Controller”• Seleccione browse de la barra de menú.• Seleccione referenced item.

Observe que se presenta el Diagrama de Clases Controller/Main, conla clase Environment Controller seleccionada.

Visibilidad:Los enlaces entre los objetos de un Diagrama de Escenerios tienenespecificaciones similares a las relaciones de un Diagrama deClases.


EUITIO-WLM 09/04/03 123

Los enlaces tienen especificaciones del lado del cliente y del lado delservidor.

Pulse el botón derecho en un extremo del enlace: Se presentan losatributos del objeto de ese lado.

Haga lo mismo con el otro extremo del enlace.

Estas especificaciones sirven para indicar el grado y tipo devisibilidad de un objeto respecto al otro. La visibilidad puede ser detipo parámetros, campos, global, local. Ademas la visibilidad puedeser compartida (cuando lo es para mas de un objeto).

Procedimiento para Dibujar los Diagramas de escenarios.Para cada paso, que se señala a continuación, elija el iconocorrespondiente de la paleta de iconos que corresponde al Diagramade Escenarios:

1)Se dibujan y definen los objetos del Diagrama. (Dibujar el icono,elegir la clase a la que pertenece el objeto y asignarle nombre alobjeto)

2)Se dibujan los enlaces entre los objetos. (similar a las relacionesentre clases).

3)Se definen los mensajes de cada enlace. En el orden en que seproducen y llevando el puntero sobre el enlace, se presiona el botónderecho.

Cada mensaje tendrá una operación, la cual se asigna de lasiguiente manera:

a)Pulse el botón derecho sobre la flecha del mensaje y elija laoperación de la lista de operaciones existentes (son las propias delobjeto mas las que hereda).Si la operación no esta definida:a´)Puede definir la operación en este momento para la clase quecorresponda o bien definirla a partir del Diagrama de Clases.


EUITIO-WLM 09/04/03 124

Para quitar un mensaje de un enlace, se hace al revés de como seasigno (pinchar botón derecho sobre el enlace y desasignar laoperación).Puede ocurrir que al dibujar el enlace de un objeto a otro, el sistemanos avise de que el objeto esta sin definir, en este caso definalo eneste momento para la clase que corresponda (elijala de la lista declases presentada).

Verificación:Una vez que finalice la definición de un Diagrama de Escenarios,pida el sistema que los verifique:a)En la barra de menú seleccione report.b)De la lista desplegada elija:Show unresolved objects.Show unresolved messages. (operaciones)

En cada caso, se le informara con la lista de los que no estánresueltos y la posibilidad de localizar sus referencias con browse,como ayuda a la depuración.

Cambiar la representación del Diagrama:El modelo de presentación gráfica del Diagrama de Escenarios,puede cambiarse automáticamente:a)Seleccione Browse en la barra menú.b) De la lista, seleccione go to ...........


EUITIO-WLM 09/04/03 125

23.7 En ROSE : DIAGRAMA DE ESTADOS.

A03 : MODELO DE ESTADOS DE OBJETOS.D04: DISEÑO DEL MODELO DE ESTADOS DE OBJETOS.

Recuerde que nos permitía representar el ciclo de vida de una clase.Las notación utilizada es: inicio de estado, estado de la clase , finalde estado y transición entre estados.

Este Diagrama podrá existir para cada clase del modelo.

Para crear, modificar o consultar este Diagrama:1)Seleccione una Clase del Diagrama de Clases.2)En la barra de menú, seleccione Browse.3)De la lista desplegada, seleccione Diagrama de Estados.

Verifiquelo con la Clase Environment Controller.

Al igual que en lo anteriores Diagramas, a cada icono lecorresponderá una especificación, siguiendo los mismosprocedimientos.A cada estado de la Clase, le corresponderá un nombre yopcionalmente unas acciones. Doble pulsación botón izquierdo sobreel estado.

A cada transición de estado, le corresponderá un evento(mensajerecibido) y/o una acción (mensaje enviado). Doble pulsación botónizquierdo sobre la transición.

Dentro de un estado pueden existir estados anidados, es decir unestado puede contener subestados, que seguirán las mismas reglasde definición. Si un estado tiene estados anidados, aparecerá unasterisco en su vértice inferior derecho. Con la opción view lossubestados se pueden visualizar u ocultar.

Referencias de un Estado:Las referencias a un estado de una clase, se consultan:a)Seleccione un estado.b)En la barra de menú, seleccione report.c)De la lista de acciones desplegadas, seleccione show usage.

Como podrá observar, la lista contiene todas las transiciones que danlugar al estado seleccionado.


EUITIO-WLM 09/04/03 126

23.8 En ROSE : DIAGRAMA DE MÓDULOS

D01 : MODELO DE SUBSISTEMAS.

Subsistema:

• Conjunto de módulos relacionados.

• Paralelismo con Categorías de Clase y Diagramas de Clases.

• Es un particionado físico del Modelo, las Categorías de Clases sonun particionado lógico.

• Se representa por un rectángulo con los vértices redondeados.

• Su nombre es único en el Modelo.

• Puede tener dependencias respecto a otros.

Definir o crear un Subsistema:a) En la barra de menú, seleccione browse.b) De la lista de acciones desplegadas, selecciones Diagrama deMódulos.

• Se presenta una ventana con dos listas, Subsistemas yDiagramas de Módulos.

• Cada Subsistema tendrá su lista de Diagramas de Módulos.• El Subsistema raíz es “Component View”.

Al menos el primer subsistema de su aplicación, será un Subsistemadel subsistema Raíz. Sigue la misma estructura que la Categorías deClases y sus jerarquías en Diagramas de Clases.

Cree su primer subsistema como un componente de un Diagrama deMódulos..

c)Para el Subsistema “Component View”, elija el Diagrama deMódulos “new”.

d)De la paleta de iconos de diagramas de módulos, elija el icono desubsistema y dibujelo en la nueva ventana de diagrama de módulos.


EUITIO-WLM 09/04/03 127

e)Para introducir las especificaciones del nuevo subsistema, sitúeel puntero sobre el icono del nuevo subsistema y pulse botónderecho.

La ventana de especificaciones del subsistema, contiene las paginas:general(asignar el nombre del subsistema), detalle (lista dediagramas de módulos del subsistema) y categorías (lista decategorías de clases existentes).

f)Para asignar una categoría de clases al subsistema, sitúe elpuntero sobre la fila correspondiente y pulse el botón derecho.

Con el mismo procedimiento puede anular la asignación.

Si ahora consulta la categoría de clases que ha asignado alsubsistema, podrá observar que la Categoría de Clases, en la paginade detalle, figura asignada al nuevo subsistema.

A un Subsistema puede asignarle varias Categorías de Clases.

La navegación para consultar o modificar las especificaciones de unSubsistema, es muy similar a la expuesta para su definición.

Pruebe la navegación:

1)En la barra de menú elija browse, de las acciones seleccioneDiagrama de Módulos.

2)En la ventana de Subsistemas y Diagramas de módulos, elija :Component View y Hidroponic.

3)Observe que Hidroponic, es realmente un Diagrama deSubsistemas.

4)Del conjunto de subsistemas que integra hidroponic, consulte susespecificaciones.

5)Observe que solo uno de los subsistemas contiene la definición deun Diagrama de Módulos.


EUITIO-WLM 09/04/03 128

Como podrá observar el subsistema que contiene el Diagrama deMódulos, tiene incompleta su definición, porque no tiene asignadaninguna Categoría de Clases.En consecuencia los módulos del Diagrama de módulos, no podrántener asignada ninguna clase.

Diagrama de Módulos:

• Representa las relaciones entre subsistemas y módulos.

• Representa una visión física del Modelo.

• Sirve para asignar Clases (de las categorías del clases asignadasal Subsistema) a Módulos.

• Sus componentes pueden ser subsistemas (anidamiento).

• Contiene:

- Subsistemas .

- Programa principal.Es el componente principal de unmodulo.Su nombre es único en el modulo.Representa a un fichero quecontiene la raíz de un programa, enC++ es el fichero xxxxxxx.cpp

- Paquete , consiste en:Módulo de especificación, que serepresenta por el fichero decabecera, que en C++ es elxxxxxx.h.(icono body).

actuator


EUITIO-WLM 09/04/03 129

Módulo de implementación,representado por el fichero cuerpo delmodelo, que en C++ es el xxxxxx.cpp.

- Subprogramas:

Son subrutinas. Una o varias.No pueden contener definición de clases

Especificación de Subprograma (modulo

Cuerpo de Subprograma (modulo)

.


EUITIO-WLM 09/04/03 130

Definición del Diagrama de Módulos:

- Sitúe el puntero sobre el icono del subsistema definido y haga doblepulsación con el botón izquierdo.

Otra opción es vía la barra de menú:

- Seleccione browse, diagrama de módulos, en la ventana desubsistema, elija su subsistema y “new” en Diagrama de Módulos.

Como al definir el Subsistema ya se ha asignado a una o variasCategorías de Clase, al definir los módulos se asignaran estos a lasclases correspondientes, a partir de la lista de clases de lasCategorías que corresponden al subsistema.

El proceso de asignación puede invertirse:

A una Categoría de Clases se le asigna un Subsistema (Browse +Diagrama de Clases + Especificaciones de la Categoría de clases, enbrowse + asignar subsistema).

A una clase de un Diagrama de clases, en sus especificaciones sepuede asignar el modulo.

final de la Guía resumida de ROSE


EUITIO-WLM 09/04/03 131

24 BIBLIOGRAFÍA.-

[Booch94] Grady Booch, Object-Oriented Analysis and Design withApplications, Benjamin/Cummings Publishing Company, inc. 1.994.

[Booch96] Rational Software Corporation, "The Unified ModelingLanguage for Object-Oriented Development, Julio 1.996.

[Cueva96] J.M. Cueva Lovelle, Cuaderno Didáctico 87 del Departamentode Matemáticas de la Universidad de Oviedo.

[Jacobs92] Ivar Jacobson, Magnus Christerson, Patrik Jonsson and GunnarÖvergaard, Object-Oriented Software Engineering: A Use Case DrivenApproach, Addison-Wesley Publishing Company, 1.992.

[OOREF96] IBM OOTC, Object-Oriented Software Development: AReference Guide, Prentice-Hall, 1996.

[Rumba95a] James Rumbaugh, "OMT: The Object Model", JOOP, Enero1.995.

[Rumba95b] James Rumbaugh, "OMT : The Dynamic Model", JOOP,Febrero 1.995.

[Rumba91] James Rumbaugh, Michael Blaha, William Premerlani,Frederick Eddy and William Lorenson, Object-Oriented Modeling andDesign, Prentice Hall, 1.991.

[Wirfs90] R. Wirfs-Brock, B. Wilkerson and L. Wiener, DesigningObject-Oriented Software, Prentice Hall, 1.990.

GUÍA DE CLASES PRÁCTICAS de Metodología Orientada a Objetos...

Documents

Transcript of GUÍA DE CLASES PRÁCTICAS de Metodología Orientada a Objetos...