Adoosi V6

Metodologa ADOOSI Versin 6: Metodologa para el desarrollo de
aplicaciones utilizando notacin UML y extensiones para Web y

servicios Web
Autor:
Dra. Sofa Alvarez Crdenas
Se presenta la metodologa ADOOSI-UML versin 6 para el desarrollo de
aplicaciones con tecnologa orientada a objetos utilizando notacin UML (Unified
Modeling Language) y la extensin de UML para aplicaciones Web (UML WAE:
Web Application Extension). Se utiliza la extensin para aplicaciones Web y se
incluyen elementos para la aplicacin de los Servicios Web. El ciclo de vida
utilizado es el iterativo e incremental y se basa en la utilizacin de componentes.
Se considera los Servicios Web como parte de los posibles componentes a utilizar
o desarrollar y se brindan recomendaciones para su uso. En el diseo se incluye la
utilizacin de los patrones GRASP (General Responsibility Assignment Software
Patters) y GoF (Gang of Four) y otros. La metodologa da un peso importante a la
definicin de la arquitectura de la aplicacin e incluye los patrones para el
desarrollo de esta en las aplicaciones Web. La presente gua metodolgica incluye
toda la documentacin a obtener para la aplicacin desarrollada, as como la
explicacin de cada etapa haciendo uso de ejemplos ilustrativos. La
documentacin propuesta por la metodologa se corresponde con la establecida
en la norma ISO 19 112. Se incluye el mapa de navegacin como instrumento de
diseo del comportamiento del prototipo y especficamente como instrumento de
diseo de la interfaz Web. Esta metodologa se basa tambin en la experiencia de
aplicar ADOOSI (Metodologa para el desarrollo orientado a objetos de sistemas
informticos).
Introduccin
1.1
Ciclo de vida del Proyecto.
1.2
Fases y pasos de la metodologa
1.2.1
Flujos dentro de cada ciclo de desarrollo
1.2.2
Fase Inicio
1.2.3
Fase de Elaboracin
1.2.4
Fase Construccin
1.2.5
Fase de Transicin
7
8
8
9
9
9
1.3
Fase Inicio
1.3.1
Obtencin del modelo del negocio
1.3.2
Definicin del alcance de la aplicacin
1.3.2.1 Identificacin de los involucrados
1.3.2.2 Formular el problema a resolver
1.3.2.3 Definicin de las facilidades del software
1.2.3.4 Definir los requisitos no funcionales
1.3.3
Confeccin de un prototipo de interfaz
1.3.4
Definicin de los casos de uso
1.3.4.1 Identificar los actores
1.3.4.2 Identificar los casos de uso
1.3.4.3 Describir los casos de uso
1.3.5
Seleccin de los casos de uso para cada ciclo
1.3.5.1 Identificacin del ncleo central de la aplicacin
1.3.5.2 Identificacin de los casos de uso del ncleo central de la aplicacin y los de cada ciclo
1.3.6
Analisis de factibilidad
1.3.6.1 Anlisis de la factibilidad econmica
1.3.6.2 Anlisis tcnico
1.3.7
Planificacin. Obtencin del cronograma general de la aplicacin
1.3.8
Balance de los artefactos
1.3.9
Revisin y completamiento de la documentacin
1.3.9.1 Obtencin del modelo del negocio
1.3.9.2 Definicin del alcance de la aplicacin
1.3.9.3 Requisitos no funcionales
1.3.9.4 Casos de uso
1.3.9.5 Anlisis de factibilidad
1.3.9.6 Cronograma general de la aplicacin
9
10
10
10
10
10
11
14
14
14
15
15
15
16
16
16
16
17
17
17
17
18
18
18
18
18
18
19
19
19
19
24
29
32
38
39
39
39
Fases
2.1
Flujo o disciplina de requisitos
2.2
Flujo o disciplina de anlisis
2.2.1
Obtencin de los casos de uso detallados
2.2.2
Definicin de las clases preliminares y de las asociaciones
2.2.3
Definicin del diagrama de clases del anlisis
2.2.4
Definicin de los diagramas de secuencia y asignacin de servicios o responsabilidades
2.2.3
Definicin de las operaciones de las clases
2.2.4
Balanceo de los artefactos
2.2.5
2.2.5.1 Paquetes de los casos de uso
2.3
Flujo o disciplina de diseo
2.1.1
Definicion de la arquitectura
2.1.1.1 Definicin del patrn de arquitectura
43
43
43
2.1.1.2 Definicin del modelo de mini arquitectura (framework)

2.1.1.3 Identificar subsistemas
2.1.1.4 Definicin de servicios Web
2.1.1.5 Definicin del Diagrama de subsistemas funcionales
2.1.1.6 Definicin de las clases y paquetes ms significativos
2.3.2
Obtencin de los diagramas de clases del diseo
2.3.2.1 Refinamiento de las clases
2.3.2.2 Refinamiento de las asociaciones e inclusin de dependencias
2.3.3
Refinamiento de los diagramas de interaccin
2.3.4
Refinamiento de los atributos y responsabilidades de las clases
2.3.4.1 Refinamiento de los atributos
2.3.4.2 Refinamiento de las responsabilidades
2.3.5
Aplicacin de patrones de diseo
2.3.5.1 Patrn Polimorfismo
2.3.5.2 Patrn Fbrica Abstracta
2.3.5.3 Patrn Indireccin
2.3.5.4 Patrn Publicar-Suscribir u Observador
2.3.5.5 Patrn No hables con extraos
2.3.5.6 Patrn Mtodo Factora
2.3.5.7 Patrn Solitario (Singleton)
2.3.5.8 Patrn Adaptador (Adapter/Wrapper)
2.3.5.9 Patrn Composicin (Composite)
2.3.5.10
Patrn Decorador (Decorator
2.3.5.11
Patrn Fachada (Facade)
2.3.5.12
Patrn Proxy
2.3.5.13
Patrn Comando (Command)
2.3.5.14
Patrn Mediador (Mediator)
2.3.5.15
Patrn Estado (State)
2.3.5.16
Patrn Estrategia (Strategy)
2.3.5.17
Patrn Mtodo Plantilla (Template Method)
2.3.5.18
Patrn Transaccin (script transaction)
2.3.5.19
Patrn Modelo del Dominio (Domain Model)
2.3.5.20
Patrn Record Set
2.3.5.21
Patrn Gateway
2.3.5.22
Patrn Data Mapper
2.3.5.23
Patrn Modulo Tabla (Table Module)
2.3.5.24
Patrn Objeto de Transferencia de Datos (Data Transfer Object)
2.3.5.25
Patrn Assembler
2.3.6
Definicin de los diagramas de Transicin de Estado
2.3.7
Confeccin de los diagramas de componentes
2.3.8
Definicin de la base de datos relacional
2.3.9
Balanceo de los artefactos
2.3.10 Revisin y completamiento de la documentacin
2.3.10.1
Diagramas de capas.
2.3.10.2
Diagramas de paquetes
2.3.10.3
Definicin de las clases
2.3.10.4
Base de datos relacional
2.4
Flujo o disciplina de Implementacin

2.4.1
Programacin y prueba de cada clase del subsistema
2.4.2
Integracin de cada subsistema
2.4.3
Integracin del software y prueba de la integracin de ste
2.4.4
2.4.4.1 Manual del usuario
2.4.4.2 Manual de instalacin
47
49
50
50
51
52
53
57
64
64
64
64
65
66
67
67
68
69
70
71
72
73
74
74
75
76
77
78
79
80
81
82
82
82
83
83
84
85
85
89
90
93
93
93
94
95
95
96
96
96
96
96
96
97
99
2.4.4.3
Manual de operacin
99
2.5
Disciplina o flujo de prueba
2.5.1
Prueba de validacin del software
2.5.2
Prueba del sistema
2.5.2.1 Prueba de recuperacin
2.5.2.2 Prueba de seguridad
2.5.2.3 Prueba de resistencia
2.5.2.4 Prueba de rendimiento
2.5.3
Balanceo de artefactos y planificacin del prximo ciclo
101
101
101
101
101
101
102
102
2.6
Fase de Transicin
2.6.1
Preparacin de condiciones
2.6.2
Implantacin o despliegue del sistema
2.6.2.1 Implantacin en Paralelo
2.6.2.2 Implantacin directa
103
103
103
103
103
BIBLIOGRAFA
105
Metodologa ADOOSI Versin 6: Metodologa para el desarrollo de

aplicaciones utilizando notacin UML y extensiones para Web y
servicios Web
Autor:
Dra. Sofa Alvarez Crdenas
Introduccin
Se presenta la metodologa ADOOSI-UML versin 6 para el desarrollo de
aplicaciones con tecnologa orientada a objetos utilizando notacin UML (Unified
Modeling Language) ) [Booch, 1997 ] y la extensin de UML para aplicaciones
Web (UML (WAE: Web Application Extension) [Conallen 99]. La notacin UML se
ha convertido en un estndar internacional para el desarrollo de aplicaciones por
lo que la notacin ha sido tomada de forma rigurosa en la metodologa propuesta.
Se utiliza la extensin para aplicaciones Web y se incluyen elementos para la
aplicacin de los Servicios Web. El ciclo de vida utilizado es el iterativo e
incremental y se basa en la utilizacin de componentes. Se considera los Servicios
Web como parte de los posibles componentes a utilizar o desarrollar y se brindan
recomendaciones para su uso. En el diseo se incluye la utilizacin de los
patrones GRASP (General Responsibility Assignment Software Patters) [Larman] y
a los GoF (Gang of Four) [Gamma].
La metodologa da un peso importante a la definicin de la arquitectura de la
aplicacin e incluye los patrones para el desarrollo de esta en las aplicaciones
Web. Como se especific antes, la metodologa se basa en el desarrollo
incremental e iterativo lo que significa que el desarrollo no se realiza de una sola
vez para toda la funcionalidad de la aplicacin sino que se realiza por ciclos en
cada uno de los cuales se agrega una funcionalidad adicional, se comienza con la
funcionalidad correspondiente al ncleo central de la aplicacin (de manera
general el ncleo central de la aplicacin se corresponde con la funcionalidad que
determina la arquitectura de la aplicacin) y se van agregando funcionalidades en
cada ciclo hasta alcanzar la aplicacin final. Por tanto el desarrollo se realiza de
forma incremental e iterativo tal y como se especifica en las mejores prcticas de
elaboracin de proyectos informticos [Pressman, 1997] y es recomendado en el
proceso de Rational [Kruchten, 1999].
La presente gua metodolgica incluye toda la documentacin a obtener para la
aplicacin desarrollada, as como la explicacin de cada etapa haciendo uso de
ejemplos ilustrativos. La documentacin propuesta por la metodologa se
corresponde con la establecida en la norma ISO 19112.
Los artefactos (diagramas, documentos y productos asociados al desarrollo en
general utilizados son los correspondientes a la notacin UML [OMG] y UML
(WAE) para el anlisis y el diseo pero con algunas modificaciones para tener en
cuenta las caractersticas especiales del desarrollo de la aplicacin. Se incluye el
mapa de navegacin como instrumento de diseo del comportamiento del
prototipo y especficamente como instrumento de diseo de la interfaz Web. Esta

metodologa se basa tambin en la experiencia de aplicar ADOOSI (Metodologa
para el desarrollo orientado a objetos de sistemas informticos) [Alvarez]. ADOOSI
contempla el hecho de que existe una coexistencia entre el modelo Orientado a
Objetos y el relacional por lo que tiene en cuenta la posibilidad de utilizar Bases de
Datos relacionales aunque el diseo sea Orientado a Objetos y se trabaje en un
ambiente Orientado a Objeto.
El desarrollo se centra en la concepcin de la arquitectura de la aplicacin y para
ello se hace uso de las tcnicas de prototipos. En los medios de programacin
disponibles se posibilita, en general, la confeccin de un prototipo del sistema
[Boar, 1984] e inclusive evolucionar este prototipo en el software final, por esta
razn se basa en la filosofa de trabajo que hace uso de prototipos [Connell,1989].
Un prototipo no es ms que una versin de un producto de software desarrollado
en los primeros estadios del ciclo de vida de un producto elaborado para
propsitos especficos y experimentales [Currie, 1998].
Un prototipo de software tiene las siguientes caractersticas:
es barato de construir
enfatiza en la interfaz del usuario
es un sistema vivo de trabajo.
es un sistema de software que se crea rpidamente.
suministra un medio de comunicacin efectivo con el usuario
puede ser evaluado por un diseador y/o los usuarios finales
Uno de los cambios introducidos en ADOOSI Versin 6 es lo referente al uso de

patrones de diseo.
Christopher Alexander de profesin Arquitecto defini el trmino patrn para
representar problemas de diseo y sus soluciones generales. Luego de trabajar
sobre la obra de Christopher Alexander [Coplien 96], los investigadores
descubrieron problemas recurrentes y sus respectivas soluciones en el desarrollo
de software. Es desde entonces, que el concepto de patrn se extiende al mundo
de la informacin.
Existe una tendencia en determinadas compaas de, querer continuamente
reinventar; esto puede verse fcilmente en proyectos que dan solucin a
problemas que anteriores proyectos haban solucionado tambin. Esto da al traste
con buenos diseos y provoca, frecuentemente, el fracaso en el desarrollo del
proyecto. Es aqu donde intervienen los patrones, los cuales son una solucin
extremadamente flexible para la reutilizacin de cdigo. Un buen nmero de
patrones que documenten buenas prcticas, podran solucionar grandes
problemas en un dominio determinado.
El poder de este tipo de documentacin es que el conocimiento, previamente
adquirido por desarrolladores con experiencia, es capturado en una forma
aceptable y puesto al alcance de todos. Los patrones son objetos que han sido
descubiertos en ms de un sistema existente, son soluciones exitosas a

problemas recurrentes [Rising 98].
A pesar que la mayora de los estudios realizados han sido dirigidos al desarrollo
orientado a objetos, y la mayora de publicaciones y descubrimiento de patrones
se ha realizado sobre este paradigma, la nocin de patrones no se encuentra
ligada a ninguna metodologa o lenguaje. Muchos trabajos sobre patrones han
sido desarrollados en sistemas no orientados a objetos. Los patrones no son un
concepto orientado a objetos [Rising, 1998].
Los principales patrones cuyo uso se recomienda en ADOOSI son:
Experto, Creador, Bajo Acoplamiento, Alta Cohesin, Controlador, Polimorfismo,
Fabricacin pura, Indireccin, No hables con extraos, Publicar-Suscribir, Mtodo
abstracto, Constructor, Solitario, Composicin, Fachada, Proxy, Decorador y
Adaptador. Especficamente para las aplicaciones Web se recomienda los
patrones: Modelo-Vista-Controlador, Controlador de pgina, Controlador de
fachada, Plantilla de Vista y Vista Transformada.
Tambin se utilizan los patrones de Mini arquitectura.
Se tiene una experiencia de nueve aos en la utilizacin de ADOOSI, por lo que la
presente metodologa hereda los instrumentos y procedimientos de ADOOSI e
incluye nuevos instrumentos y procedimientos para el desarrollo visual de
aplicaciones orientadas a objetos.
1.1 Ciclo de vida del Proyecto.
A continuacin se detallan las fases de las etapas de la metodologa propuesta.
1.2 Fases y pasos de la metodologa
Las fases de ADOOSI son:
Inicio: Definicin del alcance del trabajo, del plan y de los requisitos de la
aplicacin
Elaboracin: Definicin de la arquitectura de la aplicacin y del analisis de la
aplicacin
Construccin: Se construye el software en varias iteraciones
Transicin: Implantacin y distribucin de la aplicacin
Se toman estas fases acorde con los nombres utilizados por RUP: Rational Unified
Process [Booch] por considerarse un estndar de facto internacionalmente.
A continuacin se detallan los pasos de cada fase de la metodologa, pero como
se trata de un enfoque iterativo e incremental en el que se realizan varias
iteraciones, se define como ciclo la realizacin de una iteracin. En las iteraciones
de Arquitectura se trabaja con un prototipo ejecutable. Una representacin grfica
de los ciclos o iteraciones en las fases se muestra en la figura 1.
Entregas
Inicio
Iteracin
Preliminar
Iteraciones
Elaboracin
Construccin
Transicin
Iteracin de Iteracin de Iteracin de Iteracin de Iteracin de Iteracin de Iteracin de

Arquitectura ArquitecturaConstrucci Construcci Construcci Transicin Transicin
internas
externas
Figura 1 Iteraciones por fase recomendado para proyecto mediano. Para proyecto
pequeo la definicin de arquitectura puede hacerse en una sola iteracin.
A continuacin se define los flujos de procesos que incluye un ciclo de desarrollo:
1.2.1 Flujos dentro de cada ciclo de desarrollo
Anlisis: Incluye definir nuevos requisitos: funcionales y no funcionales. Refinar,
completar e incluir nuevos casos de uso. Se utiliza adems los diagramas de
actividad. Definir los diagramas de clases, de interaccin, de transicin de estado
de forma lgica sin incluir los elementos propios de la arquitectura definida ni los
elementos de los requisitos no funcionales. Se desarrolla adems el grafo de
navegacin.
Diseo: Modificar los diagramas de clases y de secuencia. Incluir interfaces a las
clases, paquetes y servicios Web. Incluir los elementos propios de la arquitectura
y de los requisitos no funcionales. Lo anterior tiene en cuenta a los elementos
propios de la aplicacin Web. Se modifica el resultado del analisis con la
aplicacin de patrones de diseo. Definicin de los componentes y su vinculacin
con las clases.
Implementacin: Se realiza la codificacin de lo diseado teniendo en cuenta la
distribucin por componentes. Se utilizan los estndares de codificacin
disponibles.
Prueba: Se realiza las pruebas contra requisitos y casos de uso definidos. Para
ello se utilizan los casos de prueba definidos previamente
1.2.2 Fase Inicio
Los pasos en esta fase son:
Definicin de los requisitos del sistema a nivel general (facilidades) de
manera de poder describir el alcance de la aplicacin.
Definicin de los casos de uso, solo registrar el resumen de cada uno
Estimacin de tiempo esfuerzo y costo mediante COCOMO II [Bohem]
1.2.3 Fase de Elaboracin

Detallar los casos de uso
Definicin de los casos de uso mas significativos para la aplicacin y de la
prioridad de todos
Definicin de los casos de uso a realizar en cada ciclo
Realizacin de uno o dos ciclos de desarrollo hasta completar el desarrollo
de los casos de uso seleccionados como mas significativos
Definicin de los componentes a desarrollar como servicios Web y de los
servicios Web de terceros a emplear
Definicin de la arquitectura de la aplicacin teniendo en cuenta los
patrones de las mini arquitectura
1.2.4 Fase Construccin
Realizacin de tantos ciclos como sea necesario para completar la
realizacin de todos los casos de uso
Realizacin de las pruebas de unidad y de integracin.
Obtencin del resultado de un ejecutable vlido para realizar la prueba Beta
de la aplicacin.
1.2.5 Fase de Transicin
Distribuir la aplicacin en el medio fsico
Entrenar a los usuarios
Realizar actividades de cambio en la organizacin
Evaluar el producto instalado contra el alcance del producto
Liberar el producto y evaluar extensiones y modificaciones
1.3 Fase Inicio

La etapa de estudio preliminar permite especificar los objetivos y el rendimiento
del software, la interfaz con otros elementos del sistema y las restricciones de
diseo que debe considerar el software
Obtencin del modelo del negocio
Definicin del alcance de la aplicacin
Confeccin de un prototipo de interfaz
Definicin de los casos de uso
Seleccin de los casos de uso para cada ciclo
Anlisis de factibilidad
Balance de los artefactos
1.3.1 Obtencin del modelo del negocio

La obtencin del modelo del negocio es opcional, normalmente solo se realiza si
este trabajo es renumerado de forma independiente. Este modelo consiste en la
descripcin mediante Casos de uso y Diagramas de actividad de la forma en que
la gestin se realiza en el objeto a automatizar, puede ser un sistema manual o
tener algo informatizado. En el anexo 1 se describen los diagramas de actividad.
1.3.2 Definicin del alcance de la aplicacin
Esta fase implica la identificacin de las necesidades del usuario por lo que el
analista debe utilizar todas las tcnicas de obtencin de informacin que considere
apropiadas tales como entrevistas, encuestas, revisin de documentos, tcnicas
de trabajo en grupo, etc.
Se realizan cuatro pasos:
Identificacin de los involucrados.
Formular el problema a resolver
Definir las facilidades del sistema
Definir los requisitos no funcionales
1.3.2.1 Identificacin de los involucrados
Se debe identificar los usuarios finales (hacen uso del sistema que ser
construido) y los expertos (patrocinadores y consultantes conocedores del dominio
del sistema), los clientes, as como las reas de actividades fundamentales del
sistema (se refiere a las reas que requieren anlisis de sistema).
1.3.2.2 Formular el problema a resolver
Debe definirse el problema a resolver de manera general mediante un prrafo
reflejando los antecedentes correspondientes, existencia o no de sistemas
automatizados o manuales. Debe identificar las dificultades actuales que provocan
la realizacin del sistema. Se requiere describir el lugar y el entorno donde ser
realizado el sistema. Debe definir las restricciones impuestas por el usuario y las
tcnicas impuestas por el hardware, software o tecnologa productiva y de servicio
as como las restricciones financieras que limitan los gastos del proyecto y los
lmites de tiempo para el desarrollo del proyecto. Se debe definir las fronteras del
sistema.
Es necesario profundizar sobre la informacin que se maneja en cuanto a
caractersticas, volmenes y calidad de sta. Se detalla el funcionamiento del
objeto de estudio. Para ello se debe describir los procesos que sern
automatizados.
1.3.2.3 Definicin de las facilidades del software
El analista, de forma conjunta con el usuario, definir las facilidades del sistema
(producto a obtener): la informacin que se va a generar, lo que se va a
suministrar y el rendimiento requerido. Debe distinguirse lo que "necesita" el
usuario (los elementos crticos) y lo que el usuario "quiere" (los elementos
deseables pero no esenciales).
Se debe profundizar, partiendo del problema a resolver, para definir las

facilidades del sistema.
De manera general una facilidad es una capacidad que el sistema debe cumplir.
Por ejemplo para el sistema de transplante renal se pueden definir los siguientes
requisitos funcionales:
1. Mantener informacin sobre los pacientes
Para obtenerlas se pregunta.
Qu debe hacer el sistema ?.
Se trata de la determinacin clara y concisa de qu debe ser capaz de hacer el
sistema y como lo debe hacer. Cada facilidad debe enunciarse mediante
oraciones simples.
Ejemplo de facilidades para un sistema de Ventas puede ser:
Poder mantener la informacin de los clientes y de sus cuentas asociadas
Garantizar la seguridad por perfiles de usuario
Observe que las facilidades pueden ser funcionales y no funcionales y que
poseen un carcter general.
El analista debe evaluar las facilidades del sistema de acuerdo a los siguientes
elementos:
Disponibilidad de la tecnologa necesaria.
Recursos de fabricacin y de desarrollo especiales que se requieren.
Dificultades actuales en el objeto de estudio.
Lmites de costo y de tiempo de desarrollo.
Si se trata de un software para la venta:
-. Mercado potencial para el producto
-. Comparacin del producto con otros similares.
-. Lugar del producto dentro de la lnea de productos de la empresa.
.
1.2.3.4 Definir los requisitos no funcionales
Se debe definir los requisitos no funcionales del software a desarrollar. Implica la
determinacin de los atributos no funcionales asociadas a las facilidades y de
caractersticas generales del software como controles necesarios para garantizar
la confiabilidad del sistema , seguridad propuesta, requisitos de la calidad,
interfaces con otros sistemas de procesamiento manual o automatizado, ambiente
de software y hardware.
Los requisitos no funcionales ms importantes se describen a continuacin:
Apariencia o interfaz externa
Se debe obtener respuesta a la pregunta: Cmo debe ser la interfaz?
Las caractersticas deseadas mas comunes se presentan a continuacin:
Muy legible
Simple
Interactiva
Autoritaria para que los usuarios se sientan confiados
Colorida y atractiva para nios
De tipo Profesional o ejecutivo
Usabilidad
Describe los niveles apropiados de usabilidad teniendo en cuenta los siguientes

elementos.
Qu tipo de personas son?
Qu tipo de producto necesitan para realizar su trabajo?
Qu tipo de requisito de usabilidad hara el producto apropiado para ellos?
Debe definirse adems:
Por ciento de aceptacin requerido de la aplicacin
Productividad a ganar en la introduccin
Proporcin de errores admisibles
Facilidad de uso por personas sin experiencia o por extranjeros
Consistencia en la interfaz requerida con otras aplicaciones
Documentacin de usuarios requerida
Rendimiento
Se deben describir las caractersticas siguientes:
Velocidad de procesamiento
Eficiencia
Disponibilidad
Precisin
Tiempo de respuesta
Tiempo de recuperacin
Aprovechamiento de los recursos
Requisito de Soporte
Se debe considerar todos los aspectos que influyan en el soporte de software a
realizar como servicio de posventa. Entre esos factores se encuentran:
Necesidades de la instalacin del software
Posibilidad de extensibilidad del software
Necesidad de adaptabilidad
Necesidad de mantenimiento
Necesidad de compatibilidad
Tipos de pruebas requeridas
Otros servicios de soporte
Necesidad de internacionalizacin del software
Requisito de Portabilidad
Debe usarse para especificar que el producto de software podr ser usado en
diferentes plataformas
Requisitos de Seguridad
Debe especificarse los siguientes factores:
Confidencialidad: Informacin protegida de acceso y divulgacin
Integridad: Proteccin contra corrupcin o estados inconsistentes
Disponibilidad: Los usuarios autorizados tienen acceso garantizado a la
informacin
Requisitos Polticos culturales
Debe tenerse en cuenta factores especiales que pudieran hacer al producto no

utilizable debido a costumbres humanas, preferencias o prejuicios
Requisitos Legales
Requisitos que estipulan la forma en que el software cumple las leyes vigentes o
estndares.
Requisitos de confiabilidad
Debe tenerse en cuenta los lmites para los siguientes factores:
Respuesta del sistema ante fallas
Frecuencia y severidad admisible de las fallas
Proteccin contra fallos
Recuperacin ante errores
Prediccin de fallos
Tiempo medio entre fallas
Requisito de interfaz interna
Debe tenerse en cuenta cmo interactuar con el sistema a travs de software. Se
considera interfaces a componentes comprados o reusados de otras aplicaciones
o estndares como CORBA, DCOM, COM, ETC.
Requisito de ayuda y documentacin en lnea
Debe tenerse en cuenta los siguientes elementos:
Fichero README:TXT
Se requiere instrucciones de instalacin
Existen derechos de autor
Se tiene logos corporativos
Se tiene iconos y otros elementos de la interfaz
Requisito de Software
Debe considerarse de cuales software se debe disponer.
Requisito de Hardware
Debe considerarse de cuales elementos de hardware se debe disponer.
Restricciones en el diseo y la implementacin
Debe considerar las vinculadas a los siguientes elementos:
Estndares requeridos
Lenguajes de programacin a usar
Herramientas de desarrollo a usar
Restricciones en la arquitectura
Bibliotecas de clases
1.3.3 Confeccin de un prototipo de interfaz

El objetivo es construir una versin inicial del prototipo donde se muestre un
esqueleto del sistema con las responsabilidades como quedaran aunque no se
llegue a los ltimos detalles de implementacin.
En este punto debe disearse las pantallas de interaccin con los usuarios. No se
requiere que se incluya como parte de la documentacin las pantallas
correspondientes. Se recomienda que se implemente en el medio de
programacin a utilizar o en uno similar dichas pantallas. Este prototipo debe
mostrar los datos de forma esttica (No se permite realizar las transformaciones
de los datos de entrada en los de salida)
El objetivo de la prueba del prototipo inicial es revisar, observar, criticar y dar
experiencia por parte de otros sobre si estn reflejados los requisitos.
Las primeras interacciones pueden concentrarse en:
- le resulta familiar lo que ve?
- se pas algo por alto?
- es cmodo y familiar al usuario el trabajo con el modelo?
Esta fase se puede dar por terminada cuando cada cosa que el usuario quera que
hiciera el sistema ha sido revisada por l.
Se describe la interfaz mediante un grafo conversacional, ver anexo 1
1.3.4 Definicin de los casos de uso
Un caso de uso es un documento narrativo que describe la secuencia de eventos
de un actor (agente externo) que utiliza un sistema para completar un proceso.
Los casos de uso describen los procesos y no son instrumentos que se
correspondan con el enfoque orientado a objetos por lo que pueden ser utilizados
para la obtencin de los requisitos del sistema y para comunicar la funcionalidad y
el comportamiento al cliente, al usuario y al equipo de proyecto.
Un Caso de Uso es una secuencia de acciones que obtienen resultados de valor
para un actor y un Actor representa cualquier cosa que interacta con el sistema
que puede ser un humano o un software o hardware.
Este paso se realiza segn el siguiente orden:
Identificar los actores
Identificar los casos de uso
Describir los casos de uso
1.3.4.1 Identificar los actores
Los actores se caracterizan por:
No son parte del sistema, son roles de un usuario
Pueden intercambiar informacin con el sistema
Pueden ser un recipiente pasivo de informacin
Pueden representar a un humano a una mquina o un software
Para identificar los actores en el contexto de la aplicacin deben realizarse las
siguientes preguntas:
Quien est interesado en cierto requisito?
Dnde en la organizacin es usado el sistema?
Quienes usan, eliminan o suministran informacin?

Quien usa una funcin?
Quien soporta y mantiene el sistema?
Usa el sistema un recurso externo?
Cules actores necesitan el caso de uso?
Un actor juega diferentes roles o varios actores juegan el mismo rol?
1.3.4.2 Identificar los casos de uso

Se tiene dos mtodos para identificar los casos:
Mtodo basado en los Actores
Mtodo basado en Eventos
En el mtodo basado en los actores se tiene en cuenta lo siguiente:
Se relacionan los actores relacionados con un sistema o empresa
Para cada actor, se identifican los procesos que inician o en que participan
En el mtodo basado en los eventos se tiene en cuenta lo siguiente:
Se identifican los eventos externos a los que un sistema debe responder
Se relacionan los eventos con los actores y con los casos de uso
1.3.4.3 Describir los casos de uso
Para cada caso de uso se realiza la descripcin utilizando el siguiente formato:
Caso de Uso
<Nombre del caso de uso>
Actores
<Lista de los actores involucrados>
Descripcin
<Resumen descriptivo de los pasos que incluye el proceso
asociado al caso de uso>
Facilidades:
<Lista de las facilidades relacionadas con el caso, nmero>
Ejemplo: Para una aplicacin de control de transplantes renales, se tendra:
Caso de Uso: Transplantar un rin
Actores: Cirujano, paciente, forense
Descripcin
Un rin es analizado por el forense, el cual lo enva a ciruga
donde el equipo de cirujanos solicita a medicina interna que les
enve los datos de los posibles receptores. Admisin se encarga
de localizar a los receptores. Los cirujanos valoran los receptores
posibles y operan el paciente seleccionado. Toda la informacin
producto del transplante es guardada en el expediente del
paciente y en el registro de transplantes
Facilidades: 1, 2, 3
1.3.5 Seleccin de los casos de uso para cada ciclo
Se realiza en los siguientes pasos:
Identificacin del ncleo central de la aplicacin
Identificacin de los casos de uso del ncleo central de la aplicacin y los
de cada ciclo
1.3.5.1 Identificacin del ncleo central de la aplicacin

Se deben seleccionar los casos de uso que influyan profundamente en la
arquitectura bsica, dando soporte al dominio y a las capas de servicio de alto
nivel o los que presenten el mximo riesgo, funciones urgentes o complejas
Se deben seleccionar los casos de uso que:
requieran investigacin a fondo o nueva tecnologa
representen procesos primarios de la lnea de negocio
apoyen directamente el aumento de ingresos o la reduccin de costos
Adems se debe incluir un caso de uso de inicio o arranque de la aplicacin.
Debe tener en cuenta que un caso de uso puede abordarse en varios ciclos.
Identificacin de los casos de uso del ncleo central de la aplicacin y
los de cada ciclo
Se debe registrar los casos de uso que se correspondan con el ncleo central de
la aplicacin y luego definir los subconjuntos de casos de uso que deben ir
adicionndose en cada ciclo de desarrollo. Para estos ltimos se debe priorizar la
funcionalidad a incluir de acuerdo a los intereses del usuario y del cliente.
1.3.5.2
1.3.6 Analisis de factibilidad

El estudio de factibilidad conlleva la realizacin de los siguientes pasos:
Anlisis de la factibilidad econmica.
Anlisis de la factibilidad tcnica.
1.3.6.1 Anlisis de la factibilidad econmica
La justificacin econmica de un producto de software incluye un amplio rango de
aspectos entre los que se encuentran el anlisis de costo-beneficio, las estrategias
de ingreso a largo plazo, el impacto en los centros de explotacin, el costo de los
recursos que se necesitan para el desarrollo y el crecimiento potencial del
mercado.
El anlisis de costo-beneficio consiste en contrastar los costos de desarrollo del
proyecto con los beneficios tangibles e intangibles del sistema.
Para el clculo del costo de desarrollo de un proyecto orientado a objetos, se
recomienda realizar este clculo mediante las tcnicas de COCOMO II [Boehm,
1981] y [Boehm, 2000].
La obtencin de los beneficios del sistema se realiza de acuerdo a las
caractersticas de ste. Para los sistemas de proceso de datos los beneficios
principales son: una mejor cantidad, rapidez y organizacin de la informacin. Los
beneficios que se puedan asociar a programas de anlisis cientficos y de
ingeniera difieren substancialmente y requieren un anlisis casustico.
Los beneficios de un sistema nuevo siempre se determinan comparando el modo
de trabajo manual ya existente con el automatizado propuesto.
Debe estimarse el costo de desarrollo, la economa anual, la eficiencia econmica
y el tiempo de recuperacin.
1.3.6.2 Anlisis tcnico

El anlisis tcnico es difcil de evaluar debido a que los objetivos, las funciones y
el rendimiento son de alguna manera confusos, cualquier cosa puede parecer
posible si se hacen las consideraciones adecuadas.
Debe tener en cuenta los siguientes elementos:
Riesgo de desarrollo: Delimite si se alcanzan los objetivos y el rendimiento
requerido dentro de las restricciones determinadas al identificar las necesidades
del usuario.
Disponibilidad de recursos: Delimite si se posee el personal calificado.
Tecnologa: Delimite si se dispone de la tecnologa para soportar el sistema.
Anlisis de alternativas de sistemas
Cada responsabilidad del sistema con su rendimiento requerido y sus
caractersticas de interfaz es asignada a uno o ms elementos del sistema
(software, hardware o personas). Hay diferentes formas de realizar esta
asignacin por lo que da lugar a distintas alternativas de solucin.
Para cada alternativa o variante de solucin se hace una evaluacin teniendo en
cuenta los resultados de los anlisis de la factibilidad econmica y el anlisis
tcnico.
Para la mejor variante revise las responsabilidades antes obtenidas y obtenga un
nuevo listado donde coloque las responsabilidades del software.
1.3.7 Planificacin. Obtencin del cronograma general de la aplicacin
Se debe confeccionar un plan por etapas, indicando fecha de inicio y de
terminacin. Utilice COCOMO II [Bohem, 2000] para este fin.
1.3.8 Balance de los artefactos
En esta fase se debe garantizar que todos los artefactos desarrollados estn
libres de inconsistencias. Los artefactos con que se cuenta son los casos de uso
definidos de forma general, la definicin de cuales se corresponden con el ciclo a
desarrollar, el prototipo, los requisitos funcionales y los atributos correspondientes.
Debe realizar las siguientes comprobaciones:
La definicin general de cada caso de uso debe corresponderse con las
facilidades asociadas. Debe tener en cuenta la definicin de cada facilidad
segn la ltima revisin realizada a estas. En caso de inconsistencias debe
mejorar la definicin general del caso de uso.
Los casos de uso definidos para cada ciclo debe corresponderse con la
justificacin de los casos de uso en cuanto al orden de riesgo
Los resultados obtenidos en esta fase son sometidos a gestin de configuracin y
por tanto sern cambiados de acuerdo al procedimiento de gestin de
configuracin establecido.
1.3.9.1 Obtencin del modelo del negocio

Casos de uso del modelo del negocio: Descritos en forma detallada
Diagramas de actividad
Diagramas de casos de uso
1.3.9.2 Definicin del alcance de la aplicacin
Identificacin de los involucrados: Para cada uno nombre, ubicacin y
tareas que realiza
Formular el problema a resolver: Descripcin de los problemas
fundamentales detectados en el analisis, Sistemas automatizados o
manuales existentes, ubicacin, descripcin de las caractersticas del
lugar donde se hace el sistema y del entorno donde esta ubicado el
sistema.
Listar las facilidades del sistema
1.3.9.3 Requisitos no funcionales
Se trata de un texto con los requisitos no funcionales numerados.
1.3.9.4 Casos de uso
Para cada caso de uso debe aparecer
Caso de Uso
(1)
Actores
(2)
Descripcin:
(3)
Referencias
(4)
Leyenda
(1) Indica el Nombre del caso de uso
(2) Lista de los actores que participan
(3) Descripcin en un prrafo del proceso
(4) Nmero de las facilidades asociadas al caso de uso
1.3.9.5 Anlisis de factibilidad
Debe justificarse indicando costo, personal involucrado, esfuerzo requerido y
los beneficios tangibles e intangibles
1.3.9.6 Cronograma general de la aplicacin
Una tabla indicando fases y fechas acorde con el esfuerzo requerido
2 Fases
Las fases de la metodologa tal y como fueron identificadas anteriormente son
Inicio, Elaboracin, Construccin y Transicin. Cada una de las ultimas tres fases
se realiza de forma iterativa e incremental por lo que a continuacin se detallan los
flujos o disciplinas que se efectan en cada iteracin o ciclo. En cada iteracin o
ciclo se puede realizar los siguientes flujos o disciplinas:
Requisitos
Anlisis
Diseo
Implementacin
Prueba
2.1 Flujo o disciplina de requisitos
Se incluyen nuevas facilidades y/o casos de uso de acuerdo a los criterios
recibidos de la prueba del ciclo o iteracin anterior. Se deben someter a gestin de
cambios puesto que las facilidades y casos de uso definidos en inicio fueron
sometidos a gestin de configuracin..
2.2 Flujo o disciplina de anlisis
En el flujo de anlisis orientado a objetos se examinan los requisitos desde la
perspectiva de las clases y los objetos encontrados en el dominio del problema.
Los pasos que se proponen son:
1. Obtencin de los casos de uso detallados
2. Definicin de las clases y de las asociaciones
3. Definicin del diagrama de clases del anlisis
4. Definicin de los diagramas de secuencia
5. Balance de los artefactos
2.2.1 Obtencin de los casos de uso detallados
La obtencin de los casos de uso detallados implica profundizar en el
conocimiento del problema a resolver. Para estructurar mejor los casos de uso se
recomienda dividirlos en partes que se llamaran subsistemas preliminares de
manera que sea mas fcil su entendimiento para ello se utilizan los paquetes.
Definicin de paquetes
La clasificacin de casos de uso por subsistemas preliminares da una agrupacin
de casos de uso en paquetes.
La definicin de los subsistemas preliminares se realiza en base a un anlisis de
la funcionalidad manejada en cada caso de uso. Se agrupan en un mismo
subsistema a aquellos casos de uso que se correspondan con funcionalidades que
manejen la misma informacin o informacin similar.
Un paquete en un mecanismo de propsito general para organizar elementos en
grupos. En los paquetes se agruparan en esta fase los casos de uso, pero en el
diseo se agruparan diagramas de clases y en la construccin componentes de
software etc.
Un paquete se identifica por el smbolo mostrado en la figura 2.
Figura 2 Smbolo del paquete

Confeccin de los diagramas de casos de uso
Un diagrama de casos de uso representa un conjunto de casos de uso para un
sistema, los actores y la relacin entre casos de uso y Actores es similar a un
Diagrama de Contexto del enfoque estructurado.
Los diagramas de casos de uso se deben realizar por paquetes de casos de uso,
es decir cada paquete implica uno o varios diagramas de caso de uso.
La simbologa que se utiliza se muestra en la figura 3 y en la figura 4 un ejemplo.
Actor
Caso de uso
Figura 3 Smbolos del diagrama de casos de uso
Figura 4 Ejemplo de diagrama de casos de uso

Casos de uso detallados
Para cada caso de uso del ciclo se debe detallar lo ms posible para ello debe
utilizar el formato siguiente:
Caso de Uso.
<Nombre del proceso asociado>
Actores <Nombre de los actores que intervienen en el proceso>
Resumen <Resumen, pude coincidir con la descripcin de la definicin
general>
Flujo principal
Accin del actor
1 <accin 1 de un actor>
Respuesta del sistema

3 <accin 3 del sistema>
Flujo alternativo
Accin del actor

Por supuesto el llegar a ese nivel de detalle implica profundizar con los usuarios y
clientes a travs de tcnicas de recopilacin de informacin, debe adems utilizar
el prototipo luego de realizar el refinamiento de ste de forma sucesiva a medida
que va realizando el detalle de los casos de uso.
A continuacin se muestra un ejemplo de caso de uso detallado para el ejemplo
de transplantes renales:
Caso de Uso
Transplantar un rin
Actores Forense, mdico interno, cirujano, paciente
Resumen
Un rin es analizado por el forense, el cual lo enva a ciruga donde el equipo de
cirujanos solicita a medicina interna que les enve los datos de los posibles
receptores. Admisin se encarga de localizar a los receptores. Los cirujanos
valoran los receptores posibles y operan el paciente seleccionado. Toda la
informacin producto del transplante es guardada en el expediente del paciente y
en el registro de transplantes
Flujo principal
Accin del actor
1 Comienza cuando un rin
producto de un accidente llega a
medicina legal y el forense determina
que puede ser empleado en un
transplante
3 El mdico interno solicita al sistema
los 10 pacientes receptores posibles
para el rin dado
5 En Admisin se recogen
pacientes posibles receptores
los
6 Se realiza un anlisis del estado de

cada posible receptor y se registra el
paciente a operar por el mdico
interno y se solicita transplantar
8 Al terminar el transplante el cirujano
introduce
los
resultados
del
transplante realizado y registra al
paciente como transplantado

2 El sistema registra el rin donado
y avisa al equipo de ciruga y al
mdico interno que se tiene un rin
disponible
4 Determina los pacientes posibles
receptores
y
muestra
sus
identificaciones,
prioridades,
ubicaciones en centro laboral y
vivienda. Genera un aviso a Admisin
para que recojan a los receptores
7 Al iniciarse el transplante se
muestra a los cirujanos el historial
clnico del paciente a operar
9 Al terminar
registran
los
transplante
el
transplante se
resultados
del
2.2.2 Definicin de las clases preliminares y de las asociaciones

Esta fase se divide en tres pasos:
Definicin de las clases preliminares
Definicin de las asociaciones
Definicin de los atributos de las clases
Los elementos incluidos en este epgrafe han sido tomados del proceso de RUP
[Kruchten, 1999] y de las recomendaciones incluidas en ADOOSI V5 [Alvarez,
2000]
Definicin de las clases preliminares
Hacer una lista de clases de acuerdo a las categoras entidad, frontera y control.
Clases Frontera: Sirven para modelar la interaccin entre el sistema y sus actores,
esto es, usuarios, sistemas externos y dispositivos.
Clase Entidad: Utilizada para modelar informacin de larga duracin y usualmente
persistentes.
Clases de Control: Representa el comportamiento especfico de uno o varios casos
de uso (si estn fuertemente relacionados). Los objetos de estas clases controlan a
otras clases o las coordinan
Esta clasificacin adems de ayudar a definir las clases permite obtener un modelo
robusto ya que los cambios solo afectan un rea limitada. Los cambios del contexto
externo a la aplicacin solo afectan a las clases Frontera. Los cambios en el flujo
de control a las de control y los cambios a la informacin de largo plazo a las clases
entidad.
Clases Frontera
Esta clase recibe y presenta informacin y peticiones de y hacia los usuarios,
dispositivos (sensor) y sistemas externos.
Representan a menudo ventanas, formularios, paneles, protocolos de
comunicaciones, interfaces de impresoras, sensores, terminales,
Como clase de anlisis es muy conceptual, solo basta con describir la informacin
y peticiones intercambiadas, sin interesar la forma fsica como se haga. No se debe
modelar partes de la interfaz como botones como clases separadas, solo la
ventana. La representacin grfica se representa en la figura 5.
Cl ie nteL inea
Pedido
(f ro m Ac to rs )
Figura 5 Representacin grafica de las clases frontera. Ejemplo clase Frontera

Pedido
Para detectar las clases fronteras se debe revisar:
Clases Frontera con usuarios: Una clase para cada par Caso de uso con
actor humano. Puede haber varias clases a la que la primaria le delegue
responsabilidades, por ejemplo en Windows una clase por cada Windows o
formulario. Utilizar clases solo para fenmenos del sistema o cosas

mencionadas en el flujo de eventos de los casos de uso
Clases de interfaz con sistemas: Una clase para cada actor que represente
a un Sistema. La responsabilidad de estas clases se deriva de la definicin
de la interfaz que ya existe. Un servicio Web debe considerarse como una
aplicacin externa.
Clases de interfaz con dispositivos: Una clase para cada Actor que
represente a un dispositivo. La responsabilidad de estas clases se deriva de
las responsabilidades del dispositivo. Pueden ser equipos con los que se
interacta, bien intercambiando informacin o controlndolos. Por ejemplo:
un radar en el sistema de control areo.
Clases Entidad
Usada para modelar informacin de larga duracin y usualmente persistentes.
Modela fenmenos o conceptos, es decir, objetos del mundo real o eventos. Los
valores de sus atributos y relaciones son actualizados por un actor con frecuencia.
La representacin grafica se muestra en la figura 6.
Cliente
Retiro
Cuenta
(f rom Actors)
Figura 6 Representacin grfica de la clase entidad Cuenta.

Para detectar las clases de entidad se debe revisar:
Una clase para cada trmino definido en el Glosario o definido en el modelo
del negocio (si fue realizado). Si la clase no es usada por ninguna otra clase
debe modelarse como atributo o relacin y no como una clase
Una clase para cada evento a recordar Un evento es un hecho del mundo
real a recordar por el sistema. En este caso debe tenerse informacin sobre:
quin, qu, cuando, donde, como, por qu. Por ejemplo: cambio de una
solicitud de reservacin o la rotura de un avin en el sistema de control de
reservaciones seran posibles clases.
Una clase para cada proceso a recordar. Un proceso debe ser recordado por
el sistema tambin as como las reglas del negocio utilizados en ste.
Ejemplo: El Proceso Reservacin de Asiento debe ser recordado as como
las reglas utilizadas para ello como la .Poltica de Cancelacin.
Una clase para cada rol o papel de persona. Puede generar clases -.
representando a usuarios que interactan con el sistema o clases
representando a personas que aunque no interactan con el sistema se
mantiene informacin sobre ellas. Ejemplo del primer caso tenemos a los
jefes de turno y de brigada que interactan sobre el sistema y en el
segundo al chofer que, aunque no interacta con el sistema de control de
transporte, se tiene informacin sobre este.
Una clase por cada lugar fsico a recordar. Se refiere a los lugares fsicos
sobre los que el sistema necesita conocimiento. Por ejemplo, en el Sistema
de Control de Transporte se requiere informacin sobre los centros tursticos
incluidos en las programaciones de los viajes (distancia en km, provincia,
etc.). El centro turstico es una clase posible.
Una clase por cada unidad organizativa a recordar. Se refiere a las
unidades organizativas con las que el sistema interacta y sobre las cuales
se requiere tener informacin. Por ejemplo en el sistema de control del
transporte se requiere informacin sobre las subbases de transporte
existentes en el pas, siendo sta una posible clase
Una clase por cada transaccin a recordar. Para las transacciones del
negocio se puede definir clases as como para los detalles de transacciones
que usualmente se tienen. Por ejemplo: Venta es una clase preliminar por
tratarse de una transaccin y DetalleProdVenta es el detalle de la
transaccin Venta, tanto Venta como DetalleProdVenta son ambas clases
preliminares.
Clases de Control
Representa el comportamiento especfico de uno o varios casos de uso (si estn
fuertemente relacionados). Los objetos de estas clases controlan a otras o las
coordinan. Estas clases coordinan la actividad de otros objetos que implementan la
funcionalidad que delegan.
No todos los casos de uso requieren clase controladora. Si el flujo de evento en un
caso de uso esta relacionado solamente con un objeto entidad, una clase Frontera
puede hacer el caso de uso en cooperacin con la clase entidad. Estas clases
desacoplan los objetos de la clase interfaz de los objetos entidad haciendo el
sistema tolerante a cambios del contexto. Por estas razones desacopla el
comportamiento del Caso de uso de los objetos entidad hacindolos mas
reutilizables. La representacin grafica se muestra en la figura 7.
Pedido
Confirmacion de pedido
Cliente en Linea
Gestor de Pedidos
(f rom Actors)
Solicitud de productos
Factura
Figura 7 Representacin grfica de la clase de control Gestor de Pedidos.

Para detectar las clases de control se debe tener en cuenta:
Una clase para el flujo principal del caso de uso, otra para cada flujo
alternativo y de excepcin. Ayuda a que el sistema sea fcil de mantener y
extender
No se necesita Clase de Control si el flujo puede ser manejado por la clase
interfaz y entidad
Un flujo de evento que entre informacin primaria, la recupera, la muestra o

modifica no justifica una clase de control
Dividir la clase controladora si dos actores compartan la misma clase de
control. La clase de control interacta a travs de la clase Frontera con los
actores
En la definicin de clases es til seguir las recomendaciones de Wirfs-Brock [Wirfs,
1990], que se presentan a continuacin:
Si se utiliza ms de una palabra para el mismo concepto, se selecciona una
que sea la ms importante en trminos del resto del sistema. Esto es parte
de la construccin de un vocabulario comn para el grupo de trabajo.
Ser cuidadoso con el uso de los adjetivos: pueden ser usados de muchas
formas y puede sugerir diferentes tipos de clases, un uso diferente de una
misma clase o pudiera ser irrelevante. Si el uso del adjetivo seala que el
comportamiento de la clase es diferente, entonces se hace una nueva
clase.
Modelar los valores de los atributos de las clases, no los atributos. Por
ejemplo, en la clase viaje existe un atributo que es tipo de viaje, cuyos
valores son excursin, recorrido y transfer, no se debe modelar clases para
tipo de viaje, que es el atributo, pero s para sus valores: excursin, recorrido
y transfer.
Definicin de las asociaciones
Una asociacin representa una relacin estructural entre objetos de diferentes
clases. Las asociaciones son inherentemente bidireccionales. El nombre de una
asociacin se establece a partir de una oracin que comienza con uno de los
objetos de la asociacin se concatena con una frase verbal y luego por el otro
objeto componente de la asociacin, tal y como se refleja a continuacin:
<Nombre objeto> Frase Verbal <Nombre objeto>
Deben registrarse las asociaciones en que el conocimiento de la relacin se debe
preservar durante algn tiempo. No debe incluirse asociaciones redundantes ni
derivables de otras.
Para encontrar las asociaciones se utilizarn las reglas dadas por Larman ,Larman,
1999]
A es una parte fsica de B
Por ejemplo: Ala es parte fsica de avin
A es una parte lgica de B
. Por ejemplo: LneaVenta es parte lgica de Venta
A est fsicamente contenido en B
Por ejemplo: Pasajero en Avin
A est lgicamente contenido en B
Por ejemplo: Vuelo est logicamente contenido en Descripcin de Vuelo
A es una descripcin de B
Por ejemplo: Descripcin de Vuelo es una descripcin de Vuelo
A es una lnea en una transaccin o reporte
Por ejemplo: LineaProducto es una lnea en la transaccin Venta
A se conoce/introduce/registra/ presenta/ captura en B
.Por ejemplo: Reservacin introduce en ListaPasajeros
A es miembro de B
Por ejemplo: Piloto es miembro del Avin
A es subunidad organizativa de B
Por ejemplo: Mantenimiento es una unidad organizativa de Linea Aerea
A usa o dirige B
Por ejemplo: Piloto usa el Avin
A se comunica con B
Por ejemplo: Cliente se comunica con el Vendedor
A se relaciona con una transaccin B
Por ejemplo: Pasajero se relaciona con el Boleto
A es una transaccin que se relaciona con otra transaccin B
Por ejemplo: Boleto y Venta son ambos transacciones
A est contiguo a B
Por ejemplo: Asiento y Asiento
A es propiedad de B
Por ejemplo: Avin es propiedad de Lnea Area
A es anloga a B
Por ejemplo: Avin es anlogo a Aeroplano
A es un tipo de B
Por ejemplo: Avin es un tipo de Vehculo
Definicin de los atributos de las clases
Los atributos deben corresponderse con los necesarios para representar los
objetos del mundo real y no con componentes de software. Por ejemplo la clase
Rin no debe incluir un atributo Formato de impresin, ya que este se
corresponde con una caracterstica del software y no con el concepto Rin del
mundo real.
Reglas para la definicin de los atributos [Larman, 1999]:
1. Debe utilizarse como atributo todas las propiedades que tengan valores simples
asociadas. Ejemplo para la clase Paciente son atributos que se corresponden
con propiedades simples Nombre, edad, sexo, etc.
2. No debe utilizarse atributos complejos. Si se necesita en la definicin de una
clase un objeto como atributo, esto es una indicacin de que se requiere definir
una asociacin. Ejemplo: Paciente requiere tener la informacin del Rin
Donado. No debe utilizar un atributo de tipo Rin Donado sino una asociacin
entre Paciente y Rin Donado.
3. No debe utilizar atributos que sean llaves forneas. Si se necesita en la
definicin de una clase una llave fornea como atributo, esto es una indicacin
de que se requiere definir una asociacin. Ejemplo: Paciente requiere tener el
Cdigo del Mdico que lo atiende. Se debe utilizar una asociacin entre Paciente
y Mdico para garantizar esta informacin.
4. No debe utilizarse atributos no primitivos. No obstante si el concepto
correspondiente al atributo no primitivo no tiene suficiente importancia como para
mantenerlo como una clase independiente, se mantiene como atributo de la
clase. Un atributo no primitivo puede ser un cdigo que tiene varias secciones
diferentes o se asocian a l operaciones como la validacin o posee atributos
asociados a l o tiene una unidad de medida. Ejemplo: Si en la clase Paciente el
atributo Direccin se trata como una cadena de texto y no se asocia con otras
clases de forma independiente y slo se requiere como descripcin de Paciente
se debe tomar como un atributo.
2.2.3 Definicin del diagrama de clases del anlisis
Esta vista del sistema muestra los conceptos bsicos de ste: sus partes y
relaciones. Para ello se utiliza el diagrama de clases de la notacin UML de forma
simplificada. El diagrama de clases es la representacin mediante un grafo de las
clases y las asociaciones que la conectan mediante un grafo. Se utilizan las clases
y asociaciones definidas antes, esto puede hacerse a la vez, definiendo las clases
y asociaciones y atributos sobre el propio diagrama. Lo anterior suministra una
vista esttica del sistema.
En el diagrama de clases del analisis se representan:
Las clases preliminares
Las asociaciones entre stas
La multiplicidad o cardinalidad para cada asociacin
Los nombres para las clases y las asociaciones
Representacin de las clases preliminares
Las clases preliminares se representan mediante rectngulos. Se especifica el
nombre de cada clase. La notacin se muestra en la figura 8. El tipo de clase:
entidad, de control o frontera se indica como estereotipo de la clase y en un CASE
(Computer Aided Software Engineering) puede ser representada mediante iconos
como se represent anteriormente.
<nombre de la clase >
<nombre de los atributos> >

<nombre de los servicios> >
Figura 8 Representacin de la clase

Se define como atributos las propiedades que caracterizan a los objetos de la
clase y como servicios las acciones que los objetos de una clase para satisfacer las
demandas o solicitudes de otros objetos.
Representacin de las asociaciones
Las asociaciones se representan mediante lneas que unen a los smbolos de las
clases involucradas. Las asociaciones son inherentemente bidireccionales, es
decir, la mayora de las veces interesa moverse en ambos sentidos. Por ejemplo
entre las clases rin donado y paciente se puede indicar una asociacin
bidireccional ya que dado un rin donado interesa saber cuales son los pacientes
que pueden receptarlo y dado un paciente interesa tambin saber cual es el rin
donado que le corresponde. En el diagrama de clases del anlisis se representan
todas las asociaciones como bidireccionales. Esta caracterstica ser refinada

posteriormente en el diagrama de clases del diseo. La asociacin se refleja
mediante una lnea continua que une a los smbolos de las clases involucradas. En
la figura 9 se muestra un ejemplo.
A
Figura 9 Asociacin entre las clases A y B.

Representacin de la cardinalidad o multiplicidad
La cardinalidad o multiplicidad se coloca en ambos extremos de la lnea que
representa a la asociacin. La multiplicidad define cuntos objetos de un tipo A
pueden ser asociados con un objeto de un tipo B, donde A y B son clases. La
multiplicidad se refleja en cada extremo de la asociacin por uno de los siguientes
rangos:
Multiplicidad
Muchos
Exactamente uno
Cero o muchos
Uno o muchos
Cero o uno
Rango
*
1
0..*
1..*
0..1
En la figura 10 se muestra la representacin de la multiplicidad en una asociacin.

A
0..1
0..*
Figura 10 Asociacin con multiplicidad especificada.

Un objeto de la clase B tiene asociado cero o un objeto de A y un objeto de la
clase A tiene asociado cero o muchos objetos de B
Representacin de los nombres para las clases y las asociaciones
Los nombres de las clases se colocan dentro del rectngulo correspondiente a la
clase y el nombre de la asociacin se escribe sobre la lnea que representa la
asociacin. El nombre de la clase es un sustantivo y puede tener adjetivos que lo
describan. En la figura 11 se muestra un ejemplo de diagrama de clases del
anlisis.
<<Interface>>
IClientes
<<Interface>>
ICatalogoCuentas
DevCuentas_SubCategoria()
Crear_Analisis_Subsistemas()
<<control>>
CClientes
Captar_DatosCliente()
Asociar_Cliente_Grupo()
Generar_Grupo()
Asociar_Cliente_Categoria()
Captar_Datos_Categoria()
Asociar_Cuentas_Cliente()
Seleccionar_Cuentas_Cliente()
Buscar_Cliente()
ModificarCliente()
Modificar_Categoria()
Buscar_Asociacion_Grupo()
Buscar_Cuentas_Grupo()
EGrupoCliente
IdGrupo : Single
Codigo : String
Descripcion : String
<<entity>>
EImpuestoCliente
CodImpuesto : String
Valor : Double
0..1
1
0..*
<<entity>>
EEmpresa
Nombre : String
Direccion : String
Email : String
Telefonos : String
Fax : String
Correo : String
Pais : String
CodigoPostal : String
Ciudad : String
Estado : String
SitioWeb : String
0..*
<<entity>>
EIncobrabilidadCliente
Antiguedad : Single
FechaTope : Date
<<entity>>
ECondPagoCobro
CodTipoPago : String
Dias : Single
Descuento : Byte
<<entity>>
ETipoPagoCobro
CodTipoPago : String
TipoPago : String
<<entity>>
ECategoriaCliente
0..*
<<entity>>
ERepresentante
Nombre : String
Apellidos : String
Cargo : String
1
<<entity>>
ACategoriaClienteProveedor
Codigo : String
IdTipoGrupo : Single
TipoGrupo : String
ECliente
1
Crear_Cliente()
Validar_Datos_Cliente()
Buscar_Cliente()
ModificarCliente()
factoryMethod()
AClienteProveedor
Codigo : String
Apellidos : String
Comentarios : String
Nombre : String
Direccion1 : String
Email : String
Telefonos : String
Fax : String
Correo : String
Pais : String
CodigoPostal : String
Ciudad : String
Id : Single
Estado : String
SitioWeb : String
Direccion2 : String
factoryMethod()
1..*
<<creates>>
1
AGrupoClienteProveedor
Codigo : String
Nombre : String
IdGrupo : Single
1
0..*
<<entity>>
EAnalisisCuentasGrupo
1..*
Crear_Analisis_Grupo()
Buscar_Cuentas_Grupo()
1
0..*
<<entity>>
EAnalisisCuentasCliente
<<entity>>
AAnalisis
Crear_Analisis_Cliente()
Buscar_Cuentas_ Cliente()
Figura 11 Diagrama de clases del anlisis. No aparecen los nombres de las

asociaciones y servicios. Aparecen asociaciones propias del diseo
2.2.4 Definicin de los diagramas de secuencia y asignacin de servicios o

responsabilidades
Los diagramas de interaccin constituyen uno de los artefactos mas importantes y
a su construccin se dedica gran parte del tiempo, la funcin fundamental de estos
artefactos es que permiten asignar las responsabilidades o servicios a cada clase.
El diagrama de secuencia permite describir cmo funcionar la aplicacin es decir
cul es su comportamiento, se refiere a qu har el sistema
Los diagramas de secuencia muestran como los objetos se comunican unos con
otros en secuencia de tiempo y para ello contienen objetos con sus ciclos de vida y
los mensajes que se envan entre ellos ordenados secuencialmente.
En el diagrama de secuencia se reflejan:
los actores (se obtienen de los casos de uso)
los eventos y las operaciones
los objetos de las clases
El evento es un hecho del mundo real (externo), producido por un actor al que un
sistema debe responder y la operacin es la accin que este realiza en respuesta a
un evento y que hace que el sistema en general cambie de estado y en particular
que varios objetos cambien su estado. Por ejemplo el evento puede ser que el
Cliente solicita Introducir sus datos y la operacin del sistema en respuesta es
Introducir Cliente.
En UML se define dos diagramas de interaccin:
Diagrama de Colaboracin
Diagrama de Secuencia
En la figura 12 se muestra el formato para el diagrama de secuencia y en la figura
13 el formato para el diagrama de colaboracin.
: <Actor Name>
: Clase 1
mensaje 1( )
: Clase 2
Objeto 3 : Clase
3
mensaje 2( )
mensaje 3( )
Enfatiza la
secuencia
Ciclo de vida
Foco
Figura 12 Diagrama de secuencia. Formato general

Los objetos se dibujan en rectngulos con los nombres subrayados y pueden
aparecer con uno de los formatos siguientes:
NombreObjeto o :NombreClase o NombreObjeto:NombreClase
El ciclo de vida de cada objeto se representa con lneas discontinuas que
descienden de los rectngulos representativos de cada objeto. Los mensajes
aparecen mediante lneas que enlazan la lnea de vida del objeto cliente con la
lnea de vida del objeto servidor. Los mensajes pueden numerarse indicando la
secuencia en tiempo opcionalmente. El orden de los mensajes se indica por la
posicin vertical comenzando por la parte superior hacia abajo.
En los diagramas se puede representar el foco de control, es decir el tiempo en que
el flujo de control est centrado en un objeto, es el tiempo en que el objeto est
enviando mensajes a otros objetos. A la izquierda del diagrama pueden agregarse
descripciones con los pasos a realizar en la interaccin correspondiente. El formato
general de los mensajes se muestra a continuacin:
VarRetorno:=mensaje(parmetro: TipoParmetro, ):TipoRetorno
1: mensaje 1( )
: Clase 1
: <Actor Name>
3: mensaje 3( )
2: mensaje 2( )
: Clase 2
Objeto 3 : Clase
3
Figura 13 Diagrama de colaboracin. Formato general

El formato del diagrama de colaboracin es idntico en cuanto al tratamiento de los
mensajes y de los nombres de los objetos. Se tiene enlaces de un objeto a otro con
los mensajes correspondientes, se pueden indicar en los enlaces saetas indicando
cliente y servidor del mensaje y no aparece la lnea de vida de cada objeto. La
secuencia slo se conoce a travs de la numeracin de los mensajes. El diagrama
de la figura 13 se obtuvo mediante la transformacin del diagrama de secuencia de
la figura 12.
Reglas para elaborar los diagramas de interaccin
Se identifican los actores que interactan directamente con el sistema. Se
puede observar que en los casos de uso aparecen actores que no interactan
directamente con el sistema como es el caso de Cliente en una terminal de
punto de venta.
Se identificar los eventos que estos actores generan.
Se nombran los eventos de manera que estn desprovistos del medio fsico de
entrada o de elementos de la interfaz, para ello debe utilizarse verbos en
infinitivo. Por ejemplo debe colocarse el evento TerminarVenta en lugar de
OprimirTeclaEnter ya que capta el propsito de la operacin y no se define en
funcin de la interfaz. El propsito debe reflejarse en el mayor nivel de
abstraccin posible.
Se confecciona un diagrama de interaccin por cada operacin del sistema, es
decir por cada solicitud de un actor que provoca una respuesta del sistema. En
RUP se recomienda utilizar un diagrama para el flujo principal y uno por cada
flujo alternativo pero al criterio del autor eso provoca diagramas poco claros.
Se utiliza indistintamente diagramas de secuencia o de colaboracin pero se
recomienda el diagrama de secuencia
Un diagrama se divide en varios diagramas si es muy grande
Se disea los diagramas de interaccin a partir de la descripcin de los casos
de uso.
Los diagramas de interaccin constituyen una herramienta fundamental para la
asignacin de las responsabilidades a cada clase. Existen patrones generales a
seguir en la asignacin de las responsabilidades a las clases, esos patrones se
conocen como patrn experto, patrn creador, patrn bajo acoplamiento, patrn
alta cohesin y patrn controlador [Larman, 1999]. Existen otros patrones que
sern aplicados en el diseo estos permiten definir una estrategia en la asignacin

de responsabilidades a las clases en el anlisis. A continuacin se describen estos
patrones o reglas generales:
1. Patrn experto: Asignar una responsabilidad al experto en informacin es decir
a la clase que cuenta con la informacin necesaria para cumplir con la
responsabilidad. Lo anterior garantiza mayor encapsulamiento. Una clase debe
tener acceso a todos los valores de datos que necesite para llevar a cabo sus
responsabilidades y slo a ellos. El acceso a los datos debe quedar tan
restringido como sea posible. Si una clase no necesita en absoluto el acceso a
cierta parte de la informacin para llevar a cabo sus tareas, no debe buscar ni
tener tal acceso.
2. Patrn creador: Asignar a la clase B la responsabilidad de crear una instancia
de A si:
B agrega los objetos A
B contiene los objetos A
B registra las instancias de los objetos A
B utiliza especficamente los objetos A
B tiene los datos de inicializacin que sern trasmitidos a A cuando sea creado
3. Patrn bajo acoplamiento: Asignar las responsabilidades de manera que se
mantenga bajo el acoplamiento.
Una clase que recurre a muchas No es buena porque los cambios de las otras
ocasionan cambios locales y en general son ms difciles de entender y de
reutilizar. Una clase que interacta con muchas se dice que tiene un excesivo
centralismo de control, esta situacin es negativa por las razones antes
apuntadas. Se recomienda, basado en los trabajos de Miller que: Una clase no
debe tener mas de 72 clases con las cuales interactuar. En los niveles
superiores de la jerarqua el lmite es usualmente entre 4 y 8, pues en los niveles
altos se supervisa el trabajo de otras clases y en los niveles bajos se delega la
realizacin de tareas especficas, lo que es ms simple. Se busca independencia
entre los mdulos
4. Patrn alta cohesin: Asignar las responsabilidades de manera que la cohesin
siga siendo alta para cada clase.
Una clase que hace muchas cosas no afines o muchas tareas no es buena
porque:
Son difciles de entender
Son difciles de reutilizar
Son difciles de conservar
Son delicadas las afectan constantemente los cambios
Una clase con buena cohesin es buena porque:
Mejoran la claridad y la facilidad de uso
Se simplifica el mantenimiento
A menudo se genera un bajo acoplamiento
Son mas fciles de reutilizar
5. Patrn controlador: Asignar una responsabilidad del manejo de un mensaje de
un evento del sistema a una clase que represente:
El sistema global (Controlador de Fachada)

La empresa u organizacin ()
Un manejador artificial de todos los eventos
Algo activo del mundo real y que pueda participar en una tarea (Controlador
de tareas)
Cada diagrama de interaccin debe iniciarse con una clase de este tipo que
recibe el evento correspondiente compatible.
Figura 14 Ejemplo de diagrama de interaccin para el caso del catalogo de

cuentas.
: FClientes
Inscribir_Categori...
Asociar_Cliente_Categoria( )
: C FC lientes
: IClientes
: CClientes
: ECategoriaCliente
Error_Datos_Categ...
Validar_Datos_Categori...
Crear_CategoriaClient...
Asociar_Cliente_Categoria(Clie...
Captar_Datos_Categori...
Inscribir_Categoria( )
Categoria_NoCr...
Asociar_Cliente_Categoria(Cliente)
Asociar_Cliente_Categoria(Clie...
Inscribir_Categori...
Validar_TipoDatos_Categori...
Asociar_ClienteACategori...
: FCategoriaCliente
El proceso de confeccin de los diagramas de interaccin y de asignacin de

responsabilidades a las clases debe realizarse de forma concurrente con el
refinamiento del diagrama de clases del anlisis. Si una clase requiere informacin
o accin de otra para completar su comportamiento debe existir una asociacin
entre ellas reflejada en el diagrama de clases del anlisis.
En el diagrama de la figura 14 se muestran los parmetros, esta es una informacin
que no siempre es til en estos diagramas pues los hace difcil de utilizar para la
comunicacin con los diseadores. Si se requiere generar con un CASE los
programas esta informacin ser indispensable e inclusive los tipos de los
parmetros.
2.2.3 Definicin de las operaciones de las clases
Las operaciones contribuyen a definir el comportamiento de un sistema; definen el
efecto que sobre el sistema tienen los eventos del mundo real. Se utilizar para
describir las operaciones a las precondiciones, poscondiciones, excepciones
definidas en UML.
El formato de los contratos es el siguiente:
Nombre: <Nombre de la operacin y los parmetros correspondientes>
Descripcion: <Descripcin informal de las responsabilidades que debe cumplir la
operacin >
Tipo: Nombre del tipo (Publico, Protegido y Privado)
Excepciones: Situaciones excepcionales
Precondiciones: Suposiciones acerca del estado del objeto de la clase antes de la
operacin
Poscondiciones: El estado del objeto de la clase despus de la operacin
A continuacin se describen las reglas para construir las operaciones:
Se identifican las operaciones a partir del diagrama de secuencia
Se elabora una descripcin para cada operacin
Se completa las precondiciones, se describe en forma declarativa los cambios
de las clases del diagrama de clases
Se completa las poscondiciones, se utiliza la ocurrencia de las siguientes
situaciones:
Creacin y eliminacin de objetos de las clases
Modificacin de los atributos de las clases
Asociaciones formadas y canceladas
Las poscondiciones constituyen, despus de la descripcin de la operacin, el
elemento ms y no se corresponden con acciones que deben efectuarse en la
operacin se trata de declaraciones sobre el estado del objeto una vez que se
realiz la operacin. Deben ser redactadas con los verbos en pasado. Las
poscondiciones se relacionan con el diagrama de clases y deben estar
balanceadas adecuadamente, no puede haber una asociacin o clase en las
poscondiciones que no aparezca en el diagrama de clases. Como producto de esta
fase el diagrama de clases puede ser refinado.
Las precondiciones son suposiciones sobre el estado de los objetos al iniciarse la
operacin, cosas que son importantes probar en el software en algn momento de
la ejecucin o que no sern sometidas a pruebas pero de las cuales depende el

xito de la operacin.
En la figura 14 se muestra la operacin Registrar cliente
Nombre: Registrar cliente
Descripcin: Registrar datos del cliente, tales como: nombre, direccin, telfono, e
mail, empresa y representante. Se asocia a un grupo cliente
Excepciones: Tiene que tener todos los datos
Precondiciones: Se aprob su registro por Comercial
Poscondiciones: Se creo cliente
Se asocio con Categora cliente Proveedor y se tomo la categora de cliente en no
moroso
Se cre el objeto Representante y la asociacin con este
Se creo la asociacin con Empresa
Figura 15 Ejemplo de documentacin de operacin
2.2.4 Balanceo de los artefactos
En esta fase se debe garantizar que todos los artefactos desarrollados estn
libres de inconsistencias. Los artefactos con que se cuenta son los casos de uso
detallados, la definicin de cuales se corresponden con el ciclo a desarrollar, los
diagramas de clases del analisis, la definicin de clases y de los atributos de las
clases, la definicin de las operaciones de las clases
Debe realizar las siguientes comprobaciones:
Los casos de uso detallados deben corresponderse, al menos, con los casos de
uso del ciclo realizado.
Las clases definidas deben corresponderse con las que aparecen en los
diagramas de clases del anlisis.
Los diagramas de secuencia del sistema deben corresponderse con eventos
iniciados por actores que interactan con el sistema en los casos de uso y todos
los actores que interactan con el sistema deben aparecer en algn diagrama
de secuencia
Las poscondiciones de las operaciones deben corresponderse con la creacin
o eliminacin de objetos de clases o asociaciones contenidas en los diagramas
de clases del anlisis.
Si existe alguna inconsistencia se deben realizar los arreglos necesarios
Se presenta la documentacin a modo de gua puesto que las herramientas CASE
garantizan a esta automticamente.
2.2.5.1
Paquetes de los casos de uso
Nombre del paquete
Descripcin del paquete
2.2.5.2 Casos de uso detallados

Para cada caso de uso se define:
Caso de Uso
Actores
Resumen: (3)
(1)
(2)
Accin del actor
(4)
(5)
Leyenda
(1) Indica el Nombre del caso de uso
(2) Lista de los actores que participan
(3) Resumen del caso de uso. Casi siempre coincide con la descripcin del caso de
uso no expandido
(4) Pasos numerado y secuenciales de las acciones del actor
(5) Pasos numerado y secuenciales de las acciones de respuesta del sistema al
actor. Existe una numeracin nica para actor y sistema.
2.2.5.3 Diagramas de casos de uso
Diagrama de caso de uso
Paquete
(1)
(2)
Leyenda:
(1) Deber ser colocado un nmero de acuerdo al formato siguiente:
DCU- ##
donde DCU significa Diagrama de Casos de Uso; y ##, es un nmero consecutivo
nico de identificacin para el paquete correspondiente al caso de uso.
(2) Deber ser colocada la representacin grfica del diagrama de casos de uso.
2.2.5.4 Diagrama de clases del anlisis
Puede tratarse de uno o varios diagramas
Diagrama de clases (1)
del anlisis
(2)
Leyenda
(1) Nombre del paquete o del caso de uso al que se asocia
(2) Diagrama correspondiente
2.2.5.5 Diccionario de datos
Clase: (1)
Significado: (2)
Nombre
del Descripcin
Tipo
Atributo
(3)
(4)
(5)
Leyenda
(1) incluido en el diagrama
(2) Significado del concepto o mediante una oracin simple o frase nominal
(3) Nombre del atributo asociada a la clase
(4) Significado del atributo
(5) Tipo de datos (caracteres, entero, real, alfabtico)
2.2.5.6
Diagramas de secuencia
Son varios diagramas
Diagrama de Secuencia del sistema
Paquete
(1)
(2)
Leyenda:
(1) Deber ser colocado un nmero de acuerdo al formato siguiente:
DSS- ##
donde DSS significa Diagrama de Secuencia del Sistema; y ##, es un nmero
consecutivo nico de identificacin para el paquete correspondiente.
(2) Deber ser colocada la representacin grfica del diagrama de Secuencia
2.2.5.7 Operaciones
Para cada operacin se describe:
Nombre:
Responsabilidades o mtodos:
Tipo:
Excepciones:
Precondiciones:
Postcondiciones
(1)
(2)
(3)
(4)
(5)
(6)
(1)<Nombre de la operacin y los parmetros correspondientes>

(2)<Descripcin informal de las responsabilidades que debe
cumplir la
operacin>
(3) <Nombre del tipo (los estndares)>
(4) <Casos excepcionales>
(5) <Suposiciones acerca del estado de la clase antes de la operacin>
(6) <El estado de la operacin despus de la operacin>
2.3
Flujo o disciplina de diseo
El diseo orientado a objetos es un mtodo de diseo que se basa en el concepto

de que el modelo del sistema es una coleccin de objetos que cooperan entre si
para garantizar los requisitos del usuario y donde cada objeto es una instancia de
una clase en una jerarqua de clases.
Las fases que se proponen son:
1. Definicin de la arquitectura
2. Obtencin de los diagramas de clases del diseo
3. Refinamiento de los diagramas de interaccin
4. Refinamiento de los atributos y responsabilidades de las clases
5. Aplicacin de patrones de diseo
6. Definicin de los diagramas de transicin de estado
7. Confeccin de los diagramas de componentes
8. Definicin de la base de datos relacional
9. Balanceo de los artefactos
10.Revisin y completamiento de la documentacin
Definicion de la arquitectura
La definicin de la Arquitectura es una actividad de diseo que se realiza de forma
iterativa e incremental. Esto se hace en los ciclos o iteraciones de la Etapa de
Elaboracin. Primeramente se comienza con la definicin del orden de realizacin
de los casos de uso de la aplicacin, esta es una decisin arquitectnica.
Usualmente en uno o dos ciclos de la Elaboracin se realizan los casos de uso que
determinan la arquitectura de la aplicacin y por tanto en el diseo de esos dos
ciclos se realiza la definicin de la arquitectura de la aplicacin. Esta actividad es
realizada por el Arquitecto de la Aplicacin de forma independiente de los Analistas
y otros diseadores.
Los pasos son:
Definicin del patrn de arquitectura
Definicin del modelo de mini arquitectura (framework) a emplear
Identificacin de los subsistemas
Definicin de servicios Web de terceros a emplear y servicios Web a ofertar
Definicin del Diagrama de subsistemas funcionales
Definicin de las clases y paquetes ms significativos
2.1.1.1 Definicin del patrn de arquitectura
La definicin del patrn de arquitectura requiere de un anlisis de las diferentes
variantes disponibles y de los requisitos no funcionales de la aplicacin. Las
variantes mas utilizadas son:
2.1.1
Cliente servidor: Se basa en un conjunto de nodos que realizan la funcin clientes y

de otros que realizan la funcin de servidores. Los clientes son consumidores de
servicios suministrados por un servidor. Un cliente frecuentemente sirve a un solo
usuario y maneja una interfaz GUI (Graphics User Interface) mientras que un
servidor normalmente brinda servicios a varios clientes siumultaneamente; los
servicios son de Base de Datos, Seguridad e impresin. La lgica del negocio esta
distribuido entre clientes y el servidor. Los clientes llaman a los servicios de los
servidores. Por lo general son subsistemas. Existe varias ocurrencias de un

programa cliente. Se debe resolver los problemas de concurrencia. La
representacin grfica se muestra en la figura 16
Cliente 1
Cliente 2
Cliente 3
Red de
comunicacion
Servido r de
catalogos
Servido r de
videos
Servi dor de
Fotografias
Hipertexto
Figura 16 Ejemplo de aplicacin cliente servidor. Varios servidores y clientes.

Aplicacin Web: Asociada a las aplicaciones Web hay varios patrones de
arquitectura que se presentan a continuacin. Para profundizar sobre el tema se
recomienda el texto de Jim Conallen [Conallen, 2003]
Cliente Web Delgado: Para aplicaciones basadas en internet. Poco control
de la configuracin del cliente. Toda la lgica en el servidor. Vista de diseo:
Mover todo el proceso del negocio al servidor. Los componentes son:
Browser Cliente, Web Server, HTTP, Pgina esttica y dinmica. En la figura
17 se muestra los elementos que la componen y sus relaciones y en la figura
18 la distribucin fsica de los nodos.
Crea da/modificada: Ru del Herna ndez

Date: Junio 2003
Aprobado: Sofia Alvarez
Date: Noviemb re 2003
Browser Cliente
Servidor de
Aplicacion
Servi dor Web
HTTP
Sistema de
ficheros
Capa Persistente
(BD)
Paginas
dinamicas
Paginas
Estaticas
Figura 17. Elementos de Cliente

delgado
Cliente
Red de
trabajo
Web
Server
Server
Appli...
BD
Server
preemptive
HTML Browser
<thread name>
Figura 18 Distribucin fisica de los nodos para Cliente Delgadoi

Cliente Web Grueso: Significativa cantidad de la lgica del negocio se
realiza en el cliente. Usa Applet o controles ActiveX para la lgica. En la
figura 19 se muestra los elementos que la componen y sus relaciones y en la
figura 20 la distribucin fsica de los nodos.
Script del cliente
Pagina Web
Java Applet
Brow ser Cl ie nte
DOM
HTTP
Invoca operacion()
Servidor de
Aplicacion
Servidor Web
Capa Persistente
(BD)
Figura 19 Elementos y relaciones en Cliente Grueso

Cliente
Red de
trabajo
Web
Server
Server
Appli...
BD
Server
preemptive
HTML Browser
<thread name>
Figura 20 Distribucin en nodos de Cliente Grueso

Web Distribuido (Web Delivery): Adems de HTTP usa otros protocolos
como IIOP y DCOM para los objetos distribuidos. Adicionalmente SOAP y
web services. Apropiada para cuando se puede suponer cierta configuracin
en el cliente y versin del navegador. Mejora la interfaz usuario para ejecutar
lgica del negocio en el cliente. En la figura 21 se muestra los elementos
que la componen y sus relaciones y en la figura 22 la distribucin fsica de
los nodos.
HTTP
Browser Cliente
Servidor Web
Servido r BD
Servidor de
Aplicacion
Paginas Web
Servidor de
objetos remotos
RMI/DCOM
Figura 21. Elementos y relaciones en Web Distribuido
Red de
tra b...
Web Server
Server Application
Cliente
BD
Server
p ree mp tive
HTML Browser most ran do objet os remot os
Servidor de Objetos
rem otos
RMI/DC
OM
Figura 22. Distribucin en nodos de Web Distribuido

2.1.1.2 Definicin del modelo de mini arquitectura (framework)
La realizacin de software en la actualidad se realiza sobre ambientes de
programacin que incluyen una mini arquitectura. Una mini arquitectura es un
esqueleto de los elementos fundamentales de la estructura de una aplicacin Una
mini arquitectura de software abarca un conjunto de clases que cooperan entre s
[Johnson, 1988]. El diseo de alto nivel del sistema, el cual define los
componentes de la solucin, sus interfaces y sus interacciones, es reutilizado
dentro de la mini arquitectura, y a medida que las clases o mtodos completos
pasen a formar parte de los aspectos fijos de ste, el cdigo y el diseo detallado
podrn ser tambin reutilizados [Jacobson, 1997]. Las mini arquitecturas facilitan
altos grados de reutilizacin. En el mercado existen diferentes mini arquitecturas
disponibles, entre ellas las que estn en la punta de la tecnologa son .NET y Java
2 Enterprise Edition (J2EE) [Booch, 2003]. Las razones de seleccin de una u otra
son ms polticas y comerciales que tcnicas. Cada mini arquitectura da la
posibilidad de implementar un conjunto de patrones de arquitectura.
Estas mini arquitecturas se apoyan en distribuir las componentes de la aplicacin
en capas, siendo usual la existencia de modelos de tres o ms capas en la
actualidad.
Las capas son agrupaciones lgicas de los componentes de software que
constituyen una aplicacin o negocio
1. Ayudan a diferenciar entre la clase de tareas desarrolladas por las
componentes
2. Hacen fcil el diseo de la reusabilidad
Cada capa contiene un nmero de componentes agrupados en subcapas y cada
subcapa realiza un tipo de tarea. Una distribucin por capas seria la propuesta en
la figura 23, la que se corresponde con la de .NET
Usuarios
Servicio
de
llamadas
Presentacin
Negocio
Datos
BD
Servicios
Figura 23 Distribucin por capas. Propuesta de .NET

En la figura 24 se muestra el detalle de los contenidos de las capas
Interfaz Usuario
Interfaz tradicional
Lgica del
negocio
Componentes del
negocio
Interfaz Web
Flujos de proceso del
negocio
Controlador de
interfaz
Acceso a los
datos
Logica de acceso a
los datos
Agentes de
servicios
Componentes de
entidades del negocio
Figura 24 Capas de la aplicacin en .NET

El significado de las capas se indica a continuacin.
1. Componente de la lgica. Orquesta las tareas del negocio a desarrollar
2. Componentes de las entidades del negocio. Contiene comportamiento que
implementa la lgica del negocio del servicio
3. Flujos de proceso del negocio. Se refiere a componentes que permiten el
uso de un motor de flujos de proceso
4. Componentes del acceso a los datos: Acceden a los servicios de los datos
almacenados
5. Agentes de servicio. Permite la bsqueda de los servicios Web
6. Interfaz de servicio. Se usa para exponer su funcionalidad
2.1.1.3 Identificar subsistemas
El concepto de subsistema es usado para distinguirlo de un paquete ordinario, los
que son contenedores de elementos del modelo, el subsistema es un paquete
especial que posee comportamiento de forma similar a las clases.
Las colaboraciones con un subsistema son aisladas a travs del uso de interfaces,
de forma tal que el cliente del subsistema solo dependa de la interfaz. El diseador
del subsistema esta totalmente aislado de dependencias externas, el diseador
solo es requerido para definir como la interfaz ser realizada. Los clientes del
subsistema ignoran el diseo interno, solo usan sus servicios. Por estas razones
crea una capa de encapsulamiento. La figura 28 muestra la representacin grfica
de los subsistemas.
<<subsystem>>
Clientes
Figura 28 Representacin de los subsistemas
2.1.1.4 Definicin de servicios Web

El trmino servicio es usado para indicar cualquier componente de Software
externo que brinde servicios. Incluye los Web Services XML pero no esta limitado a
ellos. Los servicios tienen interfaz y contratos. Puede ser tratado como un
subsistema especial.
Interfaz: A la cual los mensajes inboind son enviados. Fachada que
muestra la lgica del negocio implementada en el servicio a los clientes
potenciales
Contrato: Conjunto de mensajes que pueden ser intercambiados con un
servicio para desarrollar una tarea especifica del negocio
Desde la perspectiva del consumidor, los servicios son similares a los componentes
tradicionales, excepto que:
1. Los servicios encapsulan sus propios datos (Si la componente se deriva de
clases tambin se cumple)
2. No son estrictamente hablando parte de la aplicacin
Utilizan tcnicas basadas en mensajera para dar robustez y escalabilidad. Una
aplicacin esta compuesta de mltiples servicios, comunicndose a travs de
mensajes. Conceptualmente un servicio equivale a una componente, es decir, un
Servicio esta compuesto de mltiples componentes de software, similar a otra
aplicacin. Los servicios son diseados para comunicarse unos con otros con el
menor acoplamiento posible. Entre sus ventajas se tiene:
1. La comunicacin a travs de mensajes disminuye el acoplamiento, aumenta
la disponibilidad y escalabilidad
2. La seguridad puede implementarse mas simple
3. El servicio Web no posee interfaz usuario sino solo interfaz bajo control de
programa o programtica. Lo anterior facilita la reutilizacin de estas
componentes puesto que se pueden enlazar con otros componentes y
vincularlos a dismiles interfaces usuario. Por tanto, estas componentes
permiten una utilizacin muy flexible.
4. Esto ha habilitado tambin una forma de vender y reutilizar componentes en
Internet.
5. Usar servicios Web XML permite integrar con otras plataformas y
tecnologas
Sin embargo, el uso de estas componentes aumenta la lentitud de la aplicacin
resultante por lo que debe ser analizado en el caso de aplicaciones simples su
conveniencia de uso.
En base a los criterios antes mencionados se define si se utilizar algn servicio
Web de terceras partes o si se abordara el desarrollo de servicios Web como parte
de las componentes de la aplicacin.
2.1.1.5 Definicin del Diagrama de subsistemas funcionales
La definicin de subsistemas funcionales se define en el anlisis de forma general y
se refina en el diseo de la arquitectura de acuerdo a los siguientes criterios:
En el analisis se definen subsistemas funcionales que se corresponden con
la divisin de acuerdo a reas de responsabilidad o lugares.
En el diseo de la arquitectura se particiona a los subsistemas en

subsistemas o paquetes de acuerdo a criterios de la mini arquitectura
seleccionada o de reutilizacin o de divisin de capas
Los paquetes inferiores son paquetes de clases, el enfoque no es funcional
sino de objetos relacionados.
En la figura 25 se muestra un ejemplo de diagrama de subsistemas
<<subsystem>>
Facturacin y
cobro
<<subsystem>>
WS Producto
<<subsystem>>
Cuenta por
Cobrar
<<subsystem>>
WS Cliente
Figura 25 Ejemplo de particionamiento en Subsistemas. WS Cliente y WS Producto

son Servicios Web desarrollados por terceras partes.
La aplicacin de Venta del ejemplo ha sido desarrollada como un servicio Web
buscando la flexibilidad que esta tecnologa brinda por lo que Facturacin y cobro
es un Servicio Web. En la figura 26 se muestra el diagrama correspondiente
Facturacin y Cobro y su vinculacion con la interfaz.
<<subsystem>>
Facturacin y
cobro
Interfaz Web
Figura 26 Estructura de capas

2.1.1.6 Definicin de las clases y paquetes ms significativos
Es necesario definir por paquetes y/o subsistemas las clases y componentes mas
importantes y sus relaciones. En la figura 27 se muestra la estructura interna de
Facturacin y cobros
Clase Interfaz Web Sevice
Control del
negocio
Clases del
negocio
Typed Dataset
Acceso a los
datos
Agentes de
Servicios
Figura 27 Estructura interna de Facturacin y cobros. Objetos del tipo Typed

Dataset se utilizan para comunicar una capa con otra en .NET. La clase interfaz
Web representa la interfaz del servicio Web
2.3.2 Obtencin de los diagramas de clases del diseo
Los diagramas de clase se obtienen como resultado del refinamiento de los
diagramas de clases del anlisis, teniendo en cuenta la arquitectura y los requisitos
no funcionales, se confeccionan por subsistemas o paquetes. El resultado seria:
Clases definidas en el anlisis completas
Clases propias de la implementacin agregadas
El objetivo es lograr que el modelo del diseo se corresponda con el codigo a
desarrollar, tal y como se muestra en la figura 28.
Directo
Modelo del
diseo
Cdigo
Figura 28 Correspondencia del modelo del diseo con el cdigo

El proceso se realiza en los siguientes pasos:
Refinamiento de las clases

Refinamiento de las asociaciones e inclusin de dependencias
2.3.2.1 Refinamiento de las clases
El refinamiento de las clases incluye la inclusin de clases e interfaces
dependientes de aspectos fsicos. Entre estas estn:
Identificar las interfaces de los subsistemas. Un ejemplo se muestra en la
figura 29
o Definen un conjunto de operaciones las cuales son realizadas por
algn cliente
o Son importantes porque ellas permiten la separacin de la
declaracin del comportamiento (Interfaces) de la realizacin del
comportamiento (las especificas clases en el subsistema que realizan
el comportamiento)
Clases para garantizar la comunicacin entre las capas. Por ejemplo en el
caso de .NET se recomienda utilizar clases del tipo Typed Dataset para este
fin.
Clases intermediarias para garantizar la comunicacin con servicios Web
y/o aplicaciones externas.
Clases para definir la interfaz de los servicios Web internos a desarrollar
(como un servicio Web es una aplicacin independiente, cualquier solicitud
de informacin debe realizarse a travs de su interfaz haciendo uso de un
mtodo del servicio) y otras clases para garantizar la utilizacin de los
servicios Web en la aplicacin. Es necesario incluir siempre una clase
intermediaria para garantizar la independencia.
Clases intermediarias para los servicios Web con uso de Base de Datos.
Los servicios Web utilizarn una Base de Datos independiente o un
segmento de Base de Datos donde no hay relaciones entre las tablas del
servicio Web y el resto de la Base de Datos. Lo anterior genera un trabajo de
programacin mas complejo pues inclusive la integridad referencial entre
estas las tablas del servicio Web con el mundo externo tiene que ser logrado
a nivel de programa. Este problema provoca la creacin de clases
intermediarias para poseer la informacin requerida de otro WS para su uso
posterior.
Clases intermediarias para el acceso a la base de datos. Esto se
corresponde con las clases en una de las capas de la arquitectura
Clases activas que permiten representar hilos en el sistema. Puede haber
composicin entre ellas. En Sistemas de TR las cpsulas comparten
caractersticas de las clases activas y de los subsistemas y sustituyen a las
primeras. Buscar en los casos de uso cuales objetos interactan cuando un
evento ocurre y agrupar en autnomas conjuntos de colaboraciones de
objetos esto forma las clases activas compositivas. Si el evento tiene
atributos se modelan como clases con el estereotipo de activa
Interfaces permite capturar y examinar los empates del sistema definiendo
de forma precisa como las partes del sistema nter opera. Puede haber
composicin entre ellas.
Cuenta
<<subsystem>>
Caja
<<Interface>>
Fluj o
Figura 29 Ejemplo de interfaz

Tambin se deben transformar clases e incluir otras para garantizar la
implementacin de las aplicaciones Web. Se debe modelar las pginas, los enlaces
de unas con otras, todo el contenido dinmico asociado a la creacin y el
contenido dinmico de las pginas en el cliente.
Definir pginas en el cliente (indica la funcionalidad a realizar en el cliente
mediante el navegador correspondiente) y pgina en el servidor donde se
incluye toda la funcionalidad para la construccin de la pgina en el cliente.
Tambin se definen paginas Formularios para representar los formularios
normalmente incluidos en las paginas en el cliente. En la figura 30 se
muestra la representacin de estos tipos de pginas.
Incluir los tipos de asociaciones propias de las aplicaciones Web. En las
figuras 31, 32, 33 y 34 se muestran ejemplos. Las asociaciones poseen los
tipos que aparecen a continuacin:
o hipervnculos (link)
o construccin de pagina (built)
o envo de datos al servidor desde un formulario (submit)
o entre una pgina en el servidor y otra o con una cliente se enva un
comando al cliente para requerir otro recurso(redirect)
o para indicar que la pgina en el servidor incluye un objeto al construir
la pagina en el cliente (include)
o una asociacin de composicin entre una pgina en el cliente a una
clase lgica que representa un componente embebido, que puede ser
un ActiveX, un Applet u otro componente (Object).
Pgina en el cliente
Formulario
Pgina en el servidor
Figura 30 Representacin grafica de los iconos para representar paginas en el

cliente, servidor y formularios
<<link>>
homepage
<<Client Page>>
Busqueda
<<Client Page>>
Home
<<li nk>>
IdProducto
<<build>>
<<Client Page>>
DetalleProducto
<<Se rver Page>>

GetProducto
Figura 31 Utilizacin del Hipervnculo link y de Build
< < c lien t page>>
< < A pplet> >
C ronogramaA ula
C alendario
D ia : String
Aula : String
D ia : Integer
Mes : Integer
ao : Integer
cal
ActualizaActividad()
AdicionaEvento()
Elim inaEvento()
< < JavaS c ript> >

Valor()
H oy()
refres h()
EventoReunin
0..*
Tem a : Str in g
FechaInicio : D ate
FechaFin : D ate
H oraInicio : Tim e
H ora Fin : Ti m e
R es um en()
C onflictos ()
AdicionaPart()
Elim in aPart()
< < JavaS c ript> >
P artici pante
0..*
N om bre : String
Tittulo : String
Em ail : String
Telefono : String
R es um en()
< < Form > >
DetalleEvento
<<Text> > Tem a : String
<<s elect>> Participantes : String
<<Subm it>> Actual iza : Str in g
<<Subm it>> Elim ina : String
<<Subm it>> N uevo : String
<<C heckbox>> Todos D ias : Boolean
< < A c tiveX> >
Sele ccionF echa

Di a : Int eger
M es : In teger
Ao : Integer
Val or()
Hoy ()
Figura 32 Enlaces de pginas en el cliente

<<JavaScript>>
< < c lient page> >
CarritoEnLnea
Item
0..*
<<submi t> >
< < s erver page> >
ActualizaCarrito
< < Form >>
FormCarrito
Figura 33 Uso de Submit

<<Server Page>>
Checkout
<<redirect>>
(f rom Clases del dis eo)
Check out()
SubTotal()
Tax()
Envio()
Total()
<<Server Page>>
ProcesaError
(f rom Clases del dis eo)
{Paramtro=NoError,Descripcion}
Figura 34 Uso de Redirect
ValidarIU-W
ValidacionPaginaVer = "125"
Es-Valida-Pagina = true
Submit-Pagina = false
MiPagina.cs
Validar-ActDisplay()
Validar-Act Es Valida()
Validar -Control-ConexionId()
Validar-DameValor()
Validar-DameValorRecursivo()
<<Include>>
<<Build>>
MiPagina.ASPX
MiPagina.HTML
PorDefecto()
IniciaComponente()
IniciaPagina()
CargaPagina()
<<Submit>>
Principal
Campos Entrados
Valores-Definidos.NET
Figura 35 Implementacin de entradas en Web al estilo .NET

Otras clases deben ser completadas
Las clases de tipo entidad equivalen aproximadamente 1:1 a clases
persistentes
y deben ser agrupadas en paquetes para efectos
organizacionales y de control de configuracin. En caso de utilizarse
herramientas CASE para la generacin de la Base de Datos lo anterior
tambin es necesario.
Se deben completar los atributos de las clases con los tipos y valores por
defecto si los hubiera
2.3.2.2 Refinamiento de las asociaciones e inclusin de dependencias
Se incluyen las asociaciones presentes en el diagrama de clases del anlisis que
se correspondan con necesidades reflejadas en los diagramas de interaccin. Se
incluyen, adems, las asociaciones con las clases de diseo agregadas. Adems a
las asociaciones se le deben agregar otros detalles. Los detalles a incluir en las
asociaciones se corresponden con:
Los roles o papeles
La navegabilidad
Las dependencias
Las asociaciones agregacin
Las asociaciones de generalizacin-especializacin
2.3.2.2.1 Rol de una asociacin
El rol de una asociacin se corresponde con el papel o rol que realiza el objeto en
la asociacin. Por estas razones se puede reflejar el rol en ambos extremos de la
asociacin en caso de que tenga inters. Un ejemplo se representa en la figura 35.
Se observa que en la asociacin Mdico Opera a Paciente el mdico tiene el rol de

cirujano y el Paciente de Operado.
Mdico
Cirujano
Opera a
Operado
Paciente
Figura 35 Ejemplo de roles en una asociacin

2.3.2.2.2 La navegabilidad de las asociaciones
La navegabilidad es una propiedad del rol e indica la posibilidad de navegar
unidireccionalmente en una asociacin desde los objetos de la clase fuente hasta
los objetos de la clase destino. La existencia de navegabilidad implica la visibilidad
de los atributos de los objetos de la clase destino por los objetos de la clase fuente.
La implementacin usual en los lenguajes de programacin consiste en que la
clase fuente tenga un atributo que se refiera a un objeto de la clase destino.
Debe revisarse todas las asociaciones necesarias e incluir la visibilidad necesaria.
Si se deja una simple lnea entre ambas clases se est indicando navegabilidad en
ambos sentidos.
2.3.2.2.3 Las dependencias
La asociacin de dependencia entre elementos (casos de uso, paquetes, etc.) en
UML significa que un elemento conoce la existencia de otro. Para el caso de las
clases lo anterior quiere decir que le es visible, pero en este caso se toma la
visibilidad por declaracin global o local y la visibilidad por parmetro ya que la
visibilidad por atributo se representa mediante la navegabilidad.
La dependencia se representa con una saeta de lnea discontinua entre las clases
cliente y servidora. En la figura 36 se muestra un ejemplo de dependencia entre
clases. La clases CCReceptores depende de la clase PacienteComp pues recibe
como parmetro de salida un mensaje enviado a Paciente un objeto de la clase
PacienteComp.
CCReceptores
PacienteComp
Figura 36 Ejemplo de dependencia entre clases

2.3.2.2.4 Definicin de las agregaciones
Se Identifica las agregaciones con asociaciones entre clases que impliquen tiene
a. Este tipo de asociacin es similar a la agregacin del modelo entidad-relacin.
Esta asociacin se representa mediante un rombo. En la figura 37 se muestra un
ejemplo de asociacin de agregacin.
RionDonado
Transplante
Paciente
Figura 37 Ejemplo de agregacin

Existe un tipo especial de agregacin que se llama composicin y se caracteriza
por:
Es una forma fuerte de agregacin donde el tiempo de vida de la parte coincide
con la del todo.
La multiplicidad en el lado del agregado (todo) debe ser <= 1.
Las partes no deben sobrevivir fuera del todo
Operaciones de copia o eliminacin al todo deben propagarse a las partes
Lo anterior implica una forma de obtener un mayor nivel de encapsulamiento. La
representacin de la composicin se realiza mediante un rombo relleno. En la
figura 38 se presenta un ejemplo de composicin. El punto est contenido o en el
crculo o en el Polgono, no en ambos, el estilo si, por esas razones el Crculo y el
Polgono tienen asociaciones de composicin con el punto, lo que se representa
sombreando a los rombos correspondientes.
Punto
Poligono
Circulo
Estilo
Figura 38 Ejemplo de composicin

Descripcin de otras clases
Relacionado con la composicin se presenta una situacin especial que a
continuacin se detalla. Se utiliza una clase como Descripcin de otra clase cuando
un concepto o clase est incluido o contenido en otro para garantizar que la
informacin de la clase contenida no se pierda como consecuencia de la
funcionalidad de la clase que la contiene. Para el caso de la aplicacin de
transplantes renales se tiene que cada Paciente posee un Rin con determinadas
caractersticas. Cuando el Paciente es transplantado recibe otro Rin con otras
caractersticas. En ese momento el Paciente tendr otro Rin y las caractersticas

del Rin original se pierden pues Rin est contenido en Paciente. Si se
estuviera llevando un estudio sobre las caractersticas de los Riones de las
personas a las que se le realizan Transplantes sera necesario incluir otra clase
para ello, a esa clase que se incluye para describir o especificar a otra que est
contenida en una tercera y que puede desaparecer por necesidades de la clase
contenedora se le llama comnmente Descripcin de <Nombre de la Clase>. En la
figura 39 se muestra un ejemplo.
DescripcionRion
Rion
0..1
Figura 39 Ejemplo de utilizacin de las clases Descripciones de otras

2.3.2.2.5 Definicin de las asociaciones de generalizacin-especializacin
El objetivo es encontrar las clases abstractas y las superclases en general. Las
clases abstractas se detectan a partir de la asociacin de analoga.
Las clases anlogas deben heredar de una clase abstracta. Se define sta para
cada asociacin de analoga con las responsabilidades y atributos comunes y se
modifican las responsabilidades de las clases involucradas en la analoga. Este
proceso recibe el nombre de generalizacin. Pueden surgir superclases no
abstractas en este proceso.
Ejemplo:
Las clases Rin de Paciente, Rin Donado y Rin de Donante son clases
anlogas. Estas clases tienen en comn los atributos: Nmero del Rin y las
Caractersticas generales. Se crea una clase abstracta Rin con esos atributos y
las responsabilidades involucradas. Se redefinen las responsabilidades y atributos
de las clases Rin de Paciente, Rin Donado y Rin de Donante, que no
incluyen los atributos y responsabilidades que ahora aparecen en la clase abstracta
Rin.
Tambin deben revisarse las asociaciones de es un tipo de ya que si la clase
especializada no hereda todo el comportamiento de la generalizada debe incluirse
una clase abstracta con lo comn y de la cual hereden ambas. Tambin debe
determinarse las responsabilidades que son redefinidas por las subclases. Entre la
clase y la superclase o entre la subclase y la clase se define la asociacin de
generalizacin especializacin que se representa mediante una saeta con punta
gruesa y hueca tal y como aparece en la figura 40. En la figura 41 aparece un
ejemplo.
Eliminado: <sp><sp><sp>
<sp><sp><sp><sp>
Su nombre aparece en
letra cursiva
Clase Abstracta
Subclase 1
Subclase 2
Figura 40 Asociacin de generalizacin-especializacin
Rion
RionDonado
RionDonante
RionPaciente
Figura 41 Ejemplo de asociacin de generalizacin-especializacin

En el diagrama se puede representar la herencia simple o mltiple, siendo un
problema del desarrollo resolver los conflictos de la herencia mltiple que son:
1. Cuando se tiene el mismo nombre de atributo o responsabilidad en
superclases diferentes de las que se hereda directa o indirectamente.
2. Cuando una clase tiene un ancestro comn por dos o ms superclases.
La herencia mltiple es garantizada por C++ y Eiffel y en grado limitado o nulo en
otros lenguajes, siendo un tpico de debate an en el campo de la programacin
orientada a objetos. No obstante el uso de la herencia mltiple facilita la
reutilizacin del cdigo y brinda mayor potencia para la especificacin de las
clases. Sin embargo implica prdida de simplicidad conceptual en el diseo y
dificulta la implementacin.
En el diseo si est presente la herencia mltiple debe representarse dejando para
la etapa de Construccin la forma de resolver sus conflictos y de implementarla en
caso de que el lenguaje disponible no la posea.
En cada rectngulo representativo de una clase se coloca el nombre de la clase,
se incluye un diccionario donde se documenta para cada clase las
responsabilidades y atributos as como una breve explicacin de stas. Este
diccionario es completado y refinado a lo largo de todo el diseo y se describe en
la documentacin.
Debe definirse si las clases son persistentes o temporales. La persistencia es la
capacidad de almacenar un objeto y sus estados previos de manera que trascienda
al espacio y el tiempo. En ste punto hay que clasificar las clases en persistentes o
temporales en dependencia de si es de inters o no para la aplicacin que se
desarrolla, que sus objetos sean almacenados en un medio persistente. La
definicin de clases persistentes permite la obtencin de la base de datos. Si sta
es orientada a objetos no hay que hacer ninguna otra definicin. En caso de que la
base de datos no sea orientada a objetos en fases posteriores del diseo se
incluyen las clases necesarias para la interfaz con el sistema de gestin de base de
datos.
Debe definirse si las clases concurrentes (autnomas) o secuenciales. Deben
definirse las clases genricas (clases que permiten desarrollar los mtodos
teniendo como parmetros a objetos que se corresponden con una jerarqua de
clases de generalizacin-especializacin) as como los parmetros de stas.
Reglas para construir buenas asociaciones generalizacin-especializacin
Despus de construida las jerarqua de generalizacin-especializacin se analiza
de acuerdo a los siguientes criterios:
Modelar una jerarqua es un tipo de.
Asegurar que las clases abstractas no hereden de las reales.
Eliminar las clases abstractas que no agreguen funcionalidad.
Delimitar la herencia mltiple de la agregacin
Evitar generalizaciones anidadas profundas
Modelar una jerarqua es un tipo de
Debe asegurarse que la subclase soporte todas las responsabilidades definidas
para sus superclases. Asegurar esto es una forma de hacer las clases ms
reusables, porque es fcil ver donde una nueva clase debe ser colocada en la
jerarqua.
Cuando el comportamiento de la subclase incluye slo una parte de las
responsabilidades definidas por su superclase, se debe crear una clase abstracta
con todas las responsabilidades comunes a la clase y superclase de la cual
hereda.
Asegurar que las clases abstractas no hereden de las reales
Las clases abstractas se caracterizan por soportar sus responsabilidades
independientemente de su implementacin. Por esta razn no deben heredar de
las reales que dependen de la implementacin. Si una clase abstracta debe
heredar alguna responsabilidad de alguna concreta, se resuelve la contradiccin
creando una nueva clase abstracta de la que hereden las dos anteriores.
Eliminar las clases que no agregan funcionalidad
Las clases abstractas que no definan responsabilidad deben eliminarse.
Delimitar la herencia mltiple de la agregacin
La herencia mltiple puede confundirse con la asociacin de agregacin. Utilizar la
agregacin para representar la herencia mltiple es una mala decisin de diseo.
Una clase 1 hereda de una clase 2 si las instancias de la clase 1 pueden
considerarse tambin instancias de la clase 2. Una regla heurstica a usar sera: Si

una abstraccin es mayor que la suma de sus partes componentes se define una
clase agregada, en caso contrario se utiliza la herencia mltiple, [Booch, 1994].
Evtar generalizaciones anidadas profundas
Una jerarqua extensa en profundidad dificulta al analista a localizar la declaracin
de una clase pues est regada en toda la jerarqua de herencia, tambin se dificulta
la comprensin. Es difcil determinar los mtodos y atributos heredados y a cual
clase pertenecen. Lo anterior es ms crtico en la herencia mltiple donde el mismo
atributo y/o mtodo puede ser heredado de varias clases. En algunos lenguajes
como Smalltalk se fuerza a que todas las clases hereden de una clase base nica.
Lo anterior implica que clases totalmente diferentes sean relacionadas por la
herencia, lo que requiere gran esfuerzo y crea cuestionables jerarquas de
herencia.
No modelar los estados de una clase como subclases
Cuando en la funcionalidad est presente que los objetos de una clase tienen
varios estados posibles se debe crear una jerarqua de clases de estado y
asociarlas con el tipo original. Lo anterior se realiza de esta forma porque si se
crearan estados de la clase original reflejando el estado obligara a cambiar en
ejecucin un objeto de una clase a otra lo que sera poco operativo. En la figura 42
se refleja la solucin propuesta y la errnea para el caso de la clase Paciente y sus
estados de operado y no operado.
Paciente
PacienteNoOperado
PacienteOper
ado
Paciente
Solucin intil
Los objetos cambian
de subtipos en
ejecucin
Estado
*
EstadoNoOpe
rado
EstadoOper
ado
Solucin til
Figura 42 Clases que cambian de estado
2.3.3 Refinamiento de los diagramas de interaccin

Los diagramas de interaccin obtenidos en el analisis deben ser modificados para
considerar todas las clases aadidas en el diseo. Debe prestarse atencin
especial en cuanto a la comunicacin entre capas de acuerdo al patrn de
arquitectura utilizado. De las interacciones entre los objetos se obtienen nuevas
responsabilidades o mtodos para las clases.
2.3.4 Refinamiento de los atributos y responsabilidades de las clases
Esta fase se realiza en dos fases:
1. Refinamiento de los atributos
2. Refinamiento de las responsabilidades
2.3.4.1 Refinamiento de los atributos
El refinamiento de los atributos est fuertemente vinculado a las nuevas
responsabilidades incluidas a la clase, se analiza para cada nueva responsabilidad
la inclusin de nuevos atributos.
Para cada atributo se revisa si es posible calcularlo a partir de otros y en ese caso
de acuerdo a criterios de rapidez, y a la cantidad de usos se decide si debe quedar
como atributo o si debe ser calculado a partir de otros.
Tambin se revisa si los atributos contenidos en una clase se corresponden con el
significado dado a sta, la clase puede requerir atributos que no estn contenidos en
ella sino que obtenga de otras clases a travs de colaboraciones.
Se copia los atributos presentes en el modelo de clases del anlisis para las clases
que aparecen en ste, para las clases que aparecen por primera vez provenientes
de los diagramas de interaccin se realiza un anlisis similar al realizado al
construir el diagrama de clases del anlisis para incluir atributos.
2.3.4.2 Refinamiento de las responsabilidades
En el caso de las responsabilidades se deben incluir teniendo en cuenta
primeramente los mensajes que aparecen en los diagramas de interaccin. Se
debe agregar los mtodos que permiten tener acceso a los atributos de las clases
para conocer sus valores o para cambiarlos.
Para cada clase debe revisarse cada responsabilidad y hacerse las siguientes
preguntas:
Hay otro comportamiento con sentido que no fue incluido porque la aplicacin no lo
requera?
Tiene la responsabilidad una operacin inversa o complementaria?
Se incluye las responsabilidades necesarias para completar el comportamiento de la
clase.
Las responsabilidades obtenidas en los diagramas de interaccin se corresponden
con los servicios pblicos disponibles (mtodos no privados).
Por esta razn es necesario incluir las responsabilidades no vinculadas a los
servicios pblicos, para ello se analiza para cada clase las responsabilidades
siguientes:
-. Adicionar, cambiar, eliminar y seleccionar un objeto.

-. Calcular.
-. Sensar (Para sistemas en tiempo real).
Debe revisarse si las responsabilidades que aparecen en las clases abstractas han
sido completadas en las subclases y cuando esto se haga debe revisarse que no
sean convertidas en algo diferente, en sus manifestaciones visibles externas, de la
responsabilidad heredada.
Cada responsabilidad tiene asociada una especificacin. La especificacin de las
responsabilidades se realiza de forma idntica a la de las responsabilidades del
sistema, es decir mediante el contrato correspondiente. Debe definirse cules
responsabilidades son privadas.
Los mensajes como Buscar, Eliminar, etc. dirigidos a clases de tipo coleccin se
reflejan solamente en el diagrama de colaboracin de la forma en que aparece en
la figura 43. No se designa una nueva clase para la coleccin ya que estas estn
ya implementadas en todas las bibliotecas de clases de los lenguajes de
programacin disponibles, se designan con el nombre de la clase base,
correspondiente a los objetos que contiene.
Coleccin
A
Figura 43 Representacin de la coleccin en el diagrama de colaboracin

2.3.5 Aplicacin de patrones de diseo
La utilizacin de los patrones ha tomado un gran auge a partir del desarrollo del
modelo orientado a objetos. La frase de Grady Booch que a continuacin se
presenta demuestra lo anterior.
Una arquitectura orientada a objetos bien estructurada est llena de patrones. La
calidad de un sistema orientado a objetos se mide por la atencin que los
diseadores han prestado a las colaboraciones entre sus objetos.
Los patrones conducen a arquitecturas ms pequeas, ms simples y ms
comprensibles
Al realizar los diagramas de secuencia se recomend utilizar un conjunto de
patrones de carcter genrico. Ahora se indica la utilizacin de un conjunto de
patrones que garantizan la obtencin de un diseo ms flexible y reutilizable. Se
toman los patrones de La Pandilla de los Cuatro [Gamma] y patrones de Fowler
[Fowler, 2002]
Se recomienda el analisis de los patrones siguientes:
Patrn Polimorfismo
Patrn Fabrica Abstracta
Patrn Indireccin
Patrn Publicar-Suscribir u Observador
Patrn No hables con extraos
Patrn Mtodo Factora
Patrn Solitario
Patrn Adaptador
Patrn Composicin
Patrn Decorador
Patrn Fachada
Patrn Proxy
Patrn Comando
Patrn Mediador
Patrn Estado
Patrn Estrategia
Patrn Plantilla
Patrn Transaccin
Patrn Modelo del dominio
Patrn Record set
Patrn Gateway
Patrn Mapper
Patrn Mdulo Tabla
Patrn Objeto de Transferencia de Datos (DTO)
Patrn Assembler
2.3.5.1 Patrn Polimorfismo

Problema
Cmo manejar las alternativas basadas en el tipo?
Solucin
Cuando las alternativas o comportamientos relacionados varan segn el
tipo, asigne la responsabilidad para el comportamiento (mediante
operaciones polimrficas) a los tipos para los que vara el comportamiento.
El polimorfismo tiene varios sentidos. Dentro de este contexto significaasignar el
mismo nombre a responsabilidades en varios objetos, cuando las
responsabilidades se parecen o estn relacionados entre ellas. Los tipos de objetos
suelen estar relacionados en una jerarqua con una superclase comn, aunque ello
no sea estrictamente necesario (sobre todo en lenguajes con ligadura dinmica
como Smalltalk o como los que dan soporte a interfaces como Java)
El uso del patron Polimorfismo esta acorde con el espritu Lo hago yo mismo. El
pago se autoriza a si mismo, esto constituye la esencia de la orientacin a objetos
Polimorfismo es el mas importante patrn estratgico en la orientacin a objetos.
En el se basan las estrategias globales o los planes de ataque al disear. De esta
forma el sistema puede ser fcilmente extendido. Por ejemplo agregar el
PagoPorDebito afectara poco el diseo para el ejemplo de la figura 44
Pago
Monto
Crear()
Autorizar()
PagoEfectivo
PagoCheque
PagoTarjeta
Autorizar()
Autorizar()
Autorizar()
Figura 44 Ejemplo de utilizacin del patrn Polimorfismo. Autorizar es una

responsabilidad polimrfica.
2.3.5.2 Patrn Fbrica Abstracta
Problema
A quien asignar la responsabilidad si se esta desesperado y no se quiere
violar los patrones alta cohesin y bajo acoplamiento?
Solucin
Asignar un conjunto altamente cohesivo de responsabilidades a una clase
artificial (una fabricacin de la imaginacin)
La motivacin de este patrn esta en la vinculacin de una clase con la Base Datos
relacional. Deba salvarse y recuperarse el objeto a si mismo? Segn el patrn
Experto deba ser un mtodo del propio objeto que ser salvado. Sin embargo, la
clase a salvar se acopla a la interfaz de la Base de Datos relacional y aumenta el
acoplamiento. Guardar objetos en la Base de Datos relacional es una tarea
general que le da soporte a muchas clases. Estando en el objeto a salvar dara
pocas posibilidades de reutilizacin.
Venta
fecha
hora
EstaTerminada
TerminarVentra()
IntroducirProducto()
EfectuarPago()
AgenteAlmacenamie nto
Persi stente
guardar()
Figura 45 Ejemplo del patrn Fabrica Abstracta. La venta conserva alta cohesin y
bajo acoplamiento. La clase AgenteAlmacenamientoPersistente es un objeto
genrico y reutilizable
2.3.5.3
Problema
Patrn Indireccin
Cmo evitar un acoplamiento directo entre dos clases? De que modo se

desacoplan los objetos de manera de obtener bajo acoplamiento y se
conserva alto el potencial de reutilizacin?
Solucin
Asignar la responsabilidad a un intermediario que crea una indireccin
El ejemplo de Fabricacin Pura para desacoplar la Venta y los servicios de la Base
de Datos relacional introduciendo la clase AgenteAlmacenamientoPersistente es
tambin un ejemplo de Indireccin. Otro ejemplo se muestra en la figura 46. Una
Terminal de punto de venta necesita un modem para transmitir solicitudes de pago
con tarjeta de crdito. El sistema operativo tiene una funcin de bajo nivel para ello.
Una clase Servicio Autorizacin Crdito asume la responsabilidad de hablar con el
MODEM. Servicio Autorizacin Crdito invoca al sistema operativo y estar
acoplado a este.
Mod em
ServicioAutorizacionCredito
NroTarjeta
Marcar()
Recibir()
Enviar()
Tambien
llamada Proxy
porque
representa un
dispositivo
electromecanico
Figura 46 Ejemplo del patrn Indireccin

2.3.5.4 Patrn Publicar-Suscribir u Observador
Problema
Cmo mantener la consistencia entre objetos relacionados, sin establecer
un acoplamiento fuerte entre sus clases?
Ejemplo: Separacin Modelo-Vista
Solucin
Define una dependencia uno-a-muchos entre objetos, de modo que cuando
cambia el estado de un objeto, todos sus dependientes automticamente
son notificados y actualizados
Se tiene dos tipos de objetos: Sujeto y Observador. Un sujeto puede tener
cualquier nmero de observadores dependientes. Todos los observadores son
notificados si el Sujeto sufre cambios. Cada Observador solicitara al Sujeto
sincronizar su estado. El Sujeto es el Publicador de las notificaciones y enva las
notificaciones sin saber a quien. En la figura 47 se muestra la estructura de clases
para este patrn.
Subject
Observer
Attach()
Detach()
Notify()
update()
for all O in
Observers
{O->Update()
ConcreteOb server
Con creteSubj ect
GetState()
SeytState()
Return State
Subject
Update()
ObserverState()
ObserverState=Subject>GetrState
Figura 47 Estructura de las clases para el patrn Publicar-Suscribir u Observador.

2.3.5.5 Patrn No hables con extraos
Problema
A quien asignar las responsabilidades para evitar conocer la estructura de
los objetos indirectos?
Solucin
Se asigna la responsabilidad a un objeto directo del cliente para que
colabore con un objeto indirecto, de modo que el cliente no tiene que saber
del indirecto
Conocido como Ley de Demeter impone restricciones sobre los objetos a los cuales
se debe enviar mensajes dentro de un mtodo. Los objetos no extraos a los que
puede enviarse mensajes son:
La instancia actual (self)
Parmetros de mtodos
Atributos de la instancia actual
Elementos de colecciones de la instancia actual
Las figuras 48, 49 y 50 muestran la aplicacin de este patrn.
Ven ta
MetododePago()
TerminarVenta()
IntroducirProducto()
EfectuarPago()
Pago
fecha
hora
EstaTerminad a
TPDV
Captura
PagadoPor
MontoOfrecido
MontoOfrecido()
Term inarVenta()
Intro ducirProducto()
EfectuarPago()
opname()
pago()
Tota l()
Figura 48 Diagrama de clases ilustrativo del patrn No hables con extraos
: TPDV
: <Actor Name>
imp:=MetododePago
: Venta
: Pa go
pag:=Pago
imp:=MontoOfrecido
Pago es un
extrano para
TPDV
Viola el
patron
Figura 49 Diagrama de secuencia asociado al diagrama de clases de la figura 48 e

ilustrativo del patrn No hables con extraos
: <Actor Name>
Imp:=MontodePago
: TPDV
Imp:=MontodePago
: Venta
: Pago
Imp :=MontoOfrecido
Figura 50 Diagrama de secuencia solucionado la violacin del patrn No hables

con extraos
2.3.5.6 Patrn Mtodo Factora
Problema
Se conoce cundo crear un documento, no se conoce de qu tipo. Una
clase C cliente de una clase abstracta A necesita crear instancias de
subclases de la clase A que no conoce
Solucin
Define una interfaz para crear un objeto, pero permite a las subclases decidir
la clase a crear: creacin diferida a las subclases.
Tambin conocida como Constructor Virtual. Dos abstracciones claves son las
clases Aplicacin y Documento. Ambas clases son abstractas, y clientes, tienen a
subclases para realizar sus implementaciones especificas a la aplicacin. Como la
particular subclase Documento a crear es especifica de la aplicacin, la clase
Aplicacin no puede predecir la subclase de Documento a crear (la clase
Aplicacin solo conoce cuando un nuevo documento debe ser creado, no cual
clase de Documento crear). La figura 51 presenta la estructura de este patrn.
<<Abstract>>
Documento
Abrir()
Cerrar()
Salvar()
Revert()
<<Abstract>>
Aplicacion
CrearDocumento()
NuevoDocumento()
AbrirDocumento()
MiAplicacion
MiDocumento
CrearDocumento()
Documento d
d: crear
Documento
set doc.ad d(d);
d:Abrir
Metodo
Factoria
Return New
Mi Docum ento
Figura 51 Estructura del patrn Mtodo Factora

2.3.5.7 Patrn Solitario (Singleton)
Problema
Se permite una nica clase: se trata de un solitario singleton que se
encargue de asegurar que exista un solo punto de acceso. Se permite una
nica instancia de la clase que maneja las ventanas, o de un spooler de
impresoras o de un sistema de ficheros o de una factora.
Solucin
Asegurar que un mtodo de una clase que no sea miembro (En C++) y que
devuelva el solitario singleton. Soportar la visibilidad global o un solo punto
de acceso individual a una clase y no a alguna otra forma de visibilidad
Por ejemplo, cuando un PagoconTarjeta recibe un mensaje Autorizar, necesita
enviar un mensaje a la TPDV para determinar con cual servicio de autorizacin de
crdito se comunicara(Bank of Foo para Visa, Bank of Bar para MasterCard, etc.
Por que preguntarle a TPDV? Porque es un experto natural de los servicios de
Autorizacion.
Pero surge un problema de visibilidad: la instancia recin creada PagoconTarjeta

no tiene acceso a la instancia TPDV. Una solucin consiste en transmitirla hacia
abajo (como parmetro) desde TPDV (que posee la visibilidad de Atributo ante ella)
y asignarla a un atributo de PagoconTarjeta, para que tambin tenga visibilidad de
atributo frente a ella. Lo anterior es aceptable pero poco practico, otra opcin lo
constituye Solitario (Singleton). Un ejemplo se muestra en la figura 52.
Atributo de clas e de
singleton
TPDV
direcci on : String
$instancia : TPDV
Nombre : String
Metodo de clase de
singleton
$Instancia()
metodo de clase
TPDV TPDV--Instanci a()
{
if (Insta ncia==NIL )
Instancia=n ew TPDV
Re turn Instancia
}
Figura 52 Ejemplo del Patrn Solitario

2.3.5.8 Patrn Adaptador (Adapter/Wrapper)
Problema
Cmo lograr la colaboracin entre clases con interfaz incompatible?
Solucin
Convertir la interfaz de una clase en otra que el cliente espera. Permite la
colaboracin de ciertas clases a pesar de tener interfaces incompatibles
Un editor grafico de diagramas que usan lneas, polgonos, etc. Tiene como
abstraccin clave: Objeto grafico, tiene forma editable y se dibuja a si mismo. La
interfaz para el objeto grafico es definida por una clase abstracta ElementoGrafico
El Editor define subclases de ElementoGrafico para cada clase de objeto grafico:
lnea, polgono, etc. Las clases para implementar las formas geomtricas bsicas
son fciles. La subclase ElementoTexto que puede editar y mostrar texto es mas
difcil. La edicion de texto involucra gestin de buffer y actualizacin de la pantalla.
Se define ElemTexto tal que adapte la interfaz TextView a la de ElemGrafico. Se
tiene dos implementaciones:
(1) Heredando la interfaz de ElemGrafico e implementando la de TextView
(2) Por composicion de una instancia de TextView en ElemTexto e
implementando ElemTexto e terminos de una interfaz de TextView
Se le llama a ElemGrafico un adapter. La figura 53 muestra la estructura de dicho
patrn.
ElementoGrafico
Editor
marco()
crearManipulador()
return text.getExtension
ElemLinea
ElemTexto
marco()
crearManipulador()
marco()
crearManipulador()
return new ManipuladorTexto
+texto
TextView
getExtension()
Figura 53 Estructura del Patrn Adaptador

2.3.5.9 Patrn Composicin (Composite)
Problema
Cmo lograr que los clientes manejen a los objetos primitivos y compuesto
de forma uniforme?
Solucin
Componer objetos en estructuras jerrquicas para representar jerarquas
parte/todo. Un objeto de la jerarqua puede ser compuesto a su vez.
Se quiere que los clientes ignoren la diferencia entre objetos compuestos y los
objetos individuales que los forman. En la figura 54 se muestra un ejemplo.
<<abstract>>
Figura
dibujar()
add(Figura)
remove(Figura)
getHijo(int)
Linea
dibujar()
Rectangulo
FiguraCompuesta
dibujar()
dibujar()
add(Figura)
remove(Figura)
getHijo(int)
Figura 54 Ejemplo de aplicacin del patrn Composicin
2.3.5.10 Patrn Decorador (Decorator)

Problema
Cmo aadir atributos o comportamiento adicional a un objeto concreto no
a una clase? Algunas veces se deseador ejemplo agregar bordes o scrolling
a una ventana. La herencia no lo permite.
Solucin
Asignar dinmicamente nuevas responsabilidades a un objeto no a toda la
clase. Alternativa ms flexible a crear subclases para extender la
funcionalidad de una clase. Un enfoque flexible es encerrar la componente
en otro objeto que adiciona el borde. Ese objeto es el decorador
Se aade dinmicamente responsabilidades a objetos individuales de forma
transparente, sin afectar a otros objetos. Sin utilizar la herencia se evita una
explosin de clases que produce una jerarqua inmanejable. En la figura 55 se
muestra la estructura correspondiente.
Componente
operacion()
CompConcreto
Decorator
operacion()
DecoratorConcrA
estadoAdicional
operacion()
operacion()
+componente
componente.operacion
DecoratorConcrB
estadoAdicional
operacion()
comportAdicional()
super.operacion;
comportAdicional
Figura 55 Estructura del Patrn Decorador

2.3.5.11 Patrn Fachada (Facade)
Problema
Cmo proporcionar una nica interfaz a un conjunto de interfaces de un
subsistema? Algunas veces se desea por ejemplo agregar bordes o scrolling
a una ventana. La herencia no lo permite.
Solucin
Define una interfaz de ms alto nivel que facilita el uso de un subsistema.
De esta forma se logra reducir las dependencias entre subsistemas.
Por ejemplo, en un entorno de programacin que ofrece una librera de clases que
proporcionan acceso a su subsistema compilador: Scanner, Parser, ProgramNode,
ByteCodeStream y ProgramNodeBuilder. La Clase Compiler acta como fachada.
En la figura 56 se muestra la estructura correspondiente.
nica forma
Fachada
Figura 56 Estructura del Patrn Fachada

2.3.5.12 Patrn Proxy
Problema
Cmo diferir el costo de crear un objeto hasta que sea necesario usarlo:
creacin bajo demanda? Cmo ocultamos que una imagen se crear
cuando se necesite?
Solucin
Proporcionar un sustituto (surrogate) de un objeto para controlar el acceso a
dicho objeto
Se utiliza siempre que hay necesidad de referenciar a un objeto mediante una
referencia ms rica que una referencia normal. Introduce un nivel de indireccin.
Las situaciones comunes:
Proxy acceso remoto (acceso a un objeto en otro espacio de direcciones),
permite ocultar el hecho que objetos residen en diferentes espacios de
direcciones
Proxy virtual (crea objetos grandes sobre demanda), permite crear o copiar
un objeto bajo demanda
Proxy para proteccin (controlar acceso a un objeto), permite realizar
tareas de control sobre los objetos accedidos.
Referencia inteligente (smart reference), permite realizar tareas de control
sobre los objetos accedidos.
<<abstract>>
Sujeto
Cliente
(from flyweight)
operacion()
SujetoReal
operacion()
Proxy
+sujeto
sujeto.operacion()
operacion()
Figura 57 Estructura del Patrn Proxy

2.3.5.13 Patrn Comando (Command)
Problema
Cmo enviar mensaje a un objeto sin conocer el selector del mensaje o el
objeto receptor? Por ejemplo widgets (botones, mens,..) realizan una
accin como respuesta a la interaccin del usuario, pero no se puede
explicitar en su implementacin.
Solucin
Encapsula un mensaje como un objeto, permitiendo parametrizar los clientes
con diferentes solicitudes, aadir a una cola las solicitudes y soportar
funcionalidad deshacer/rehacer (undo/redo)
Permite parametrizar objetos por la accin a realizar (en lenguajes procedurales
con funciones Callback: funcin que es registrada en el sistema para ser llamada
ms tarde; en C++ se puede usar punteros a funciones). Especificar, aadir a una
cola y ejecutar mensajes en diferentes instantes: un objeto Command tiene un
tiempo de vida independiente de la solicitud original.
Permite desacoplar el objeto que invoca la operacin del objeto que sabe cmo
realizarla. Cada subclase CommandConcreto especifica un par receptor/accin,
almacenando el receptor como un atributo e implementando el mtodo ejecutar.
Aplicacion2
Menu
add(Document)
MenuItem +command
add(MenuItem)
Command
clicked()
ejecutar()
Cut
command.execute()
Paste
execute()
Document
execute()
+document
open()
close()
cut()
copy()
paste()
document.paste
Figura 58 Estructura para el patrn Comando

2.3.5.14 Patrn Mediador (Mediator)
Problema
Cmo realizar la reutilizacin y la especializacin del comportamiento
cuando muchas interconexiones entre objetos lo dificultan? Por ejemplo,
ventana que incluye un conjunto de elementos grficos con dependencias
entre ellos
Solucin
Se define un objeto que encapsula como interaccionan un conjunto de
objetos. Lo anterior favorece un bajo acoplamiento, liberando a los objetos
de referenciarse unos a otros explcitamente, y permite variar la interaccin
de manera independiente.
En las figuras 59 y 60 se muestra la estructura correspondiente.
DialogDirector
Widget
+director (from Logical View)
showDialog()
createWidgets()
widgetChanged(Widget)
FontDialogDirector
director.WidgetChanged(this)
changed()
+list
createWidgets()
widgetChanged(Widget)
ListBox
getSelection()
+field
Figura 59 Estructura del patrn Mediador (1)
EntryField
setText()
:Cliente
:FontDialogDirector
:ListBox
:EntryField
showDialog
widgetChanged
getSelection
setText
Figura 60 Estructura del patrn Mediador (2)

2.3.5.15 Patrn Estado (State)
Problema
Cmo simular cambiar en ejecucin a los objetos de clase? Por ejemplo,
una conexin TCP puede encontrarse en uno de varios estados, y
dependiendo del estado responder de un modo diferente a los mensajes de
otros objetos para solicitudes tales como abrir, cerrar o establecer conexin
Solucin
Permite a un objeto cambiar su comportamiento cuando cambia su estado.
El objeto parece cambiar de clase.
El comportamiento del objeto depende de su estado, y debe cambiarlo en tiempo
de ejecucin dependiendo de su estado. Esto provoca que las operaciones tengan
grandes estructuras CASE que dependen del estado del objeto, que es
representado por uno o ms constantes de tipo enumerado.
TCPConexion
TCPState
+state
open()
close()
acknowledge()
open()
close()
acknowledge()
TCPEstablished
open()
close()
acknowledge()
state.acknowledge()
TCPListen
open()
close()
acknowledge()
TCPClosed
open()
close()
acknowledge()
Figura 61 Estructura del Patrn Estado (1)

Context
+state
solicitud()
State
operacion()
StateConcr1
StateConcr2
operacion()
operacion()
state.operacion()
Figura 62 Estructura del Patrn Estado (2)

2.3.5.16 Patrn Estrategia (Strategy)
Problema
Cmo definir para una clase varios comportamientos sin utilizar
sentencias CASE en sus mtodos? Por ejemplo, existen muchos algoritmos
para justificacin de texto, debe implementarlo el cliente que lo necesita?
Solucin
Se define una familia de algoritmos, se encapsula cada uno, y se permite
intercambiarlos. Permite variar los algoritmos de forma independiente a los
clientes que los usan
Un problema seria: Cmo una estrategia concreta accede a los datos del
contexto?
Pasar datos como argumentos
Pasar el contexto como argumento
Estrategia almacena una referencia al contexto
Composicion
+algoJustif
recorrer()
formato()
Justificacion
justificar()
JustificacionSimple
JustificacionTeX
justificar()
justificar()
algoJustif.justificar
Figura 63 Estructura del Patrn Estrategia (1)

Contexto
Estrategia
+estrategia
InterfaceContexto()
algoritmoInterface()
EstrategiaA
EstrategiaB
Figura 64 Estructura del Patrn Estrategia (2)

2.3.5.17 Patrn Mtodo Plantilla (Template Method)
Problema
Cmo definir un algoritmo en una operacin permitiendo a las subclases
redefinir ciertos pasos. Por ejemplo, la Clase Aplicacin que maneja objetos
de la clase Documento y el mtodo OpenDocument de esta.
Solucin
Se define el esqueleto (esquema, patrn) de un algoritmo en una operacin,
difiriendo algunos pasos a las subclases sin cambiar la estructura del
algoritmo.
Este patrn es fundamental para escribir cdigo en un framework. Para se
implementan las partes fijas de un algoritmo y se dejan que las subclases
implementen el comportamiento que puede variar. Se utiliza tambin cuando el
comportamiento comn entre varias subclases debe ser factorizado y localizado en
una superclase comn.
En las figura 65 se muestra el mtodo OpenDocument de la clase Documento
hecho como una Plantilla.
void openDocument (String name) {

if (! canOpenDocument(nombre){return};
Document doc = openDocument();
if !(doc = null) {
docs. addDocument(doc);
aboutToOpenDocument (doc);
doc.open;
doc.read();
}
}
Figura 65 Mtodo OpenDocument de la clase Documento hecho como una Plantilla
2.3.5.18 Patrn Transaccin (script transaction)
Problema
Cmo realizar la lgica de la aplicacin?
Solucin
Esencialmente es un procedimiento que toma la entrada de la presentacin,
la procesa (validaciones y clculos), lo almacena en la Base de Datos, se
invoca cualquier operacin desde otro sistema y responde con mas datos a
la presentacin quizs haciendo mas clculos para ayudar a formatear y
organizar los datos entregados. Es el enfoque mas simple ya que se tiene un
procedimiento por cada accin que quiera el usuario. Por ejemplo, en un
sistema de ventas se tiene una para Checkout, adicionar al carro de compra,
mostrar el estado de la entrega, etc.
Las dificultades aparecen cuando la lgica del dominio incrementa ya que
frecuentemente se duplica el cdigo en varias transacciones que requieren las
mismas cosas. Se puede colocarse subrutinas comunes pero en general es difcil
ya que la aplicacin resultante puede ser un enredo de subrutinas. En las figura 66
se muestra un ejemplo del Patrn Transaccin.
: <Actor Name>
Un servicio de reconocimiento :
ServicioReconocimiento
Un Data Gateway :
Data GateWay
Un conjunto de resultados del

contrato : ResultadosContrato
Calcular Reconocimiento (ContratoID)

FindContrato(ContratoID : )
New( )
GetData( )
InsertReconocimientoIngreso( )
Figura 66 Ejemplo del Patrn Transaccin
2.3.5.19 Patrn Modelo del Dominio (Domain Model)

Problema
Cmo realizar la lgica de la aplicacin?
Solucin
Esencialmente el dominio esta organizado alrededor de clases, las
validaciones y clculos en el dominio se representan como mtodos de las
clases y cada clase tiene su comportamiento a travs de los mtodos
En las figura 67 se muestra un ejemplo del Patrn Modelo del Dominio.
: <Actor Name>
: Contrato
Calcular Reconocimi ento
: Producto
CalcularRecono(UnContrato)
: EstrategiaReconocimiento
CalcularRec(UnContrato)
:
Reco noci mientoIn greso
New
Figura 67 Ejemplo del Patrn Modelo del Dominio

2.3.5.20 Patrn Record Set
Problema
Cmo realizar la vinculacin con los datos de la Base de Datos?
Solucin
Es una representacin en memoria de datos tabulares. Por tanto es la
representacin en memoria del contenido de los query a la base de Datos
En las figura 68 se muestra un ejemplo del Patrn Record Set.
Fila
Record set
Tabla
Colum na
Figura 68 Ejemplo del Patrn Record Set

2.3.5.21 Patrn Gateway
Problema

Solucin
Un objeto que encapsula el acceso a un sistema externo o recurso. Puede
ser la Base de Datos u otro recurso o sistema externo.
En las figura 69 se muestra un ejemplo del Patrn Gateway.
Arrendamiento
Gateway
Tasa cion
Tasacion
Paquete
Activo
Figura 69 Ejemplo del Patrn Gateway. Arredamiento y Activo tienen acceso al

Paquete de Tasacin a travs de la clase GatewayTasacin.
2.3.5.22 Patrn Data Mapper
Problema
Solucin
Por cada clase que represente un objeto del negocio se crea un mapper
que se encarga de la interaccin con la Base de Datos.
En las figura 70 se muestra un ejemplo del Patrn Data Mapper.
Mapper Pers ona
Persona
Get exemptions()
Insert()
Actu ali za()
Figura 70 Ejemplo del Patrn Data Mapper.

2.3.5.23 Patrn Modulo Tabla (Table Module)
Problema
Solucin
El Patrn Mdulo Tabla es diseado para trabajar con Record Set ya que
para cada objeto del negocio representa la tabla correspondiente en lugar de
una instancia.
Se parece al Modelo del Dominio ya que ambos tienen clases Contrato, Producto y
reconocimiento de ingreso pero la diferencia es que mientras Modelo Dominio tiene
una instancia de Contrato para cada contrato en la Base de Datos un Modulo

Tabla tiene una instancia para manejar toda la tabla. El cliente de Modulo Tabla
Contrato har las solicitudes a la Base de Datos para formar el Record Set
entonces creara el objeto Contrato y pasara este al Record Set como argumento.
El cliente puede entonces invocar operaciones sobre el Contrato para hacer varias
cosas. Si se quiere hacer algo a un contrato individual se debe pasar su
identificador.
.
En las figura 71 se muestra un ejemplo del Patrn Modulo Tabla
: Contrato
: <Actor Name>
: Producto
: Reconoci miento de
ingreso
New(The Data Set)
CalcularReconocimiento(ContratoId) New(The DataSet)

New(The DataSet)
GetTi poProducto(ProductoID)
Insert
Figura 71 Ejemplo del Patrn Modulo Tabla.

2.3.5.24 Patrn Objeto de Transferencia de Datos (Data Transfer Object)
Problema
Cmo en una aplicacin distribuida se disminuye el tiempo de respuesta?
Solucin
Crear un Data Transfer Object (DTO) que contenga los datos requeridos de
la llamada remota. Una sola llamada remota.
En las figura 72 se muestra un ejemplo del Patrn DTO
UnCliente
:
CompradorDTO
: Comprador
DameCompradorDTO()
Create
: Contrato
: <Actor Name>
: Producto
: Reconoci miento de
ingreso
DameTitulo
New(The
Data Set)
DamePrimerApellido
CalcularReconocimiento(ContratoId) New(The DataSet)
DameSegApellido
New(The DataSet)
GetTi poProducto(ProductoID)
Insert
Figura 72 Ejemplo del Patrn DTO.

2.3.5.25 Patrn Assembler
Problema
Cmo en una aplicacin distribuida se disminuye el tiempo de respuesta?
Solucin
Un objeto que acta para llevar los datos para reducir las llamadas a los
mtodos
En las figura 73 se muestra un ejemplo del Patrn DTO y del Patrn Assembler
AlbumDTO
Titulo
Artista
AlbumAssemb
ler
ToXMLElemento()
LeeXML()
Album
Titulo
Artista
Nombre
Definicin de los diagramas de transicin de estado

Figura 73 Ejemplo del Patrn DTO y Assembler
2.3.6 Definicin de los diagramas de Transicin de Estado
Mediante los diagramas de transicin de estado (DTE) se identifica la secuencia de
actividades que un objeto de una clase puede generar [Coleman, 1992]. Son de gran
utilidad para el diseo de los sistemas en tiempo real. Se usa para mostrar el ciclo
de vida de los objetos de una clase, los eventos que causan una transicin de un
estado a otro y las acciones que resultan de un cambio de estado. Se agrupan en
paquetes al igual que los diagramas de clases y los diagramas de interaccin.
Se recomienda realizar los DTE para aquellas clases que posean atributos
dinmicos pues en funcin de estos es que estn los posibles estados por los que
transita un objeto. Para ello antes hay que clasificar los atributos de las clases,
teniendo en cuenta la forma y las causas por las que toman valor en el tiempo, en:
Atributo esttico: no cambia de valor en el tiempo por lo tanto no puede ser
actualizado. El nico evento que lo afecta es el que provoca la creacin de la
clase que como consecuencia le da valor.
Atributo dinmico: a diferencia de los atributos estticos, los dinmicos se
reconocen porque son afectados por otros eventos que son los que hacen que
cambie de valor.
Atributos derivados: cambian cuando cambian otros atributos. Estos otros
atributos integran la frmula de derivacin y pueden pertenecer o no a la clase a la
que pertenece el atributo derivado. Los SGBD, cuando cambia alguno de los
atributos que forman la frmula, deben automticamente disparar el reclculo del
valor derivado.
En un diagrama de transicin de estado se representan:
Los estados
Los eventos
Las transiciones
Las acciones
Estado: El estado de un objeto es una de las posibles situaciones en la cual un
objeto puede existir y representa una combinacin de todas las propiedades de un
objeto. Las actividades a desarrollar en el estado requieren de un tiempo de
realizacin y pueden tener asociadas restricciones de integridad, que son reglas
que especifican restricciones y requisitos que debe afectar tanto a la estructura
como al comportamiento de los objetos de una clase y deben ser tratados en
mtodos de la clase. Los estados se representan grficamente mediante un
rectngulo con las esquinas redondeadas. Un ejemplo se muestra en la figura 74.
Se incluye un estado inicial para indicar la creacin del objeto y que
automticamente pasa a otro estado, es obligatorio y se representa por un crculo
slido. El estado final indica el fin de vida de un objeto, es opcional, puede existir
mas de uno y se representa por un crculo slido circulado. El estado final se
corresponde con la destruccin del objeto de la clase. En la figura 75 se representa
la notacin. Una actividad es una operacin que toma tiempo completarla, se
asocia a los estados y comienza al entrar en un estado y puede ejecutarse hasta
concluirse o puede ser interrumpida por una transicin entrante. En la figura 76 se
muestra un ejemplo.
Clase: Consulta
AdicionarPaciente
Cancelar
ConsultaAbierta
ConsultaCancelada
Figura 74 Clase Consulta mdica
Estado
Figura 75 Ejemplo de estados inicio y fin
Eventos: Un evento es un hecho importante para la aplicacin. Los eventos pueden

ser consecuencia de una operacin que est dentro del dominio del anlisis
(internos), resultado de una operacin que es externa al dominio del anlisis
(externos) o como resultado de una operacin de reloj (temporal). Un Ejemplo sera
adicionar un paciente a una consulta.
Transicin: Una transicin es una relacin entre dos estados e indica que cuando
ocurre un evento el objeto pasa del estado anterior al siguiente. Las transiciones se
reflejan mediante flechas que llevan el nombre del evento correspondiente y tienen
asociadas acciones.
Acciones: Una accin es una operacin que se asocia con una transicin y tiene las
siguientes caractersticas:
Toma una insignificante cantidad de tiempo completarla
Se considera que no se puede interrumpir
Los nombres de las acciones se muestran en las transiciones precedidas por
una barra inclinada (/)
En la figura 76 se muestra un ejemplo.
AdicionarPaciente
Creacion
AbrirRegistro/NumPaciente a 0
Creada
Figura 76 Ejemplo de acciones. Abrir Registro e Inicializar
Las acciones pueden tener asociadas condiciones guardianes que pueden

provocar o disparar- la transicin. Una condicin guardin es una expresin lgica
de los valores de los atributos la que permite transiciones slo si la condicin es
true. En la figura 77 se muestra un ejemplo.
Para especificar una transicin se sigue el siguiente formato:
[<clase que genera evento>]:<evento>[[condicin guardiana]][/accin].
AdicionarPaciente
Cancelar
ConsultaCancelada
ConsultaAbierta
CerrarRegistro[ Numero>=20 ]
ConsultaCompleta
Figura 77 Ejemplo de condicin guardiana

Los diagramas de transicin de estado pueden volverse grandes y complejos y los
estados anidados pueden simplificarlos. Un superestado es un estado que incluye
estados anidados llamados subestados. En este caso las transiciones comunes de
los subestados son representadas al nivel de los superestados. Se permite
cualquier nivel de anidamiento. Los estados anidados facilitan modelar mayores y
ms complejos problemas.
El anidamiento es un tpico poco definido en cunto a cules criterios utilizar para
agrupar Cooling, recomienda los estudios de George Miller [Miller, 1956] que
indican la cantidad de 72 elementos por nivel y que lo general est en los niveles
ms altos y lo particular en los ms bajos. Un criterio para agrupar recomendado es
agrupar a los estados que estn fuertemente acoplados.
Los diferentes niveles de diagramas, que surgen por el uso de los estados
anidados, deben estar balanceados en cuanto a las transiciones de entrada y
salida cumplindose las siguientes reglas:
Para el caso de las transiciones de entrada es necesario que cada uno de los
eventos en OR, de la lista de eventos de cada una de las transiciones entrada
al estado anidado, est formando parte de la lista de eventos de al menos una
de las transiciones que parten del estado inicial.
Para el caso de las transiciones de salida debe cumplirse que: cada subestado
tendr una transicin al subestado final y cada transicin hacia el subestado
final, contendr entre su lista de eventos las listas de eventos de todas las
transiciones de salida del estado agregado relacionadas entre s por el operador

lgico OR.
2.3.7 Confeccin de los diagramas de componentes
Un componente realiza un conjunto de interfaces. Las clases representan
abstracciones lgicas y los componentes elementos fsicos (secuencias de bits).
Las clases tienen atributos y operaciones directamente accesibles, los
componentes slo tienen operaciones alcanzables a travs de sus interfaces. Se
representa mediante el smbolo que aparece en la figura 78.
Componente
Figura 78 Representacin de los componentes

Un componente se puede corresponder con:
Fichero ejecutable
Fichero de clase Java, C++, C#, etc.
Biblioteca esttica
Biblioteca dinmica
A los componentes se les pone en las interfaces funciones pblicas que pueden ser
llamadas por componentes externos. Las funciones de las interfaces se definen
mediante:
Nombre de la funcin
Parmetros
Tipos de datos (entrada o salida)
Tipo de valor del retorno de la funcin
Un diagrama de componente permite visualizar componentes, interfaces, y sus
dependencias. La representacin grafica se muestra en la figura 79.
Eliminado:
Componente 1
Interface
Dependencia
Componente 2
Figura 79 Smbolos para las Interfaces y las dependencias
Producto.dll
Producto
Cotizacion
Producto
Orden.dll
Orden
Direccion del
envio
Linea de Item
Figura 80 Ejemplo de diagrama de componentes

La relacin entre un componente y las clases que representa puede especificarse
mediante la realizacin.
2.3.8 Definicin de la base de datos relacional
El procedimiento para convertir las clases en tablas se indica a continuacin:
1 Se crea un paquete con las clases persistentes. Cada una de estas clases se
corresponde con una tabla y cada atributo con un campo en dicha tabla. La
multiplicidad de UML se corresponde con la cardinalidad en el modelo de datos.
2 La asociacin de agregacin se transforma en una relacin no identificada entre
las tablas apropiadas
3 La asociacin de composicin se transforma en una relacin identificada entre
las tablas apropiadas. En las figuras 80 y 81 se muestra la transformacin del
diagrama de clases al modelo de datos de las asociaciones de agregacin y
composicin.
4 En caso de la herencia se debe seguir uno de los patrones siguientes:
Definir una nica tabla con los atributos del padre y los atributos de cada
hija. Esto provoca que haya registros con campos cuyo valor no es de
inters en algunos casos y estarn vacos.
Definir una tabla para cada clase hija terminal que incluya los atributos de la
clase padre. Cuando la jerarqua es de ms de dos niveles, ocurre lo mismo
que en el caso anterior. La ventaja de sta forma est en la rapidez en la
recuperacin de informacin.
Definir una tabla para cada subclase y para cada clase generalizada. Para
recuperar la informacin de una clase hay que consultar la subclase y sus
ancestros. Cada subclase se convierte en una tabla y la clase padre en una
tabla con relaciones 1:n con cada subclase.
En las figuras 82 y 83 se aplica el patrn indicado en la tercera pleca.
5 No defina una tabla para una asociacin m a m, se puede realizar a travs de la
componente de acceso lgico a los datos. Ejemplo: Orden y detalle de ordenes
que encapsula la relacin m a m con producto [Fowler, 2002]
6 En el caso de una asociacin 1:m o m:1 se puede tomar dos variantes:
Convertir en una nueva tabla la asociacin. En este caso las ventajas serian
que est preparada para la evolucin del esquema en caso de que se
transforme la relacin a m:n, es mas fcil realizar las bsquedas y

actualizaciones de la relacin y se garantiza mejor el encapsulamiento ya
que la tabla solo conoce lo que requiere y no mas.
Puede ser aadida una llave extranjera a la tabla del extremo m, que se
corresponde con la llave de la tabla del extremo 1. En este caso la ventaja
es que se trabaja con menos tablas con lo que la ejecucin es mas rpida.
7 En el caso de una asociacin 1: 1 se puede convertir la asociacin en una
nueva tabla o se adiciona un nuevo campo a alguna de las tablas que es la llave
de la otra. Cada solucin tiene las mismas ventajas que en el caso de la
asociacin 1:m m:1.
8 Cada clase asociacin se transforma en una tabla interseccin con una columna
adicional que no es ni llave fornea ni primaria.
9 El rol del modelo de clases se corresponde con el rol en el modelo de datos
A pesar de que no es necesario crear nuevas clases que reflejen la relacin en casi
ningn caso, se recomienda hacerlo porque el esquema puede evolucionar y no
sera en este caso necesario, hacer cambios a la estructura de la Base de Datos.
No obstante, en caso de trabajar con alguna herramienta CASE para la generacin
de la base de Datos a partir del modelo de objetos se recomienda utilizar en
general los convenios propios de la herramienta.
Figura 80 Ejemplo de composicin y agregacin en el diagrama de clases
Figura 81 Representacin en el diagrama de objetos de la agregacin y

composicin del diagrama de clases de la figura 80
Figura 82 Ejemplo de diagrama de clases con Herencias
Figura 83 Representacin de las herencias del diagrama de clases de la figura en

el modelo de objetos
2.3.9 Balanceo de los artefactos
Se debe revisar:
Que exista un diagrama de interaccin por cada operacin del sistema
Que exista un diagrama de clases por cada paquete o subsistema que no le
corresponda un diagrama de paquetes o subsistemas
Por cada mensaje que aparezca en los diagramas de interaccin debe existir
una responsabilidad asociada a la clase del objeto servidor
Si en el diagrama de clases existe un enlace entre dos objetos, en el diagrama
de clases donde aparezcan las clases correspondientes debe existir una
asociacin con la navegabilidad apropiada y viceversa.
Para cada clase con atributos dinmicos debe existir un diagrama de estado
Debe existir un paquete para las clases persistentes
Debe existir al menos un diagrama de componentes por cada diagrama de
clases
2.3.10.1 Diagramas de capas.
Se presenta para el caso de tres capas y puede extenderse para el resto de los
casos
Diagrama de tres Capas
Presentacin
Lgica de la aplicacin
Almacenamiento
(1)
(2)
(3)
(1) Paquetes de la presentacin

(2) Paquetes de la lgica de la aplicacin
(3) Paquetes de almacenamiento
2.3.10.2 Diagramas de paquetes
Para cada diagrama se tiene:
Diagrama
de (1)
paquete
(2)
(1) Nombre del paquete
(2) Diagrama del paquete
Para cada paquete que no se describa con un diagrama de paquete se presentan
el diagrama de clases, los diagramas de interaccin involucrados y los diagramas
de transicin de estado
Diagramas de clases.
Diagrama de Clases (1)
(2)
Leyenda
(1) Identificacin mediante los casos de uso involucrados
Diagramas de interaccin (secuencia y colaboracin).
Diagrama
de (1)
secuencia
(2)
Leyenda
(1) Identificacin mediante nombre
Diagramas de transicin de estado
Diagrama
de (1)
transicin de estado
(2)
Leyenda
(1) Identificacin mediante el nombre de la clase
2.3.10.3 Definicin de las clases
Nombre: (1)
Atributo
(2)
(2)
Para cada responsabilidad:
Nombre:
Descripcin:
Tipo:
Referencias cruzadas:
Notas
Excepciones:
Precondiciones:
Postcondiciones
Tipo
(3)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(1) <Nombre de la clase>

(2) <Nombre de un atributo>
(3) <Tipo de un atributo>
(4) <Nombre de la operacin y los parmetros correspondientes>
(5) <Descripcin informal de las operaciones que debe
cumplir la
responsabilidad>
(6) <Nombre del tipo (Clase de software, Sistema, clase interfaz)>
(7) <Nmero de referencia de los requisitos funcionales o casos de uso, etc.>
(8) <Informacin relacionada si existe, por ejemplo un algoritmo seleccionado>
(9) <Casos excepcionales>
(10) <Suposiciones acerca del estado del sistema antes de la operacin>
(11) <El estado del sistema despus de la operacin>
2.3.10.4 Base de datos relacional
Debe presentarse el diagrama de objetos correspondiente con la informacin
mnima para cada tabla que se muestra a continuacin:
Tabla
Nombre: (1)
Campo
Tipo
(2)
(3)
Leyenda:
(1) Nombre: de la Tabla
(2) Nombre del campo
(3) Tipo (entero, real, cadena, etc.)
2.4
Flujo o disciplina de Implementacin
La disciplina o flujo de Implementacin realiza la programacin y prueba de todas las

partes del sistema de forma ascendente.
El objetivo de esta fase es implementar e integrar las clases, objetos y cualquier
mdulo auxiliar en el subsistema y desarrollar las pruebas de integracin sobre el
subsistema. Los elementos referentes a las pruebas han sido tomados de Pressman
[Pressman, 2000].
El mtodo de programacin seguido es incremental y la estrategia adoptada es la
ascendente porque coincide con la estrategia de programacin seguida en el
enfoque orientado a objetos.
Se realiza en los siguientes pasos:
Programacin y prueba de cada clase del paquete o subsistema
Integracin de cada paquete o subsistema
Integracin del software y prueba de la integracin de ste
2.4.1 Programacin y prueba de cada clase del subsistema
Se comienza la programacin, compilacin y prueba de cada clase de los
subsistemas o paquete de ms bajo nivel (en caso de utilizar un lenguaje hbrido se
programan y prueban los otros mdulos necesarios).
Las pruebas de cada clase incluyen la prueba de los mtodos as como la
verificacin de las excepciones especificadas para la clase. Aqu deben utilizarse
pruebas de caja negra y de caja blanca. Las pruebas de caja blanca permiten probar
los caminos lgicos ms importantes (probar cada mtodo para las situaciones ms
comunes) y las pruebas de la caja negra se basan en probar que la clase realiza las
responsabilidades para las que fue diseada. Por tanto habra que revisar que las
responsabilidades definidas en diseo se corresponden con los mtodos
programados.
2.4.2 Integracin de cada subsistema
La integracin se realiza de forma ascendente, comenzando por los subsistemas de
ms bajo nivel.
La prueba de la clase coordinadora del subsistema garantiza la prueba del
subsistema, no obstante si el subsistema tiene clases visibles a otros subsistemas
deben probarse estas interacciones tambin para lo cual puede confeccionar un
programa de control de prueba para ese fin.
2.4.3 Integracin del software y prueba de la integracin de ste
Se deben ir integrando los subsistemas uno a uno comenzando por los de mas bajo
nivel (integran slo clases) y desarrollando las pruebas de integracin.
Debe desarrollarse los manuales de usuario, de operacin y de instalacin del
sistema. Para ello se detalla a continuacin el contenido de cada manual, de
acuerdo a lo establecido la norma ISO adaptacin cubana 19112 [Norma 19112].
2.4.4.1 Manual del usuario

El manual del usuario contiene los siguientes aspectos.
1. Introduccin
2. Generalidades
3. Instalacin
4. Iniciacin
5. Utilizacin
6. Entrenamiento
7. Apndices
I. Introduccin.
Aspectos que introducen al usuario tales como:
a. Identificacin del software expresando su nombre comercial y el problema
que resuelve.
b. Panormica de los elementos componentes (subsistemas y clases)
describiendo de forma general las caractersticas bsicas de cada uno de
ellos, as como exponiendo a grandes rasgos la informacin que es necesario
suministrar al software y los resultados que sern obtenidos.
c. Ventajas y limitaciones de la versin del software.
d. Organizacin y estructura del documento y breve descripcin del contenido
del manual.
e. Forma de usar el manual.
II. Generalidades.
Informacin general al usuario tales como:
a. Informacin sobre el producto del software, indicando quien diseo,
desarroll y document el software.
b. Forma de cmo contactar con el productor, brindando adems la
informacin que el usuario debe tener en caso de detectar errores en el
software
Versin del producto.
Nmero de serie.
Lugar de produccin y modelo de la computadora.
Tipo de monitor, tipo de tarjeta grfica.
Versin del sistema operativo.
Relacin de los programas cargados en la memoria operativa.
Descripcin de la imagen visualizada en el monitor en el momento en
que se produjo el problema.
Este inciso procede slo cuando el usuario y el operador son la misma
persona.
c.
Informacin sobre las organizaciones y personas responsables de la

operacin del software.
d.
Informacin sobre las organizaciones y personas responsables del

mantenimiento del software.
e.
Deberes y derechos (tanto del usuario como del productor del software)
que deben estar sujetos a acuerdos entre las partes contractuales, los
cuales pueden estar influenciados por la legislacin y por las normas
nacionales e internacionales vigentes.
f.
Proteccin contra copia, brindando informacin sobre si el software tiene o

no un esquema de roteccin contra copia, sealando si est permitido o
no realizar copias del software.
g.
Registro del usuario, brindando informacin sobre la necesidad y

conveniencia de que el comprador del software se inscriba como usuario
de ste.
h.
Informacin sobre la facilidad de obtener ayuda o asesora tcnica.
i.
Informacin sobre la garanta.
III. Instalacin.
Este epgrafe procede en caso de que usuario y operador coincidan. Verse al
manual de instalacin.
IV. Iniciacin.
Consta de la siguiente informacin:
a. Comienzo. Pasos iniciales para dar inicio a la utilizacin del software,
por ejemplo el procesamiento de la informacin antes del tratamiennto
automatizado, el procedimiento de carga, etc.
b. Modo de ayuda, descripcin de como se puede obtener ayuda
referente a la utilizacin del software.
c. Documentacin de referencia. Recomendacin en caso necesario de la
consulta de cualquier material impreso que posibilite completar los
conocimientos de los mtodos, algoritmos, etc. utilizados en el
software.
V. Utilizacin.
Slo procede en caso de usuario y operador coincidan.
operacin.
VI. Entrenamiento.
Verse el manual de
Debe incluirse lecciones de aprendizaje, preferiblemente de forma automatizada.

VII. Apndices.
Informacin adicional que se requiere suministrar al usuario. Esta puede ser:
a. Glosario de trminos.
b. Relacin de los mensajes de error.
c. Relacin de todas las abreviaturas.
2.4.4.2 Manual de instalacin
El documento contiene los siguientes aspectos:
Condiciones para la instalacin.
Instalacin.
Desinstalacin.
I. Condiciones para la instalacin.
Informacin sobre lo primero que se debe hacer antes de proceder a la instalacin
del software, tales como:
a. Relacin de los elementos del software que componen la configuracin del
paquete del sofftware.
b. Requisitos del ambiente de operacin necesario para instalar el software
c. Procedimiento para poder leer el contenido del fichero LEEME.DOC, el cual
contendr cualquier informacin adicional para la instalacin o uso del
software.
II. Instalacin.
Procedimiento para instalar el software en la computadora.
III. Desinstalacin.
Procedimiento para eliminar el sofftware de la computadora del usuario.
2.4.4.3 Manual de operacin
El manual de operacin contiene los siguientes aspectos:
Utilizacin de perifricos
Procedimiento para la operacin del software.
Tratamiento de los errores.
Recuperacin de los fallos.
I. Utilizacin de perifricos.
Descripcin de la forma de utilizacin de los diferentes dispositivos perifricos as
como de los elementos finales de control y de adquisicin de datos.
II. Procedimiento para la operacin del software.
Instrucciones precisas sobre como usar las opciones o comandos que brinda el
software.
Para el caso de los comandos debe incluirse:
a. Propsito, orden, sintaxis y posibles parmetros y valores implcitos.
b. Relacin de comandos y su descripcin.
Para el caso de las opciones debe incluirse:
a. Dilogos que se establecen o mensajes informativos.
b. Exposicin de las pantallas de entrada y salida de informacin asociadas a
las diferentes opciones.
III. Tratamiento de los errores.
Forma de manipulacin de todos y cada uno de los errores posibles que puedan
presentarse durante la utilizacin del software.
IV. Recuperacin de los fallos.
Procedimientos para resolver los problemas que puedan presentarse durante la
utilizacin del software y la explicacin de la forma de reiniciar el trabajo.
2.5 Disciplina o flujo de prueba

En la disciplina o flujo de Prueba se realiza primero la validacin del sistema y
despus la prueba del sistema.
Esta disciplina o flujo consta de los pasos siguientes:
Prueba de validacin del software
Prueba del sistema
Balanceo de artefactos y planificacin del prximo ciclo
2.5.1 Prueba de validacin del software
La validacin se logra cuando el software funciona de acuerdo a los intereses del
usuario.
Para ello se revisa si el software cumple con:
Los casos de uso definidos en el anlisis
Los requisitos de rendimiento definidos en el estudio preliminar
Otros requisitos como portabilidad, posibilidad de recuperarse ante errores,
facilidad de mantenimiento, (etc.)
2.5.2 Prueba del sistema
En el paso anterior se prob el software pero el sistema incluye otros elementos
(hardware, personas, bases de datos, etc.). Esta prueba por sus caractersticas no
puede realizarse slo por el analista. Se realiza en los siguientes pasos:
1. Prueba de recuperacin.
2. Prueba de seguridad.
3. Prueba de resistencia.
4. Prueba de rendimiento
2.5.2.1 Prueba de recuperacin
La prueba de recuperacin es una prueba que fuerza el fallo del software de
muchas formas y verifica que la recuperacin se lleva a cabo adecuadamente. Si la
recuperacin es automtica hay que evaluar la correccin de la reinicializacin, de
los mecanismos de recuperacin de estado del sistema, de la recuperacin de
datos y del rearranque. Si la recuperacin requiere intervencin humana hay que
evaluar los tiempos de reparacin para ver si estn dentro de los lmites
aceptables.
2.5.2.2 Prueba de seguridad
La prueba de seguridad intenta verificar que los mecanismos de proteccin
incorporados al sistema lo protegern de hecho de la penetracin impropia. El
encargado de la prueba debe desempear el papel de un individuo que desea
penetrar el sistema usando cualquier medio. Una buena prueba debe penetrar el
sistema, el problema est en que sea costoso y requiera mucho tiempo
2.5.2.3 Prueba de resistencia
Las pruebas de resistencia estn diseadas para enfrentar al software a
situaciones anormales. La prueba de resistencia ejecuta un sistema de forma que
demande recursos en cantidad, frecuencia y volmenes anormales
2.5.2.4 Prueba de rendimiento

Para sistemas en tiempo real o empotrados es inaceptable el software que
proporciona las respuestas requeridas pero que no se ajusta a los rendimientos. La
prueba de rendimiento se desarrolla para probar el rendimiento del software en
tiempo de ejecucin dentro del contexto de un sistema integrado.
2.5.3 Balanceo de artefactos y planificacin del prximo ciclo
Se realiza una revisin de la documentacin obtenida en el ciclo anterior y se
garantiza que todos los cambios realizados en la construccin se incorporen a la
documentacin para realizar el prximo ciclo.
2.6 Fase de Transicin

En esta fase se realiza la introduccin del nuevo sistema en la entidad usuaria.
Preparacin de condiciones.
Implantacin o despliegue del sistema
Existen dos formas de implantacin del sistema:
1. Implantacin paralela.
2. Implantacin directa.
2.6.1 Preparacin de condiciones
En esta fase se realiza el entrenamiento completo del personal que utilizar el
sistema. Tambin se deben convertir ficheros y crear otros imprescindibles para el
funcionamiento del sistema.
2.6.2 Implantacin o despliegue del sistema
2.6.2.1 Implantacin en Paralelo
Se implanta el nuevo sistema sin dejar de utilizar el viejo. Es la forma ms compleja
y costosa. Tiene entre otras las siguientes desventajas
A. El hecho de procesar dos sistemas al mismo tiempo hace que se dificulte el
proceso de comprobacin de los resultados del nuevo sistema y que no se
llegue en algunos casos a verificar totalmente el nuevo sistema.
B. El volumen de datos a verificar y procesar aumenta considerablemente.
C. Pueden cometerse errores con mayor frecuencia.
Las ventajas que tiene son:
A. Se pueden comparar los resultados de ambos sistemas y los tiempos de
procesamiento y respuesta.
B. En caso de falla del nuevo sistema no se afecta la obtencin de la
informacin.
2.6.2.2 Implantacin directa
Se implanta el nuevo sistema sin la utilizacin del viejo. Es la forma menos costosa y
con mayores riesgos.
Presenta las siguientes desventajas:
A. No se pueden comparar resultados con los mismos datos entre los dos
sistemas.
B. En caso de fallas no se obtiene la informacin.
C. Se deben prever los resultados a obtener.
Las ventajas que tiene son:
A. Se puede dedicar mayor esfuerzo a la revisin de los resultados del nuevo
sistema.
B. Tiende a disminuir la cantidad de errores pues el personal slo centra la
atencin en este sistema.
La utilizacin de una u otra forma de implantacin est en dependencia de las
caractersticas del sistema, de la entidad usuaria, del tipo de informacin a procesar
y del rigor conque se haya realizado la prueba.
Si est etapa es aprobada satisfactoriamente por el usuario se comienza la
explotacin de ste, en caso contrario se revisa y reelabora el proyecto en caso de
necesidad en el prximo ciclo. An en caso de aprobarse el sistema pueden existir
solicitudes de cambio del usuario los que pueden hacerse como parte del
mantenimiento del sistema.
Bibliografa
[Alvarez, 1995]
Alvarez, S. Metodologa para el desarrollo de aplicaciones

orientadas a objetos. Tesis presentada para la obtencin del
grado a doctor en Ciencias Tcnicas. La Habana, 1995
[Alvarez, 2000]
Alvarez, S. y Hernndez, A. Metodologa ADOOSI. Versin 5.

Informtica 2001. La Habana
[Boar, 1984]
Boar, B.H. Application Prototyping : a requeriments definition

strategy for the 80s Jhon Wiley & Sons, 1984.
[Boehm, 1981]
Boehm, B.Software Engeneering Economics Prentice Hall,

1981.
[Boehm]
Boehm, Barry. Software Cost Estimation in COCOMO II.

Prentice Hall, 2000
[Booch, 1994]
Booch, B."Object Oriented Design with Applications". Redwood

City, The Benjamin/Cummings Publishing Company, 1994
[Booch, 1997]
Booch, B, Jacobson, I. y Rumbaugh, J. The UML specifications

documents. Santa Clara, Caa: Rational Software Corp. Ver los
documentos en WWW.rational.com
[Booch, 2003]
Grady Booch, Language Once Was KeyNow It's Design,

Microsoft, Http://www.microsoft.com, February 2003 Issue
[Booch, 1999]
Booch, G., Rumbaugh, J., Jacobson, I. The Unified Software

Development Process.Addison-Wesley Longman, Inc. 1999.
[Budd, 1994]
Budd, T."Introduccin a la programacin orientada a

objetos". Addison-Wesley Iberoamericana, 1994.
[Carming, 1989]
Carming, R.G. Development Systems by prototyping. Prentice

Hall, 1989
[Coad, 1990]
Coad, P. and Yourdon, E."Object-Oriented Analysis Yourdon

Press, Prentice Hall Building Englewood". Cliffs, New Jersey.
USA.
[Coad, 1991]
Coad, P. y Yourdon, E."Object-Oriented Design Yourdan Press,

Prentice Hall Building Englewood". Cliffs, New Jersey,1991,
USA.
[Coleman, 1992]
Coleman, D; Hayes, F. and Bear, S."Introducing ObjectCarts or

How to Use Statecharts in Object-Oriented Design" en IEEE
Transactions on Software Engeneering, Vol 18, Num. 1, January
1992.
[Conallen, 2002]
Conallen, Jim. Building Web Application with UML, Second

Edition 2003 Addison-Wesley
[Connell, 1989]
Connell, J.L y Brice, L. Structured Rapid Prototyping Prentice

Hall, 1989.
[Coplien 96]
Coplien, J. O. A Generative Development - Process Pattern

Language. Del libro: "The Pattern Handbook. Techniques,
Strategies, and Application". Cambridge University Press. Pag:
243-300. USA, 1996.
[Currie, 1998]
Currie, M. N. Software Prototyping: An Overview. 1998.

Publicacin
Internet:
www.geocities.com/Heartland/2054/proto2.html
[Fowler, 1998]
Fowler, M. y Scott, K. UML Distilled. Appliying the Standar

Object Modeling Language. Addison Wesley Longman. 1998
[Fowler, 2002]
Fowler, M. Pattern of Enterprise Application Architecture,

OOPSLA 2002
[Gamma]
Design Pattern CD Erich Gamma, Richard Helm, Ralph

Johnson and John Blissides. Addison Wesley Longman. (Gang
of Four Pattern)
[Herderson, 1990] Henderson-Sellers, B., Edwards, J.M."Oriented Systems". Life

Cyde. Comm of the ACM sept. 1990, vol 33, No.9 pp 143-159,
USA
[Jacobson, 1997]
Jacobson, I., Griss, M., et al. Software Reuse. Architecture,

Process and Organization for Business Success. AddisonWesley. Pag: 4-28. New York USA, 1997.
[Johnson, 1988]
Johnson, R. E. y Foote, B. Designing Reusable Classes.

Journal of Object-Oriented Programming. Vol: 2. Pag: 22-35.
June, 1988.
[Kruchten, 1999]
Kruchten, P. The Rational Unified Process. Addison Wesley

Longman, Inc. 4th edition 1999
[Larman, 1999]
Larman, C. UML y patrones. Introduccin al Anlisis y Diseo

Orientado a Objetos. Prentice Hall Hispanoamericana. 1999
[Microsoft]
Microsoft Corporation, Designing Data Tier Components

and Passing Data Through Tiers. Pattern&practices. 2003
[Miller, 1956]
Miller, G. A. "The Magical Number Seven, Plus or Minus Two:

Some Limits on Our Capacity for Procesing Information" en
Psychological Review, pp 63-65, March 1956.
[Norma 19112]
Norma 19112. Tecnologia de la Informacion. Paquetes de

Software. Requisitos de Calidad y pruebas. Cuba
[OMG]
OMG Object management Group, OMG Unified Modeling

Language Specification, March 2003, Version 1.5, formal/0303-01
[Schmauch, 1994] Schmauch, C. H., ISO 9000 for Software Developers, ASQC
Quality Press, Milwaukee, WI., 1994
[Pressman, 2002]
Pressman, R. Ingeniera de Software. Un enfoque prctico.

Quinta Edicin.. McGraw-Hill, Inc. 2002
[Rising 98]
Rising, L. The Patterns Handbook. Techniques, Strategies, and

Applications. Cambridge University Press. Pag: 10-11, 443-469.
USA, 1998.
[Wirfs, 1990]
Wirfs-Brock, R. et al."Disigning Object-Oriented Software".

Prentice-Hall, Engliwood Cliffs, New Jersey. USA.

Adoosi V6

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Adoosi V6

Caricato da

Copyright:

Formati disponibili

Metodologa ADOOSI Versin 6: Metodologa para el desarrollo de

aplicaciones utilizando notacin UML y extensiones para Web y

Ciclo de vida del Proyecto.

2.1.1.2 Definicin del modelo de mini arquitectura (framework)

Revisin y completamiento de la documentacin

Metodologa ADOOSI Versin 6: Metodologa para el desarrollo de

prototipo y especficamente como instrumento de diseo de la interfaz Web. Esta

enfatiza en la interfaz del usuario

es un sistema vivo de trabajo.

es un sistema de software que se crea rpidamente.

suministra un medio de comunicacin efectivo con el usuario

puede ser evaluado por un diseador y/o los usuarios finales

Uno de los cambios introducidos en ADOOSI Versin 6 es lo referente al uso de

descubiertos en ms de un sistema existente, son soluciones exitosas a

Iteracin de Iteracin de Iteracin de Iteracin de Iteracin de Iteracin de Iteracin de

1.2.3 Fase de Elaboracin

1.3 Fase Inicio

1.3.1 Obtencin del modelo del negocio

Se debe profundizar, partiendo del problema a resolver, para definir las

Describe los niveles apropiados de usabilidad teniendo en cuenta los siguientes

Debe tenerse en cuenta factores especiales que pudieran hacer al producto no

1.3.3 Confeccin de un prototipo de interfaz

Quienes usan, eliminan o suministran informacin?

1.3.4.2 Identificar los casos de uso

1.3.5.1 Identificacin del ncleo central de la aplicacin

1.3.6 Analisis de factibilidad

1.3.6.2 Anlisis tcnico

1.3.9.1 Obtencin del modelo del negocio

Figura 2 Smbolo del paquete

Figura 3 Smbolos del diagrama de casos de uso

Figura 4 Ejemplo de diagrama de casos de uso

Respuesta del sistema

Respuesta del sistema

6 Se realiza un anlisis del estado de

Respuesta del sistema

2.2.2 Definicin de las clases preliminares y de las asociaciones

Figura 5 Representacin grafica de las clases frontera. Ejemplo clase Frontera

formulario. Utilizar clases solo para fenmenos del sistema o cosas

Figura 6 Representacin grfica de la clase entidad Cuenta.

Figura 7 Representacin grfica de la clase de control Gestor de Pedidos.

Un flujo de evento que entre informacin primaria, la recupera, la muestra o

<nombre de la clase >

<nombre de los atributos> >

Figura 8 Representacin de la clase

todas las asociaciones como bidireccionales. Esta caracterstica ser refinada

Figura 9 Asociacin entre las clases A y B.

En la figura 10 se muestra la representacin de la multiplicidad en una asociacin.

Figura 10 Asociacin con multiplicidad especificada.

Figura 11 Diagrama de clases del anlisis. No aparecen los nombres de las

2.2.4 Definicin de los diagramas de secuencia y asignacin de servicios o

Figura 12 Diagrama de secuencia. Formato general

Figura 13 Diagrama de colaboracin. Formato general

sern aplicados en el diseo estos permiten definir una estrategia en la asignacin

El sistema global (Controlador de Fachada)

Figura 14 Ejemplo de diagrama de interaccin para el caso del catalogo de

El proceso de confeccin de los diagramas de interaccin y de asignacin de

la ejecucin o que no sern sometidas a pruebas pero de las cuales depende el

2.2.5.2 Casos de uso detallados

Accin del actor

Respuesta del sistema

(1)<Nombre de la operacin y los parmetros correspondientes>

Flujo o disciplina de diseo