Análisis y Diseño Orientado Al Objeto

ANLISIS Y DISEO ORIENTADO AL
OBJETO
A P U N T E S D E M O D E L A M I E N T O D E SI ST E M A S U S A N D O U M L Y U P
Prof. Andrs Muoz Ordenes

Carrera de Ingeniera en Computacin e Informtica
Instituto Profesional La Araucana
Anlisis y Diseo Orientado al Objeto

Apuntes de Modelamiento de Sistemas usando UML y UP
TABLA DE CONTENIDO
INTRODUCCIN ........................................................................................... 7
RESUMEN EJECUTIVO ................................................................................................................ 8
AGREDECIMIENTOS ................................................................................................................... 8
UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETO .............. 9

FUNDAMENTOS DE LA ORIENTACIN AL OBJETO ........................................................................... 10
Objeto .................................................................................................................................... 10
Clase ...................................................................................................................................... 10
Instancias ............................................................................................................................... 11
Atributos y Operaciones ........................................................................................................ 11
Mensajes ............................................................................................................................... 12
Encapsulamiento ................................................................................................................... 12
Herencia ................................................................................................................................ 12
Abstraccin ............................................................................................................................ 13
Modularidad .......................................................................................................................... 14
Reutilizacin .......................................................................................................................... 15
Polimorfismo ......................................................................................................................... 16
METODOLOGAS DE MODELAMIENTO ......................................................................................... 16

La Tcnica de Modelado de Objetos (OMT).................................................................. 17
Fases de la Metodologa........................................................................................................ 17
Los Modelos, Diagramas y Su Notacin ................................................................................ 18
El Proceso Unificado (UP) de Desarrollo de Software .................................................. 22

UP y el Desarrollo Iterativo Incremental ............................................................................... 22
La Retroalimentacin y la Adaptacin: Filosofas de UP ....................................................... 24
La Arquitectura: El Centro de UP .......................................................................................... 24
Las Fases del UP .................................................................................................................... 25
Disciplinas del UP .................................................................................................................. 26
Otros Conceptos Orientados a la Planificacin ..................................................................... 27
EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML) .................................................................. 28

Qu es UML? ............................................................................................................... 28
Visin General de los Metamodelos UML Aplicados al A/DOO .................................... 29
Modelo de Dominio............................................................................................................... 30
Modelo de Casos de Uso ....................................................................................................... 31
Modelo de Anlisis ................................................................................................................ 32
Modelo Arquitectnico ......................................................................................................... 33
Modelo de Diseo ................................................................................................................. 34
Modelo de Implementacin .................................................................................................. 35
2

UNIDAD II. EL ANLISIS ORIENTADO AL OBJETO ........................................ 37

FUNDAMENTOS DEL ANLISIS DE SOFTWARE ............................................................................... 38
Caractersticas de los Requerimientos .......................................................................... 38
Clasificacin de los Requerimientos ............................................................................. 38
ESPECIFICACIN DE REQUISITOS ................................................................................................ 39
Tcnica de Especificacin de Requisitos ....................................................................... 40
Paso 1: Definir el Panorama General .................................................................................... 40
Paso 2: Identificar el o los Clientes del Sistema .................................................................... 40
Paso 3: Definir Los Objetivos y Metas ................................................................................... 40
Paso 4: Identificar las Funciones del Sistema........................................................................ 40
Paso 5: Identificar los Atributos del Sistema ......................................................................... 41
MODELO DE CASOS DE USO ..................................................................................................... 42

Conceptos Bsicos ......................................................................................................... 43
Actor ...................................................................................................................................... 43
Escenario ............................................................................................................................... 43
Caso de Uso ........................................................................................................................... 43
Responsabilidad .................................................................................................................... 44
Formalidad ............................................................................................................................ 44
Artefactos del Modelo .................................................................................................. 44

Proceso de Desarrollo del Modelo ................................................................................ 45
Identificacin de Casos de Uso.............................................................................................. 45
Especificacin de Casos de Uso ............................................................................................. 46
Diagrama de Casos de Uso .................................................................................................... 48
GLOSARIO ............................................................................................................................. 50
MODELO DE DOMINIO ............................................................................................................ 51
Dominio ................................................................................................................................. 51
Clases Conceptuales .............................................................................................................. 52
Proceso .................................................................................................................................. 52

Especificacin del Proceso de Negocio ................................................................................. 53
Identificacin de Clases Conceptuales .................................................................................. 55
Diagrama de Clases Conceptuales......................................................................................... 62
MODELO DE COMPORTAMIENTO............................................................................................... 64
Evento.................................................................................................................................... 64
Contrato ................................................................................................................................ 64
3

Estado .................................................................................................................................... 64

Diagramas de Secuencia de los Eventos de Casos de Uso .................................................... 65
Contratos de las Operaciones ............................................................................................... 68
Diagramas de Estado ............................................................................................................. 71
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ..................................... 73

Especificacin de Funciones .......................................................................................... 74
Modelo de Casos de Uso ............................................................................................... 76
Especificacin de Casos de Uso ............................................................................................. 76
Glosario ......................................................................................................................... 80
Modelo de Dominio ...................................................................................................... 81
Diagrama de Actividades ....................................................................................................... 81
Diagrama de Clases Conceptuales......................................................................................... 82
Modelo de Comportamiento ........................................................................................ 85

Diagramas de Secuencia........................................................................................................ 85
Contratos de las Operaciones ............................................................................................... 89
Diagramas de Estados ........................................................................................................... 90
UNIDAD III. EL DISEO ORIENTADO AL OBJETO ......................................... 91

FUNDAMENTOS DEL DISEO DE SOFTWARE ................................................................................. 92
La Arquitectura del Software ........................................................................................ 92
MODELO ARQUITECTNICO ..................................................................................................... 94
Refinamiento ......................................................................................................................... 94
Componente .......................................................................................................................... 95

Especificacin de los Factores de la Arquitectura ................................................................. 95
Especificacin de las Decisiones de la arquitectura .............................................................. 96
Diagrama de Componentes ................................................................................................... 97
MODELO DE DISEO ............................................................................................................... 98

Realizacin de Caso de Uso ................................................................................................... 99
Responsabilidad .................................................................................................................... 99
Patrones de Diseo ............................................................................................................. 100
Artefactos del Modelo ................................................................................................ 101

Proceso de Desarrollo del Modelo .............................................................................. 101

Diagramas de Colaboracin ................................................................................................ 101

Patrones de Diseo GRASP.................................................................................................. 103
Patrones de Diseo GoF ...................................................................................................... 112
Diagrama de Clases de Diseo ............................................................................................ 115
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ................................... 125

Modelo Arquitectnico ............................................................................................... 125
Diagrama de Componentes ................................................................................................. 125
Modelo de Diseo ....................................................................................................... 128

UNIDAD IV: INTRODUCCIN A LA IMPLEMENTACIN.............................. 139

FUNDAMENTOS DE LA IMPLEMENTACIN DEL SOFTWARE ............................................................. 140
Codificacin de Calidad ............................................................................................... 140
Estndares de Codificacin ......................................................................................... 140
Herramientas CASE ..................................................................................................... 141
MODELO DE IMPLEMENTACIN............................................................................................... 141
Conceptos Bsicos ....................................................................................................... 141
Cdigo.................................................................................................................................. 141
Artefactos del Modelo ................................................................................................ 142

Proceso de Desarrollo del Modelo .............................................................................. 142
Diagrama de Clases de Implementacin ............................................................................. 142
Estructura del Cdigo .......................................................................................................... 147
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ................................... 149

Modelo de Implementacin ........................................................................................ 149
Estructura de Clases ............................................................................................................ 151
ANEXOS ................................................................................................... 155

PLANTILLA DE DOCUMENTACIN DEL A/DOO ........................................................................... 156
Especificacin de Requisitos ....................................................................................... 156
Identificacin del Sistema ................................................................................................... 156
Especificacin de Funciones ................................................................................................ 156
Modelo de Casos de Uso ............................................................................................. 156

Especificacin de Casos de Uso ........................................................................................... 156
Diagrama de Casos de Uso .................................................................................................. 157
Glosario ....................................................................................................................... 157

Modelo de Dominio .................................................................................................... 157
Diagrama de Actividades ..................................................................................................... 157
5

Diagrama de Clases Conceptuales....................................................................................... 157
Modelo de Comportamiento ...................................................................................... 157

Diagramas de Secuencia...................................................................................................... 158
Contratos de las Operaciones ............................................................................................. 158
Diagramas de Estado ........................................................................................................... 158
Modelo Arquitectnico ............................................................................................... 158

Diagrama de Componentes ................................................................................................. 158
Modelo de Diseo ....................................................................................................... 158

Modelo de Implementacin ........................................................................................ 159

Estructura de Clases ............................................................................................................ 159
GUA DE USO DE STARUML ................................................................................................... 160

Introduccin a las Herramientas CASE ........................................................................ 160
Historia ................................................................................................................................ 160
Objetivos ............................................................................................................................. 160
Clasificacin de las Herramientas........................................................................................ 161
UML Case-Tool: StarUML ............................................................................................ 163

Ficha Tcnica ....................................................................................................................... 163
Descripcin .......................................................................................................................... 163
Funcionalidades................................................................................................................... 164
Recomendaciones y Buenas Prcticas ................................................................................ 171
BIBLIOGRAFA ...................................................................................................................... 172

TABLA DE ILUSTRACIONES ...................................................................................................... 174

INTRODUCCIN

RESUMEN EJECUTIVO
Este documento contiene una compilacin de clases y apuntes del curso de Diseo Orientado al
Objeto dictado por el profesor Andrs Muoz O. durante 3 aos seguidos a alumnos de quinto
semestre de la carrera de Ingeniera en Computacin en Informtica del Instituto Profesional La
Araucana.
Los contenidos principales se dividen en 4 unidades:
En la Unidad I se abordan los conceptos bsicos del modelamiento orientado al objeto, su

historia y la descripcin del proceso de desarrollo de software con el cual se basa este
curso.
En la Unidad II se desarrollan los modelos y artefactos en UML correspondientes a la

disciplina del anlisis de requisitos y de sistema del proceso de desarrollo.
En la Unidad III se desarrollan los modelos y artefactos en UML correspondientes a la

disciplina de diseo de sistema del proceso de desarrollo.
En la Unidad IV se introduce una tcnica para la conversin del diseo a cdigo,

preparando la construccin del software.
El contenido de este documento puede ser utilizado como apuntes de curso, material de apoyo
para otros profesores como tambin de alumnos de carreras a fines o similares, solo con la debida
citacin del autor.
Cualquier colaboracin para mejorar este apunte, por favor enviarla a andmunoz@gmail.com.
AGREDECIMIENTOS
Agradezco profundamente a mis alumnos del instituto de los aos 2007, 2008 y 2009, quienes
recibieron este apunte clase a clase, y por supuesto fueron informando todo tipo de errores e
inconsistencias que encontraban.
Adems, agradecer el apoyo y confianza de los profesores Ral Rojas y Nelson Carvallo, quienes me
dieron la oportunidad de lograr desarrollar este ramo. Tambin al profesor Daniel Muoz G., quien
tambin utiliz en su curso esta informacin, validando la aplicabilidad de este contenido
desarrollado.
Y por ltimo, a mi esposa quin fue comprensiva cuando trabajaba dedicadamente en estos
apuntes en la comodidad de mi hogar.
A todos, muchas gracias.
Profesor Andrs Muoz O.

UNIDAD I. LA BASE DEL MODELAMIENTO

ORIENTADO AL OBJETO
El objetivo de esta unidad es entender cmo los conceptos de la orientacin al
objeto tambin son aplicables en el modelamiento de un software y adems cmo
su uso puede ser beneficioso desde el punto de vista del producto de software que
espera el cliente obtener.

FUNDAMENTOS DE LA ORIENTACIN AL OBJETO

Para comenzar, veamos cules son los conceptos bsicos que define la Orientacin al Objeto.
OBJETO
En el mundo real, estamos rodeados de objetos, basta que echemos una mirada a nuestro
alrededor y nos daremos cuenta de ello: el lpiz con el que escribo, la silla en la que estoy sentado,
el apunte que estoy leyendo, el celular que tengo en mi bolsillo, el computador que uso para
conectarme al MSN, el libro de UML que est en la biblioteca, el sistema operativo de mi
computador, el microbs del Transantiago que me trae al instituto, el semforo que me hizo llegar
tarde, etc. Todos estos ejemplos representan distintas cosas que vemos, tocamos, usamos, omos
y entendemos como objetos de nuestra realidad.
Pues, la definicin de lo que es un objeto en OO no est alejada de esa realidad, porque un objeto
no es ms que cualquier cosa con la cual se interacta. As, podemos decir que:
UN OBJETO ES CUALQUIER COSA REAL O ABSTRACTA QUE POSEA
ATRIBUTOS, SE PUEDA ALMACENAR INFORMACIN Y TENGA UN
CONJUNTO
DE
OPERACIONES
CON
LAS
CUALES
SE
PUEDE
INTERACTUAR.
En A/DOO lo que interesa es el comportamiento del objeto. De esta forma, al disear la estructura
de la informacin incorporaremos objetos para representar cada entidad o elemento que
interacta dentro del sistema.
Por ejemplo, una Factura es un objeto ya que posee un cdigo de factura, informacin de a quien
se le est entregando esa factura, la informacin del emisor de dicha factura, el detalle de los
servicios o productos, los montos por esos productos, un total, etc. A pesar de que todas las
facturas que conocemos poseen esta informacin, el objeto se refiere a una de ellas en particular
como individuo nico dentro de su especie.
CLASE
El ser humano posee una capacidad innata de clasificar. Gracias a esta capacidad entendemos que
todos los objetos son de cierto tipo, lo que normalmente lo representamos con un nombre
genrico de dicho tipo. Es as como definimos que:
UNA CLASE ES UNA CLASIFICACIN ABSTRACTA, BAJO LA CUAL
AGRUPAMOS UN CONJUNTO DE OBJETOS QUE POSEEN EL MISMO
TIPO DE CARACTERSTICAS Y LAS MISMAS OPERACIONES.
Cuando hablamos del mismo tipo de caractersticas, queremos decir que las clases definen todos
aquellos objetos que podemos definirlos con la misma plantilla.
10

Por ejemplo, la clase Perro es una clasificacin que hacemos para definir los animales que tiene 4
patas, 2 orejas, que ladran, jadean y que son utilizados como compaa del ser humano por su
fidelidad al amo. De esta forma, estamos agrupando a todos los perros del mundo bajo este
concepto de perro. Sin embargo, cada uno de los perros que conocemos son un objeto en
particular de aquella clase porque posee caractersticas que lo hacen nico entre sus pares: color
de pelo, largo de pelo, talla, peso, frecuencia de ladrido, etc.
INSTANCIAS
La distincin que hacemos entre una clase y un objeto generalmente no es fcil de digerir, pues en
muchos casos tienden a confundirse. Sin embargo, definiremos el concepto de instancia para
hacer ms notoria la diferencia. Es as como decimos que:
UNA INSTANCIA ES UNA REFERENCIA QUE SE HACE A UNO Y SOLO
UNO DE LOS OBJETOS DE CIERTA CLASE.
Cuando en OO hablamos de instancia generalmente nos referimos a la relacin que existe entre
una clase y un objeto. De esta forma escucharemos cosas como por ejemplo: el objeto es una
instancia de una clase o la clase posee como instancias a un conjunto objetos diferentes.
Por ejemplo, podemos decir que el alumno Rodrigo Vera es una instancia de la clase Alumno.
ATRIBUTOS Y OPERACIONES
Las clases poseen cierta estructura la cual define a todas sus instancias. Estas estructuras se
construyen a travs de atributos y operaciones. De esta forma, definiremos que:
UN
ATRIBUTO
ES
UN
DATO
QUE
PERMITE
DEFINIR
UNA
CARACTERSTICA CON LA CUAL SE PUEDE DIFERENCIA A LOS OBJETOS

DE UNA MISMA CLASE.
Tal cual como se define, los atributos son variables entre instancias diferentes o a travs del
tiempo. De esta forma, dos objetos de la misma clase podran tener diferente informacin en
ellos, o simplemente el objeto podra ir variando su atributo a medida que su ciclo de vida vaya
avanzando.
Por ejemplo, toda Persona posee caractersticas como Talla, Peso y Edad. Estos tres atributos van
variando a travs del tiempo y tambin son distintos para diferentes instancias de Persona. As,
Mara Eliana tiene 26 aos, mide 1 metro 64 centmetros y pesa 58 kilgramos, en cambio, Pedro
tiene 47 aos, mide 1 metro 82 centmetros y pesa 75 kilgramos. El prximo ao ambos
cambiaran su edad, d forma que Mara Eliana tendr 27 aos y Pedro 48.
Por otro lado, decimos que:
11

UNA OPERACIN O MTODO ES UNA ACCIN QUE PUEDE REALIZAR

UN OBJETO Y QUE LE PERMITE INTERACTUAR CON LOS ATRIBUTOS
QUE POSEE.
Las operaciones son definidas en la clase, y los objetos automticamente adhieren esa accin a su
ADN, lo que nos permite interactuar con ellos directamente (nosotros solo interactuamos con los
objetos y no con las clases).
Por ejemplo, la Cuenta Corriente posee un atributo de saldo. Cuando de una instancia de la cuenta
corriente hacemos la operacin de Giro o Depsitos, el saldo de la cuenta vara.
MENSAJES
Es importante relacionarse con los objetos de alguna manera estandarizada, de esta forma, se
definen algunas solicitudes que nos permiten interactuar con ellos. Con esta premisa, podemos
definir que:
UN MENSAJE ES LA FORMA CON QUE SE PUEDE INTERACTUAR CON
UN OBJETO.
An cuando esta definicin es muy bsica (y casi abstracta), la lgica de mensajes en el A/DOO
tiene la misma simplicidad, es decir, los mensajes son solo el medio de interaccin que los objetos
ocupan para comunicarse entre s y con el medio ambiente.
ENCAPSULAMIENTO
Dentro del diseo OO es muy importante tener en cuenta que nuestros sistemas no interactan
directamente con los atributos de los objetos. Por lo que definimos un nuevo concepto como:
ENCAPSULAMIENTO
ES
LA
CAPACIDAD
DE
OCULTAR
LA
REPRESENTACIN INTERNA DE UNA CLASE (ATRIBUTOS) UTILIZANDO

OPERACIONES RELACIONADAS CON LAS FUNCIONALIDADES DEL
MISMO.
Con esta herramienta, no necesitamos conocer la definicin interna de un objeto, sino que es
importante saber cules son las operaciones con las cuales se puede interactuar.
HERENCIA
Otro concepto muy utilizado es la herencia. An cuando no tenga nada que ver con dinero de
algn familiar, la herencia es, por decirlo as, la capacidad de entregar atributos y operaciones
entre clases de cierto parentesco. De esta forma definiremos:
12

LA HERENCIA ES EL MECANISMO A TRAVS DEL CUAL SE GENERAN

CLASES QUE COMPARTEN ALGUNOS ATRIBUTOS Y OPERACIONES,
PERO QUE EN SU ESENCIA SON CONSIDERADOS COMO DISTINTOS.
Con esta definicin encontraremos diferentes soluciones a problemas similares, ya que nos abre
una serie de posibilidades sin restriccin.
Por ejemplo, si hablamos de la clase Telfono. Esta clase posee atributos que son conocidos:
Sistema marcador que permite marcar un nmero telefnico
Auricular que permite hablar y escuchar a travs de l
Campanilla o timbre que me permite escuchar cuando alguien llama
De la misma manera podemos identificar algunas operaciones que se pueden realizar con l:
Conectar a otro telfono
Recibir una llamada de otro telfono
Hablar con una persona que est al otro lado del telfono
Colgar el telfono para finalizar una llamada
An as, y tal como hemos visto anteriormente, estoy hablando de todos los telfonos que existen.
Sin embargo, podemos subdividir esta clase en dos grupos: Telfonos Fijos y Telfono Celulares.
Ambos grupos comparten los atributos y operaciones anteriormente mencionadas porque son
todos del tipo Telfono, pero cada uno puede tener algunas otras caractersticas que lo hace
diferente con respecto al otro.
ABSTRACCIN
Como parte del diseo OO, este concepto es una verdadera herramienta en el modelamiento. As,
para entender ms el trmino, definimos:
LA ABSTRACCIN ES LA REPRESENTACIN DE LAS CARACTERSTICAS Y
FUNCIONALIDADES ESENCIALES DE UN OBJETO, DESDE EL PUNTO DE
VISTA DEL OBSERVADOR, SIN DETALLAR NI ESPECIFICAR SU
IMPLEMENTACIN INTERNA.
Este concepto tiene por fin el descomplejizar el diseo, con respecto a la implementacin futura.
En efecto, cuando estamos diseando nuestros sistemas es muy importante tener en cuenta que,
lo que nos interesa, es el comportamiento de los objetos desde el punto de vista del sistema y
no importa mucho la implementacin de cada uno hasta el momento en que los programadores
deban comenzar a implementarlos, utilizando herramientas e instrucciones predecibles segn
nuestra experiencia.
Por ejemplo, si consideramos a la clase Complejo bajo nuestro prisma de abstraccin podemos
mencionar algunas de sus funcionalidades:
13

Crear un objeto de tipo Complejo.
Sumarle otro Complejo.
Restarle otro Complejo.
Obtener su parte real o su parte imaginaria.
Amplificarlo por un nmero.
Etc.
Al leer esta definicin de funcionalidades, podemos rpidamente percatarnos que no hemos

hablado nunca en cmo estn implementadas, sino que esas son las funcionalidades que podemos
utilizar de la clase. Ms an, ni siquiera hablamos de la representacin interna de la clase, porque
para nosotros es transparente.
Es muy importante destacar que la abstraccin nos permite fcilmente ver un conjunto de
definiciones y operaciones de un objeto como algo funcional, sin reparar en sus detalles, porque
es una caracterstica humana. Alguien se ha preocupado de que el ser humano sea un conjunto
de clulas y seres microscpicos que realizan todas las labores que podemos ver? Adems de los
estudiosos de la materia, para nosotros un ser humano no es ms que un objeto con el cual
podemos interactuar y que posee algunas operaciones definidas (aunque a veces no sean
predecibles).
MODULARIDAD
Profundizando un poco en el tema, encontramos conceptos un poco ms avanzados pero que
tienen mucho que ver con el Diseo OO. Por ejemplo, decimos que:
LA MODULARIDAD ES LA CAPACIDAD DE PARCELAR CARACTERSTICAS
Y FUNCIONALIDADES DE UN SISTEMA, EN PAQUETES DE PROGRAMAS
INDEPENDIENTES CON EL RESTO.
Desde el punto de vista de programacin, este concepto es fcil de entender, ya esas

caractersticas y funcionalidades son identificables dentro de la implementacin de las clases el
sistema. Sin embargo, desde el punto de vista del diseo es muy importante tener en cuenta que,
a pesar de no tener claramente identificados los programas y las instrucciones que definen las
clases, son perfectamente agrupables en paquetes de implementacin independientes desde el
punto de vista de su funcionalidad.
Por ejemplo, si tomamos un sistema de remuneraciones, podemos comenzar a identificar las
acciones que deseamos que realice:
Administracin de Empleados
Emisin de Sueldos
Emisin de Reportes
Etc.
14

Ya con esta sencilla divisin obtenemos mdulos que son considerados independientes con
respecto a los dems. Sin embargo, esos mdulos pueden ser mucho ms especficos, por
ejemplo:
Ingreso de Nuevo Empleado
Modificacin de Empleado
Eliminacin de Empleado
Mandato de Pago de Sueldos
Emisin de Liquidaciones de Sueldo
Emisin de Reporte de Sueldos Pagados
Emisin de Reporte de Sueldos de Empleados
Emisin de Certificado de Rentas
Etc.
Administracin de Empleados
Emisin de Sueldos
Emisin de Reportes
Como pueden ver, los mdulos encontrados en el primer ejemplo fueron descompuestos en
este segundo ejemplo para mostrar que se pueden modularizar con distintos niveles de detalles.
Esto a su vez permite que los mdulos sean ms simples y sencillos de implementar, sin embargo,
aumenta la complejidad con respecto a las relaciones y mensajes que se deben utilizar para
integrar estas funcionalidades.
La receta de la modularidad en el diseo tiene que ver con la capacidad de reunir funcionalidades
o eventos del sistema que sean atmicos, de manera tal de independizar cada mdulo para que
integren un sistema como si fuera un verdadero lego.
REUTILIZACIN
Este concepto es uno de los ms importantes temas que resuelve un buen diseo OO, y a su vez,
es una consecuencia de una buena modularidad. Entonces, diremos que:
LA REUTILIZACIN ES EL MECANISMO O PROCEDIMIENTO A TRAVS
DEL CUAL ES POSIBLE UTILIZAR DEFINICIONES DE CLASES Y/O
MDULOS YA EXISTENTES, EN UN PROBLEMA NUEVO, DE MANERA
NTEGRA O CON ALGN NIVEL DE ADAPTACIN.
Por mucho tiempo, la ingeniera de software se ha dedicado a industrializar procesos de manera

de poder reutilizarlos en distintos problemas en forma reiterativa. Sin embargo, la lgica de cada
problema en particular hace que las componentes de software sean cada vez menos reutilizables.
Sin embargo, cuando el sistema se encuentra modularizado, es posible identificar funcionalidades
replicables entre sistemas con ciertas similitudes (imprimir, guardar en disco, etc). Dichas
funcionalidades son definidas de una manera general la que permite su reutilizacin dentro de
otros sistemas.
Es as como aparecen cada vez ms herramientas que hacen ms genricas las soluciones. Por
ejemplo, en el despliegue de las pginas web, los diseadores de los programas navegadores de
Internet se preocupan solo de aprender a interpretar el lenguaje de hipertexto (HTML) de manera
15

ntegra. Sin embargo, ese mismo mdulo intrprete puede ser usado en cualquiera de los
navegadores en forma transparente.
POLIMORFISMO
Recordando lo que conocemos desde la programacin, este concepto es ms o menos similar. As,
definiremos que:
EL POLIMORFISMO ES LA CAPACIDAD DE QUE UNA MISMA
OPERACIN PUEDA REALIZARSE DE FORMAS DISTINTAS EN CLASES
DISTINTAS.
Como podemos ver, el concepto es el mismo, desde el punto de vista del diseo, como de la
programacin, porque trata de explicar cmo la implementacin de las operaciones pueden variar
segn la utilidad y momento en la cual deben ser utilizadas.
Por ejemplo, si hablamos de una clase Polgono, podemos definir sus operaciones:
permetro: Obtiene el valor del permetro del polgono.
rea: Obtiene el valor del rea del polgono.
altura: Obtiene la altura del polgono.
Utilizando la abstraccin, no hemos definido cul es la implementacin de ninguna de estas

operaciones, las cuales sabemos (por nuestros conocimientos de matemticas) que dependiendo
del polgono, las frmulas varan.
Ahora bien definiremos 2 clases que heredan de Polgono: La clase Rectngulo y la clase Tringulo.
Tanto para Rectngulo como para Tringulo, la operacin permetro se calcula como la suma de
los lados de la figura (los 4 lados cuando es cuadrado y 3 lados cuando es tringulo). Sin embargo,
la implementacin vara cuando hablamos de rea y de altura, porque ambas figuras tienen
diferentes frmulas para calcularlas:
El rea de un rectngulo es el producto del lado ms corto por el lado ms largo, en

cambio, el rea de un tringulo es la mitad del producto de la base por la altura.
La altura de un rectngulo es igual al tamao del lado perpendicular a la base, en cambio,

la altura de un tringulo es el tamao del segmento de la recta que pasa por el vrtice
superior y que es perpendicular a la base.
Sin entrar en terreno computacional vemos que la misma operacin definida desde el punto de
vista abstracto en la clase Polgono se ve enfrentado a diferentes frmulas, pero el
comportamiento sigue siendo el mismo (el calcular el permetro, rea y altura).
METODOLOGAS DE MODELAMIENTO
Para comenzar, debes entender que:
16

UNA METODOLOGA DE MODELAMIENTO ES UN CONJUNTO DE

PASOS, FASES, ITERACIONES, DISCIPLINAS Y ETAPAS QUE SE DEBEN
CUMPLIR PARA OBTENER UN MODELO A NIVEL FUNCIONAL, DE
NEGOCIO Y/O DE IMPLEMENTACIN DE UN SISTEMA.
En particular, las Metodologas de Modelamiento Orientado al Objeto son un enfoque de la

ingeniera de software que nos permite modelar un sistema como un grupo de objetos que
interactan entre s. Este enfoque representa un dominio en trminos de conceptos compuestos
por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.
En ste mtodo de anlisis y diseo se crea un conjunto de tcnicas utilizando una notacin
acordada. A continuacin estudiaremos 2 metodologas modernas con las cuales se puede realizar
A/DOO.
LA TCNICA DE MODELADO DE OBJETOS (OMT) 1

La metodologa OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael
Blaha en 1991, mientras James diriga un equipo de investigacin de los laboratorios General
Electric.
OMT es una de las metodologas de anlisis y diseo orientadas a objetos, ms maduras y
eficientes que existen. La gran virtud que aporta esta metodologa es su carcter de abierta (no
propietaria), que le permite ser de dominio pblico y, en consecuencia, sobrevivir con enorme
vitalidad. Esto facilita su evolucin para acoplarse a todas las necesidades actuales y futuras de la
ingeniera de software.
FASES DE LA METODOLOGA
Al igual que cualquier metodologa, OMT se compone de cierta receta que debe cumplir. Las
fases que conforman la metodologa son:
Anlisis. El analista construye un modelo del dominio del problema, mostrando sus
propiedades ms importantes. El modelo de anlisis es una abstraccin resumida y precisa
de lo que debe de hacer el sistema deseado y no de la forma en que se har. Los
elementos del modelo deben ser conceptos del dominio de aplicacin y no conceptos
informticos tales como estructuras de datos. Un buen modelo debe poder ser entendido
y criticado por expertos en el dominio del problema que no tengan conocimientos
informticos.
Diseo del Sistema. El diseador del sistema toma decisiones de alto nivel sobre la
arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas
basndose tanto en la estructura del anlisis como en la arquitectura propuesta. Se
selecciona una estrategia para afrontar el problema.
Ver OMT en http://www.monografias.com/trabajos13/metomt/metomt.shtml
17

Diseo de Objetos. El diseador de objetos construye un modelo de diseo basndose en

el modelo de anlisis, pero incorporando detalles de implementacin. El diseo de objetos
se centra en las estructuras de datos y algoritmos que son necesarios para implementar
cada clase. OMT describe la forma en que el diseo puede ser implementado en distintos
lenguajes (orientados y no orientados a objetos, bases de datos, etc.).
Implementacin. Las clases de objetos y relaciones desarrolladas durante el anlisis de

objetos se traducen finalmente a una implementacin concreta. Durante la fase de
implementacin es importante tener en cuenta los principios de la ingeniera del software
de forma que la correspondencia con el diseo sea directa y el sistema implementado sea
flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que
potenciemos la reutilizacin de cdigo y la correspondencia entre el dominio del problema
y el sistema informtico, si luego perdemos todas estas ventajas con una implementacin
de mala calidad.
LOS MODELOS, DIAGRAMAS Y SU NOTACIN

OMT emplea tres clases de modelos para describir el sistema. Estos modelos permiten, de manera
sencilla y aplicando conceptos orientados al objeto, definir desde un punto de vista OO cada una
de las componentes, funciones y responsabilidades del sistema.
EL MODELO DE OBJETOS EN OMT
EL MODELO DE OBJETOS DESCRIBE LA ESTRUCTURA ESTTICA DE LOS
OBJETOS DEL SISTEMA (IDENTIDAD, RELACIONES CON OTROS
OBJETOS, ATRIBUTOS Y OPERACIONES).
El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo

dinmico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que
sean importantes para la aplicacin. Se representa mediante diagramas de objetos.
La definicin clara de las entidades que intervienen en el sistema es un paso inicial necesario para
poder definir qu transformaciones ocurren en ellas y cundo se producen estas
transformaciones. Esta forma de pensar es inherente al paradigma de OO donde las clases y su
jerarqua determinan el sistema.
Los diagramas de objetos permiten representar grficamente los objetos, las clases y sus
relaciones mediante dos tipos de diagramas: los diagramas de clases y los diagramas de casos
concretos (instancias). Los diagramas de clases describen las clases que componen el sistema y
que permitirn la creacin de casos concretos, los diagramas de casos concretos describen la
manera en que los objetos del sistema se relacionan y los casos concretos que existen en el
sistema de cada clase. En los diagramas que componen este modelo se pueden representar los
siguientes elementos del sistema: objetos y clases, atributos, operaciones, y relaciones o
asociaciones.
Para la construccin del Modelo de Objetos, es importante seguir ciertos puntos esenciales de la
metodologa:
18

Identificar las clases de objetos.
Iniciar un diccionario de datos que contenga descripciones de clases, atributos y

asociaciones.
Agregar asociaciones entre clases.
Agregar atributos a objetos.
Organizar y simplificar las clases de objetos usando herencia.
Probar las rutas de acceso usando escenarios e iterar los pasos anteriores segn sea
necesario.
Agrupar las clases en mdulos, basndose en "acoplamiento cercano" y funcin

relacionada.
La Notacin del Modelo se puede describir en la siguiente cartilla:
ILUSTRACIN 1. NOTACIN DEL MODELO DE OBJETOS DE OMT
MODELO DINMICO
EL MODELO DINMICO DESCRIBE LOS ASPECTOS DE UN SISTEMA
QUE TRATAN DE LA TEMPORIZACIN Y SECUENCIA DE OPERACIONES
(SUCESOS QUE MARCAN LOS CAMBIOS, SECUENCIAS DE SUCESOS,
ESTADOS QUE DEFINEN EL CONTEXTO PARA LOS SUCESOS) Y LA
ORGANIZACIN DE SUCESOS Y ESTADOS.
19

Los conceptos ms importantes del modelado dinmico son los sucesos, que representan
estmulos externos, y los estados, que representan los valores de los objetos. El diagrama de
estados va a representar los sucesos y los estados que se dan en el sistema.
El modelo de objetos describe las posibles tramas de objetos, atributos y enlaces que pueden
existir en un sistema. Los valores de los atributos y de los enlaces mantenidos por un objeto son lo
que se denomina su estado. A lo largo del tiempo, los objetos se estimulan unos a otros, dando
lugar a una serie de cambios en sus estados. Un estmulo individual proveniente de un objeto y
que llega a otro es un suceso. La respuesta a un suceso depende del estado del objeto que lo
recibe, y puede incluir un cambio de estado o el envo de otro suceso al remitente o a un tercer
objeto. La trama de sucesos, estados y transiciones de estados para una clase dada se puede
abstraer y representar en forma de un diagrama de estados. El modelo dinmico consta de
mltiples diagramas de estados, con un diagrama de estados para cada clase que posea un
comportamiento dinmico importante, y muestra la trama de actividad para todo el sistema.
En resumen, los aspectos del sistema que estn relacionados con el tiempo y con los cambios
constituyen el modelo dinmico.
La notacin del Modelo Dinmico se puede observar en la siguiente cartilla:
ILUSTRACIN 2. NOTACIN DEL MODELO DINMICO
Para la construccin del modelo, es necesario definir y realizar algunas actividades:
20

Preparar escenarios para las secuencias de interaccin tpicas.
Identificar eventos entre objetos y preparar trazos de eventos para cada escenario.
Preparar un diagrama de flujo de eventos para el sistema.
Desarrollar un diagrama de eventos para cada clase que tenga un comportamiento

dinmico importante.
Verificar que los eventos compartidos entre diagramas de estado sean consistentes y
correctos.
MODELO FUNCIONAL
EL MODELO FUNCIONAL DESCRIBE LAS TRANSFORMACIONES DE
VALORES
DE
DATOS
(FUNCIONES,
CORRESPONDENCIAS,
RESTRICCIONES Y DEPENDENCIAS FUNCIONALES) QUE OCURREN

DENTRO DEL SISTEMA.
Este modelo muestra la forma en que se derivan los valores producidos en un clculo a partir de
los valores introducidos, sin tener en cuenta el orden en el cual se calculan los valores. Consta de
mltiples diagramas de flujo de datos, que muestran el flujo de valores desde las entradas
externas, a travs de las operaciones y almacenes internos de datos hasta las salidas externas.
Tambin incluyen restricciones entre valores dentro del modelo de objetos. Los diagramas de flujo
de datos no muestran el control ni tampoco informacin acerca de la estructura de los objetos;
todo esto pertenece a los modelos dinmico y de objetos.
El modelo funcional consta de mltiples diagramas de flujo de datos, que especifican el significado
de las operaciones y de las restricciones. Un diagrama de flujo de datos (DFD) muestra las
relaciones funcionales entre los valores calculados por un sistema, incluyendo los valores
introducidos, los obtenidos, y los almacenes internos de datos. Un diagrama de flujo de datos es
un grafo que muestra el flujo de valores de datos desde sus fuentes en los objetos mediante
procesos que los transforman, hasta sus destinos en otros objetos. Un diagrama de flujo de datos
no muestra informacin de control como puede ser el momento en que se ejecutan los procesos o
se toman decisiones entre vas de datos alternativas; esta informacin pertenece al modelo
dinmico. Un diagrama de flujo de datos no muestra la organizacin de los valores en objetos; esta
informacin pertenece al modelo de objetos.
Un diagrama de flujo de datos contiene procesos que transforman datos, flujos de datos que los
trasladan, objetos actores que producen y consumen datos, y de almacenes de datos que los
almacenan de forma pasiva.
Para la construccin del Modelo Funcional, es necesario realizar las siguientes actividades:
Identificar valores de entrada y salida.
Usar diagramas de flujo de datos para mostrar dependencias funcionales.
21

Describir las funciones.
Identificar restricciones.
Especificar criterios de optimizacin.
La notacin se puede resumir en la siguiente cartilla:
ILUSTRACIN 3. NOTACIN DEL MODELO FUNCIONAL
EL PROCESO UNIFICADO (UP) DE DESARROLLO DE SOFTWARE

Tal como ya mencionamos al principio del curso, el Proceso Unificado (UP) es una metodologa de
desarrollo descrita por Ivar Jacobson, Grady Booch y James Rumbaugh (The Three Amigos) que
utiliza conceptos y estrategias OO en el modelamiento del software.
No existe claridad si UP dio origen a RUP (Rational Unified Process) o viceversa, sin embargo es
claro que es la misma metodologa, con la diferencia que el segundo es una versin comercial de
la misma metodologa y apoyada con un paquete de software especfico (Rational Rose
actualmente de IBM).
UP Y EL DESARROLLO ITERATIVO INCREMENTAL
La primera distincin que debemos conocer, es que el UP se basa en un enfoque Iterativo
Incremental. Qu quiere decir esto? Esto significa que cada proyecto de software se divide en
mini-proyectos de menor complejidad y que son resueltos en un menor tiempo. A esta
subdivisin en mini-proyectos se les llama Iteraciones. De esta forma, tenemos que:
22

UNA ITERACIN ES UN INTERVALO DE TIEMPO DENTRO DEL

PROYECTO, EN DONDE SE RESUELVE PARTE DE LA PROBLEMTICA
ENTREGANDO UN MINI-SISTEMA QUE PUEDE SER PROBADO,
INTEGRADO Y EJECUTADO.
La duracin de una iteracin es variable, a pesar de que cada una siempre es un tiempo corto, este
tiempo puede ser desde das como algunas semanas. Entre ms largas son las iteraciones ms
complejos son los mini-proyectos, por lo que se complejiza ms el desarrollo. Los expertos dicen
que una duracin adecuada va entre 2 a 6 semanas. Sin embargo, la duracin de cada iteracin
depende directamente de los objetivos de la misma.
Requerimientos
Diseo
Requerimientos
Tiempo
Diseo
Implementacin
Implementacin
Integracin &
Pruebas
Iteracin
Integracin &
Pruebas
El Producto va creciendo a medida que se va

avanzando en el proyecto
ILUSTRACIN 4. ITERACIONES DEL PROCESO UNIFICADO DE DESARROLLO
Mientras se va avanzando en el proyecto, cada vez que hacemos una nueva iteracin, el producto
final va incrementando su tamao, lo que lo convierte en un proceso incremental. Los miniproyectos se van repartiendo de forma tal de comenzar con un producto muy simple y de poca
envergadura, para luego ir creciendo junto al sistema para llegar a un trmino en donde el sistema
cumpla con todos los requerimientos recogidos del sistema.
Esta estrategia se asemeja mucho a la prototipacin de algunos procesos de desarrollo, pero
difiere en que cada producto es parte del sistema final, y no un prototipo desechable. An as, es
probable que en algunas iteraciones de realicen prototipos, pero stos siempre los veremos
como parte del sistema final.
Cada producto debe ser un mini-sistema que sea utilizable, quiere decir, con el cual se puede
interactuar y comprobar los requerimientos solicitados. Sin embargo, eso lo hace algo voltil, ya
que si no se cumple algn requerimiento en particular, el cliente puede solicitar un cambio en el
desarrollo realizado convirtindose en un tiempo perdido. Este tiempo perdido, como suelen
llamarlo algunos, no lo es tal, pues es la parte que nos ayuda tener ms claro los requerimientos
reales y no los que nosotros creemos que el cliente quiere.
Las ventajas prcticas de que UP sea iterativo son:
Mitigacin de riesgos altos de manera temprana (tcnicos, funcionales, de usabilidad, etc)
23

Progreso visible desde las primeras fases
Retroalimentacin, adaptacin y compromiso por parte de los usuarios
Gestin de la complejidad a procesos largos de anlisis
Reutilizacin de conocimientos aprendidos en iteraciones previas
LA RETROALIMENTACIN Y LA ADAPTACIN: FILOSOFAS DE UP

Dentro del desarrollo de Software hay siempre una aprensin: el cliente no sabe lo que quiere.
Esto se explica de formas muy variadas. Sin embargo, el problema central no es que el cliente no
sepa, sino que es un problema de lenguaje.
Muchos proyectos caen en este juego, ya que comienzan por un levantamiento de
requerimientos en donde los analistas tratan (en forma infructuosa) de capturar todos los
requerimientos que el cliente necesita, llevndose consigo un montn de dudas que hacen que el
anlisis y diseo se torne algo turbio. Esto a su vez lleva a que el desarrollo tome cursos
indeseados para llegar a productos que, a pesar de su exactitud a los requerimientos levantados,
no son satisfactorios para el cliente final. Para mitigar esta situacin muchos comienzan a realizar
documentos de anlisis o de diseo que deben ser firmados por el cliente, respaldando sus
errores, generando un nivel de frustracin al cliente obligndolo a conformarse con el sistema
final entregado.
Esta problemtica es abordada por el UP, ya que compromete la participacin del cliente final en
el proceso de desarrollo desde el principio del proyecto, para realizar la retroalimentacin. Con
esta relacin directa, y el compromiso de parte del usuario, podemos hacer que el sistema se vaya
adaptando a las reales necesidades del cliente y no solo con los requisitos funcionales declarados
al inicio del proyecto.
En las primeras iteraciones, muchas veces trabajaremos con especulaciones de requerimientos.
Sin embargo, considerando el objetivo de esta iteracin, el cliente por su parte entender su
preocupacin y podr clarificar si esta especulacin est correctamente abordada o realmente fue
un invento de los analistas. Esta retroalimentacin es muy importante, ya que nos permite ahorrar
mucho tiempo en corregir el error al final del proyecto. Luego de que hemos clarificado el
requerimiento, podemos adaptarlo de forma tal que cumpla con las expectativas del cliente final.
Pero no todo es color de rosa, ya que el lenguaje ser un gran antagonista en nuestros proyectos.
Ms adelante veremos que esta problemtica se resuelve en parte utilizando UML como lenguaje
comn.
LA ARQUITECTURA: EL CENTRO DE UP
Otro tema importante para el UP es que es un desarrollo centrado en la Arquitectura. Definiremos
que:
ARQUITECTURA ES UNA DESCRIPCIN DE LOS ELEMENTOS MS
IMPORTANTES Y DA UNA PERSPECTIVA DEL SISTEMA COMPLETO.
La arquitectura sirve para:

24

Comprender el sistema
Organizar el desarrollo en mini-sistemas
Fomentar la reutilizacin
Flexibilizar la evolucin del sistema
Esta distincin nos hace nacer otras dudas: cmo se hace una arquitectura slida? Durante las
primeras iteraciones del UP se define esta arquitectura. Esta arquitectura se arma con todas las
vistas del sistema, a travs de metamodelos y con una comprensin general del mismo. Para
armar estos modelos se usan los Casos de Uso. De esta forma, diremos que:
LOS CASOS DE USO SON UN CONJUNTO DE ARTEFACTOS QUE NOS
PERMITEN MODELAR LOS REQUERIMIENTOS DESDE EL PUNTO DE
VISTA DEL USUARIO FINAL Y QUE NOS DAN LAS VISTAS DEL SISTEMA
COMPLETO.
De esta forma, a travs de los casos de uso podemos armar la arquitectura del sistema, de manera
tal que podamos entender y dar un panorama general de lo que se debe realizar en el resto del
proyecto. Generalmente estos casos de uso son generados con el cliente final y en un lenguaje
ms al alcance del usuario, ya que requeriremos una alta retroalimentacin para construir la base
del sistema.
LAS FASES DEL UP
Ahora que ya sabemos bajo qu principios se utiliza el UP, es hora de que veamos cules son las
fases que lo definen y comencemos a adentrarnos en el detalle de esas fases, indicando cules son
los modelos utilizados en el anlisis y diseo orientado al objeto.
Veamos el ciclo de desarrollo desde un punto de vista macro para luego comenzar a desarrollar
cada etapa:
Fase
Iteracin
...
Inicio
Elaboracin
Construccin
Transicin
Ciclo de Desarrollo
ILUSTRACIN 5. FASES DEL PROCESO UNIFICADO DE DESARROLLO
Como vemos en el diagrama, una fase puede estar constituida por una o ms iteraciones, y el ciclo
de desarrollo completo se compone de 4 fases:
25

1. Fase de Inicio (Inception): Tiene por objetivo tener una visin aproximada del sistema,
realizar el anlisis del negocio, definir el alcance del sistema y realizar estimaciones
imprecisas que sern refinadas en las siguientes fases.
2. Fase de Elaboracin (Elaboration): Tiene por objetivo definir una visin refinada del
problema, implementar iterativamente el ncleo central de la arquitectura, resolver los
riesgos altos, identificar ms requisitos y alcances del sistema y realizar estimaciones ms
realistas.
3. Fase de Construccin (Construction): Tiene por objetivo implementar en forma iterativa
el resto de los requerimientos de menor riesgo y elementos ms sencillos, adems de
preparar el despliegue del sistema en la siguiente fase.
4. Fase de Transicin (Transition): Tiene por objetivo realizar las pruebas del tipo beta y
adems de implementar el despliegue del sistema.
DISCIPLINAS DEL UP
Es importante destacar que las fases del proceso de desarrollo de software no definen en donde
se disea o en qu parte se programa, por el contrario, existe en cada iteracin un nmero de
disciplinas con las cuales se cruzan estas fases y que si incluyen metodologas de anlisis, diseo,
construccin y calidad. Estas disciplinas son:
a) Modelado del Negocio
b) Requisitos
c) Diseo
d) Implementacin
e) Prueba
f)
Despliegue
g) Gestin de Configuraciones y Cambios

h) Gestin del Proyecto
i)
Entorno
En cada fase, los matices que se les da a cada disciplina es muy importante. Por ejemplo, un
diagrama muy interesante es el siguiente:
26

ILUSTRACIN 6. CARGA DE TRABAJO POR DISCIPLINA EN EL PROCESO UNIFICADO DE DESARROLLO
En este diagrama podemos ver como la carga de trabajo en cada disciplina va variando
dependiendo de las fases del proyecto, pero no significa en muchos casos que en etapas
posteriores (o anteriores) no exista, pero que es menos importante desde el punto de vista del
objetivo de la iteracin en cuestin. En particular, nosotros nos centraremos en las 3 primeras
disciplinas, ya que son parte del Anlisis y Diseo OO. El resto de las disciplinas son parte del
proyecto en otras reas del mismo.
OTROS CONCEPTOS ORIENTADOS A LA PLANIFICACIN
Para terminar la visin general del UP, debemos tener en cuenta que existen algunos conceptos
que van orientados a la planificacin, ms que al diseo, pero que son importantes clarificar desde
un punto de vista del proyecto de software.
Estos conceptos, se definen a continuacin:
Proyecto es el conjunto de definiciones y la planificacin necesaria para resolver una

problemtica puntual.
Hito es un punto de terminacin de una iteracin o etapa del proyecto en donde es

necesaria tomar alguna decisin o evaluacin importante.
Producto o Entregable es el resultado fsico de una iteracin en donde es entregado y

validado tanto los requisitos, como el diseo o la implementacin del sistema.
Versin es un subconjunto estable y ejecutable del producto final.
Incremento es la diferencia (delta) entre las versiones de dos iteraciones seguidas.
Versin Final se define cuando el sistema se lanza para su puesta en produccin y es el

ltimo hito del proyecto.
27

EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML)

UML nace originalmente como una iniciativa de Booch y Rumbaugh en el 1994 cuando combinan
las notaciones visuales de sus mtodos de Booch y OMT (citados anteriomente). Luego de eso, se
consolid con la incorporacin de Jacobson, y posteriormente el aporte continuo de Cris Kobryn,
refinando el proceso iniciado por The Three Amigos.
Hablando del lenguaje, dice textualmente:
EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML) ES UN
LENGUAJE
PARA
ESPECIFICAR,
VISUALIZAR,
CONSTRUIR
DOCUMENTAR LOS ARTEFACTOS DE LOS SISTEMAS SOFTWARE, AS

COMO PARA EL MODELADO DEL NEGOCIO Y OTROS SISTEMAS NO
SOFTWARE.
Esta definicin formal, entregada por el Object Management Group (OMG), quien adopt a UML
como lenguaje estndar en 1997, define claramente qu es y para qu sirve. Es as como vemos
claros indicios de algo que ya habamos visto:
UML es un lenguaje, compuesto por una sintaxis, pero solo comprende de la notacin o
nomenclatura y no se hace cargo del proceso de desarrollo (para eso est el Proceso
Unificado que veremos ms adelante).
UML sirve para especificar, visualizar, construir y documentar nuestros sistemas a travs
de metamodelos que sirven en las diferentes etapas del proceso de desarrollo de
software.
UML documenta sistemas software y otros sistemas no software porque no solo aplica
el modelamiento a las componentes de software de un sistema, sino tambin es factible
modelar procesos y el mismo negocio a travs de los metamodelos que propone la
metodologa de desarrollo.
Como se puede ver, UML no es solo notacin aislada, sino que tambin tiene un potencial
maysculo cuando hablamos de acompaar al proceso de desarrollo de software. Sin embargo, las
disciplinas de anlisis y diseo que nos interesa estudiar no estn dadas por un manual de UML,
sino que, a travs del uso de este lenguaje, podremos plasmar en documentos o diagramas los
modelos que sean necesarios de realizar.
A continuacin, daremos un paseo por el UML, como lenguaje, y su aplicabilidad orientada en las
disciplinas de UP como parte del proceso de desarrollo de software.
QU ES UML?
UML se define a travs de dos elementos importantes: una Notacin y un Metamodelo. Diremos
entonces que:
28

LA NOTACIN ES LA SINTAXIS DEL LENGUAJE DE MODELADO.
Para esta definicin tenemos un mundo completo de preguntas. Cul sintaxis? En qu lenguaje?
Qu quiere decir? En realidad la respuesta es ms fcil de lo que parece, ya que la notacin, tal
cual como versa su significado textual, es un conjunto de elementos utilizados en los artefactos.
UN ARTEFACTO ES UN ELEMENTO DEFINIDO A TRAVS DE LA NOTACIN
DEL LENGUAJE Y QUE MUESTRA UN PUNTO DE VISTA DE LO QUE SE
REQUIERE MODELAR.
De esta manera, los artefactos utilizan la notacin de manera de poder dar una visin del
problema en cuestin. As, podemos definir diferentes artefactos dependiendo tambin del punto
de vista que se desea plantear.
Existen 2 tipos de artefactos:
Diagramas: Son aquellos artefactos que utilizan una notacin principalmente grfica o
visualmente esquemtica.
Documentos: Son aquellos artefactos que describen a travs de un lenguaje natural o
estructurado diferentes propiedades de la vista que se desea modelar.
En el segundo caso (documentos), UML provee plantillas que definen qu tipo de informacin se
debe describir, indicada por el artefacto respectivo, pero no define el idioma. Para esto se
recomienda que el lenguaje siempre sea el adecuado a la audiencia del mismo, de esta manera, si
es orientado al cliente, el lenguaje natural es ms adecuado. En cambio si es orientado al
programador, puede serlo un lenguaje estructurado o incluso un pseudocdigo.
Ahora, si seguimos con definiciones, decimos que:
EL METAMODELO ES UN CONJUNTO DE ARTEFACTOS AGRUPADOS PARA UN
OBJETIVO ESPECFICO.
Segn lo que aqu estamos planteando, entonces, para un metamodelo, requeriremos utilizar la
notacin (UML) necesaria que se ajuste al objetivo planteado a travs de un conjunto de
artefactos (diagramas o documentos) que tengan las vistas que cumplan con el objetivo.
Es as como UML tiene bien especificados los metamodelos necesarios en cada etapa del
desarrollo y la notacin en cada modelo que debe ser utilizada.
VISIN GENERAL DE LOS METAMODELOS UML APLICADOS AL A/DOO

Segn lo expresado en la parte anterior, y llevndolos al mbito del A/DOO, los metamodelos nos
ayudan a graficar, con un notacin conocida (UML), nuestros modelos de anlisis y propuestas de
diseo (de software) para un problema particular que queremos resolver.
29

Ahora bien, si esto lo cruzamos con la metodologa UP que ya vimos la clase pasada, tenemos
que para cada una de las disciplinas que son parte esencial del UP podemos asociar uno o ms
modelos. Es as como se plantea una visin de los modelos en UML de la siguiente forma:
ILUSTRACIN 7. METAMODELOS APLICADOS A LA METODOLOGA
Como se puede observar, no es fcil separar el modelado del negocio del anlisis de
requerimientos, ya que con ambos podemos completar toda la informacin necesaria para realizar
un diseo de software. Adems, al no ser un proceso lineal, es probable que dentro del tiempo del
anlisis que se utiliza, el modelado del negocio pueda realizarse en forma paralela.
Veamos ahora qu son cada uno de los metamodelos planteados en esta grfica y cules son sus
objetivos.
MODELO DE DOMINIO
Este primer modelo lo podemos definir de la siguiente forma:
ES UNA REPRESENTACIN VISUAL (DIAGRAMA) DE LAS CLASES
CONCEPTUALES U OBJETOS DEL MUNDO REAL EN UN DOMINIO DE
INTERS.
30

La idea central de estos modelos es representar las clases conceptuales y no los componentes de
software, utilizando un lenguaje ms cercano al negocio o dominio en el cual est inmersa la
solucin en vez de centrarse en explicar desde el punto de vista tecnolgico el problema (para eso
est el Modelo de Diseo).
DIAGRAMAS DE CLASES CONCEPTUALES
La notacin que utilizan es muy similar a la que se usan en los Diagramas de Clase del modelo de
diseo, sin embargo a diferencia de estos diagramas, la representacin de las clases tiene ms que
ver con conceptos que con el modelamiento de objetos a travs de clases de software.
Es informacin relevante para el modelo de dominio todo lo que tiene que ver con los casos de
uso (Especificacin de Casos de Uso), ya que en ella se muestran los procesos elementales que se
desean resolver. De esta misma manera, el uso de la informacin modelada en este diagrama es
de gran utilidad para incorporar informacin para los Contratos de las Operaciones, Glosario y
para el Modelo de Diseo.
DIAGRAMAS DE ACTIVIDADES
Es una forma especial de diagrama de estado usado para modelar una secuencia de acciones y
condiciones tomadas dentro de un proceso. La especificacin del UML define un diagrama de
actividad como: una variacin de una mquina estados, lo cual los estados representan el
rendimiento de las acciones o subactividades y las transiciones se provocan por la realizacin de
las acciones o subactividades.
El propsito del diagrama de actividad es modelar un proceso de flujo de trabajo y/o modelar
operaciones (del negocio).
MODELO DE CASOS DE USO
Antes de mirar el objetivo del modelo, definamos algo ms bsico an y que es el trmino Caso de
Uso:
ES UNA COLECCIN DE ESCENARIOS RELACIONADOS, QUE DESCRIBE
A LOS ACTORES Y LA INTERACCIN QUE ELLOS REALIZAN CON EL
SISTEMA PARA CONSEGUIR Y SATISFACER UN OBJETIVO ESPECFICO.
Este concepto es el centro del modelo, ya que intenta explicar que, en otras palabras, un caso de
uso no es ms que el uso particular (escenario) que le puede dar el usuario final (actor) al sistema
para resolver su problema. Con este concepto claro, podemos definir que el modelo:
ES EL CONJUNTO DE TODOS LOS CASOS DE USO DEL SISTEMA, EN
DONDE SE DETALLA LA FUNCIONALIDAD Y EL ENTORNO DE STE.
Despus de esta definicin, podemos decir que en realidad el modelo de casos de uso no es ms
que un grupo de modelos que definen tanto las funcionalidades del sistema como de los detalles
tiles para el diseo de software.
31

Para entender mejor, expliquemos en forma separada los diferentes diagramas y artefactos que
son parte importante de este modelo.
ESPECIFICACIN DE CASOS DE USO
Una de las actividades principales que se deben realizar en la disciplina de anlisis de requisitos es
especificar el detalle de los requerimientos funcionales en casos de uso. De esta forma, este
artefacto es la documentacin detallada de dichos requerimientos, a travs de una estructura
completa que incluye objetivos de los actores, escenarios de xito, escenarios alternativos,
variantes tecnolgicas, restricciones, etc.
Este artefacto bsicamente es un documento y no es una grfica, como pasa con los diagramas,
sino que ms bien es un detalle (escrito en espaol) con cierta estructura fija que UML define.
La fuente de informacin necesaria para la especificacin deben ser los requerimientos
funcionales directamente obtenidos del cliente (con su lenguaje natural) y su resultado es parte
esencial para el resto de artefactos del modelo de casos de uso.
DIAGRAMA DE CASOS DE USO
Uno de los primeros artefactos grficos utilizados en el proceso de desarrollo es el diagrama de
casos de uso. Este artefacto tiene por objetivo el de organizar, en forma visual, cules son los
casos de uso del sistema, su contexto, los lmites y la relacin que tienen con respecto a los
actores del mismo.
La notacin que utilizan los diagramas de casos de uso por lo general es muy simple, con tipos de
relaciones bsicas y sin un detalle que muestre implementacin (como corresponde). Adems, es
importante recordar que la parte importante de los casos de uso es su especificacin y no el de
llenarse de diagramas que muestren su contexto.
GLOSARIO
Es un documento que pone en comn toda la terminologa y su utilizacin dentro del dominio de
anlisis. Su propsito es poder comprender mejor el negocio en el cual se va a disear el sistema
para que todos los actores involucrados mantengan un nivel de entendimiento similar.
MODELO DE ANLISIS
El modelo de anlisis o de comportamiento se puede definir de la siguiente forma:
ES UN CONJUNTO DE ARTEFACTOS QUE PERMITEN IDENTIFICAR EL
COMPORTAMIENTO DEL SISTEMA O PARTES DEL MISMO A TRAVS
DE LOS ESCENARIOS PRESENTADOS EN EL MODELO DE CASOS DE
USO Y EN FUNCIN DE LAS CLASES CONCEPTUALES.
Es claro identificar que este modelo es el que da pie a identificar los primeros elementos de diseo
del sistema. Sin embargo, la mayora de los anlisis se hacen a travs del concepto de caja negra
que nos permite abstraernos de la implementacin.
32

Los artefactos asociados a este modelo son:

DIAGRAMAS DE SECUENCIA
Es un artefacto creado de manera rpida y fcil, que muestra los eventos de entrada y salida
relacionados con el sistema que se est estudiando. De esta manera, el diagrama de secuencia
muestra el comportamiento como si fuera una caja negra, es decir, sin entender la lgica
implementada dentro, sino que desde el punto de vista externo.
Desde el punto de vista del anlisis, los actores que se relacionan con el sistema generan
diferentes eventos. Estos eventos, organizados como parte de un escenario especfico de uso, son
los llamados diagramas de secuencia del sistema, y nos ilustran esta interaccin tanto con los
actores (tal como dijimos anteriormente) como con otros sistemas externos.
La visin que se utiliza en estos diagramas debe ser para entender el comportamiento del sistema,
y no de definir su implementacin, es por eso que la abstraccin nos ayuda a elaborar mejor estos
diagramas. La informacin necesaria para estos diagramas se obtiene de los casos de uso
(especificacin).
CONTRATOS DE LAS OPERACIONES
Los contratos de las operaciones del sistema describen el resultado de la ejecucin de las
operaciones en funcin de los cambios de estado de los objetos del dominio. Cada una de las
operaciones es vista como una caja negra que recibe cierta informacin de entrada y que
produce cierta informacin de salida, sin la necesidad de saber cmo se produce esta ltima.
El artefacto UML que define un contrato, es un documento que contiene algunos campos
sencillos de llenar. De esta manera, el analista puede determinar informacin adicional para el
anlisis desde el punto de vista funcional.
La informacin esencial para construir estos artefactos son necesariamente las operaciones
detectadas en los diagramas de secuencia y a partir del detalle de los casos de uso (especificacin
de casos de uso).
DIAGRAMA DE ESTADOS
Este diagrama nos muestra el comportamiento de objetos, clases, procesos y casos de uso a travs
de sus cambios de estados. Es utilizado para describir el comportamiento a diferentes niveles de
detalle, dependiendo de lo que se quiere entender.
La aplicacin de este artefacto ser para describir dinmicamente el comportamiento del sistema
o partes de l a travs de los casos de uso o elementos conceptuales del sistema, es por eso que
es muy relevante en este modelo.
MODELO ARQUITECTNICO
Este modelo podemos definirlo de la siguiente manera:
33

EL MODELO ARQUITECTNICO DEFINE LA ORGANIZACIN Y LAS

INTERFACES QUE DEBE
TENER EL SISTEMA PARA HACERLO
REUTILIZABLE Y MODULAR.
Es fcil ver que en este modelo, tambin conocido como Arquitectura de Software, se definir la
modularidad de nuestro sistema. A pesar de que en el proceso estricto, la arquitectura tiene ms
informacin que los mdulos del sistema, para efectos acadmicos solo veremos esa dimensin
del modelo2.
DIAGRAMA DE COMPONENTES
Un diagrama de componentes representa cmo un sistema de software es dividido en
componentes y muestra las dependencias entre estos componentes. Los componentes fsicos
incluyen archivos, cabeceras, libreras compartidas, mdulos, ejecutables, o paquetes. Los
diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden
ser usados para modelar y documentar cualquier arquitectura de sistema.
Debido a que estos son ms parecidos a los diagramas de casos de usos estos son utilizados para
modelar la vista esttica de un sistema. Muestra la organizacin y las dependencias entre un
conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del
sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
MODELO DE DISEO
El modelo de diseo lo podemos definir como:
EL PROCESO A TRAVS DEL CUAL SE DEFINEN LAS CLASES DE
SOFTWARE, SE LES AADEN ATRIBUTOS, OPERACIONES Y EL PASO DE
MENSAJES PARA SATISFACER LOS REQUISITOS DEL PROBLEMA.
Con esta definicin, podemos decir que el modelo de diseo define cmo lograr el objetivo del
sistema, incorporando las clases de diseo que se deben implementar y por supuesto entregando
detalles que van a apoyar el proceso de implementacin.
REALIZACIN DE CASOS DE USO Y DIAGRAMAS DE COLABORACIN
Una definicin formal de lo que es una realizacin dice que la realizacin describe el cmo se
realiza un caso de uso particular en el modelo de diseo, en funcin de los objetos que colaboran.
De esta forma, en el diseo, el concepto de realizacin de caso de uso en realidad no es ms que
una forma de relacionar los casos de uso analizados con el diseo de objetos que satisface los
requisitos.
La definicin formal de la arquitectura es un conjunto de decisiones significativas sobre la organizacin del

sistema, la seleccin de elementos estructurales y sus interfaces, el comportamiento dado por la
colaboracin de sus elementos y las motivaciones o fundamentos sobre el diseo del mismo.
34

Por otro lado, la forma de realizar los casos de uso es utilizando diagramas de colaboracin los
cuales grafican en forma visual cules son las operaciones e interacciones entre los diferentes
objetos del dominio.
La informacin necesaria para realizar los casos de uso es, principalmente, las especificaciones de
los casos de uso. Sin embargo, para aquellas operaciones que se hayan definido contratos, este
detalle nos especifica mayor informacin tambin para la realizacin.
DIAGRAMA DE CLASES DE DISEO
Es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases,
atributos y las relaciones entre ellos.
A pesar que la notacin es similar al usado en el modelo de dominio, el diagrama de clases de
diseo incorpora notacin adicional y por supuesto un detalle mayor desde el punto de vista de la
implementacin, ya que el objetivo es especificar con el mximo de detalle posible la estructura,
su composicin y la relacin de los objetos que componen el sistema.
La informacin usada en el DCD para la definicin de las clases y sus operaciones sale en su
mayora como parte de las realizaciones de casos de uso. En efecto, de los diagramas de
interaccin, podemos obtener de manera sencilla las operaciones de cada clase, ya que es fcil
encontrarlas como interacciones entre sus instancias de objetos.
MODELO DE IMPLEMENTACIN
Este modelo se define como:
UN CONJUNTO DE ARTEFACTOS DE IMPLEMENTACIN COMO EL
CDIGO FUENTE, DEFINICIONES DE BASES DE DATOS, PGINAS,
PROGRAMAS, ETC.
Tal como queda definido, el modelo de implementacin se preocupa de contener el cdigo a

travs de diferentes estrategias. Por ejemplo, una tcnica es la transformacin de diseos en
cdigos desde las definiciones de las clases e interfaces y la definicin de los mtodos desde el
DCD.
Es claro ver que el principal alimentador de este modelo es el modelo de diseo, quien ha llevado
el detalle de cmo es el software hasta detallar las operaciones.
Una gua rpida de este modelo es la siguiente:
Crear definiciones de las clases a partir de los DCDs. Con esto podemos definir
rpidamente la estructura de nuestras clases fsicas o programas, sin lograr detallar el
funcionamiento del sistema todava.
Crear los mtodos a partir de los diagramas de interaccin. Con esto podemos entender el
funcionamiento de cada una de las operaciones en su mecnica interna, lo que nos
35

permite encontrar fcilmente la secuencia lgica de las instrucciones dentro de los

mtodos de los objetos.
Ordenar la implementacin. Con esto es importante que tengamos un orden de
implementacin definido desde la menos a la ms acoplada.
Programar probando primero. Con esto se puede minimizar la cantidad de errores, ya que
las pruebas de unidad se van haciendo antes de que ya est desarrollado el cdigo
completo. De esta manera la mayor cantidad de errores tpicos es resuelto en la
codificacin.
36

UNIDAD II. EL ANLISIS ORIENTADO AL

OBJETO
Durante este captulo veremos cmo recolectar los requerimientos y cmo ellos
van agregando informacin, a travs de modelos desarrollados en UML, para
recabar y recolectar el mximo detalle necesario para construir nuestros diseos
de software.
37

FUNDAMENTOS DEL ANLISIS DE SOFTWARE

Segn la definicin de Wikipedia se entiende por necesidad una carencia o la exigencia de un
objeto. Si esto lo llevamos al plano informtico, una necesidad es la respuesta a la carencia o la
exigencia de algo dentro de un contexto de negocio (dominio).
Para comenzar a describir un buen modelo de software, es importante distinguir respecto a la
necesidad un concepto que ser el respaldo de lo que debemos de disear. Definamos entonces el
concepto de Requerimiento o Requisito:
UN
REQUERIMIENTO
REQUISITO
ES
UNA
NECESIDAD
DOCUMENTADA SOBRE EL CONTENIDO, FORMA O FUNCIONALIDAD

DE UN PRODUCTO O SERVICIO.
Es muy importante comprender que se habla de una necesidad documentada, porque muchas
veces se confunden las necesidades con los requerimientos. De esta forma, podemos dejar muy en
claro que un requerimiento es la respuesta a la necesidad que un cliente busca satisfacer con
alguna funcionalidad o capacidad del sistema.
CARACTERSTICAS DE LOS REQUERIMIENTOS

Los requerimientos poseen algunas caractersticas que necesitamos destacar y diferenciar. De esta
forma podemos decir que un requerimiento, que se aprecie como tal, debe ser:
Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
Sin ambigedad: El texto debe ser claro, preciso y tener una nica interpretacin posible.
Conciso: Debe redactarse en un lenguaje comprensible para los usuarios en lugar de uno
de tipo tcnico y especializado, aunque an as debe referenciar los aspectos importantes.
Consistente: Ningn requerimiento debe entrar en conflicto con otro requerimiento
diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos
requerimientos tambin debe ser consistente.
Completo: Los requerimientos deben contener en s mismos toda la informacin
necesaria, y no remitir a otras fuentes externas que los expliquen con ms detalle.
Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con
el dinero, el tiempo y los recursos disponibles.
Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue
satisfecho o no. Esta verificacin puede lograrse mediante inspeccin, anlisis,
demostracin o testeo.
CLASIFICACIN DE LOS REQUERIMIENTOS

Existen 2 grandes grupos de requerimientos:
38

Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas de

los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales
debe funcionar.
Los requerimientos del sistema establecen con detalle las funciones, servicios y
restricciones operativas del sistema.
Los requerimientos de sistema adems pueden ser clasificados a travs de un modelo denominado
FURPS+, el cual es un acrnimo de las categoras escritas en ingls, las que logran realizar una
clasificacin de una manera amplia. Esta es la clasificacin:
Funcional (Functional): relacionados con caractersticas, capacidades y seguridad del
sistema.
Usabilidad (Usability): relacionado con factores humanos, ayuda y documentacin.
Fiabilidad (Reliability): relacionado con la frecuencia de cadas, capacidad de recuperacin
y previsin de ellas.
Rendimiento (Performance): relacionado con los tiempos de respuesta, productividad,
precisin, disponibilidad y uso eficiente de los recursos.
Soporte (Supportability): relacionado con la adaptabilidad, facilidad de mantenimiento,
multi-lenguaje y configurabilidad.
Y el signo + corresponde a:
Implementacin: relacionado con la limitacin de los recursos, lenguajes, herramientas,
hardware, etc.
Interoperabilidad: relacionado con las restricciones impuestas para la interaccin con
sistemas externos.
Operacin: relacionado con la gestin del sistema en su puesta en marcha.
Empaquetamiento: relacionado con la capacidad de empaquetar el sistema.
Legales: relacionado con las licencias de uso, instalacin de componentes, etc.
Es bastante til trabajar con una categorizacin de los requerimientos. Esta es una base con la cual
se puede comenzar, sin embargo, existen otras clasificaciones muchas veces ms simples, pero
que dejan fuera una buena distincin. Dependiendo del estilo de anlisis que se utiliza, realizar
una u otras es bastante indiferente, porque la real distincin que uno debe tener es de los
requerimientos funcionales (caractersticas y comportamiento del sistema) con los
requerimientos no funcionales (usabilidad, fiabilidad, rendimiento, soporte, etc).
Por qu est ltima distincin? Los requerimientos funcionales son los prcticamente definen las
funciones del sistema.
ESPECIFICACIN DE REQUISITOS
39

A pesar de que no es parte del UML, la formalizacin de los requerimientos es una gran ayuda
desde el punto de vista de claridad de lo que realmente necesita el cliente. Es por eso que aqu se
definen algunos artefactos recomendados para esta fase previa al anlisis3.
TCNICA DE ESPECIFICACIN DE REQUISITOS

PASO 1: DEFINIR EL PANORAMA GENERAL
Este elemento permite definir el entorno del sistema, es decir, el marco en el cual se desenvolver
ste.
Por ejemplo, un panorama general sera algo como: D&S, distribuidor de alimentos a travs de
distintos formatos y que agrupa los supermercados Express de Lder, Hiper Lder y Ekono.
PASO 2: IDENTIFICAR EL O LOS CLIENTES DEL SISTEMA
Lo que se quiere definir en este punto es quienes son los principales usuarios finales del sistema,
de manera de que se puedan identificar aquellas fuentes del negocio ricas en informacin
(stakeholders). En esta parte se incluyen organizaciones y personas. Por ejemplo, Los cajeros, el
rea de finanzas, inventario y SecurePay.
PASO 3: DEFINIR LOS OBJETIVOS Y METAS
Las metas definen qu es lo que se espera mejorar con este sistema. En esta parte es importante
que se detalle claramente lo que el cliente espera obtener con la implementacin.
Por ejemplo, la meta es una mayor automatizacin del pago en las cajas registradoras, dar
soporte a los servicios ms rpido, ms baratos y mejores y a los procesos de negocio a travs de
un sistema de terminal para el punto de venta que se utilizar en las ventas del supermercado .
PASO 4: IDENTIFICAR LAS FUNCIONES DEL SISTEMA
Esta es la parte medular de esta definicin, ya que debe contener lo que debe hacer el Sistema
en anlisis. Es importante no solo identificarlas, sino que tambin listarlas en grupos cohesivos y
lgicos. De esta forma, se propone ingresar las funciones del sistema en una tabla con el siguiente
formato:
# Ref:
Funcin:
Descripcin:
Categora:
ILUSTRACIN 8. PLANTILLA DE ESPECIFICACIN DE FUNCIONES
En cada campo se debe indicar el detalle de la siguiente forma:

Ref #: Indicar una referencia, como por ejemplo R1.1, R2.4, etc. El primer nmero indica el
grupo y el segundo es un correlativo dentro de ese grupo.
3
Existen otros artefactos que pueden detallar estos requerimientos, pero no sern abordados en el curso
40

Funcin: Se debe dar un nombre autoexplicativo que haga referencia a lo que sta realiza.
Descripcin: Se debe describir en forma sinttica y exacta la funcin que debe realizar el
sistema frente a las necesidades del usuario final.
Categora: Es necesario indicar un cierto nivel de prioridad clasificada por su significado y
que pueden consumir tiempo cuando no son formalizadas. Estas categoras son:
o Evidente: Debe realizarse y el usuario debera estar consciente de ello.
o Oculta: Debe realizarse, pero no necesariamente es visible para el usuario
(procesos de soporte, por ejemplo).
o Superflua: Son opcionales ya que su inclusin no repercute significativamente en
las otras funciones.
PASO 5: IDENTIFICAR LOS ATRIBUTOS DEL SISTEMA
Estos no son funciones, sino que valores que pueden abarcar algunas o todas las funciones del
sistema. Por lo general tienen que ver con aquellos requerimientos no funcionales. Se propone el
siguiente formato4:
Atributo
Detalles y Restricciones
Categora
ILUSTRACIN 9. CONTINUACIN DE LA PLANTILLA DE ESPECIFICACIN DE FUNCIONES
Cada uno de los atributos tiende a tener un detalle que contiene valores discretos, confusos o
simblicos. Adems, podra tener restricciones de frontera, que son las condiciones obligatorias,
generalmente en un rango de valores, de un atributo. Por ltimo, se debe indicar qu tipo de
categora o de requerimientos estamos hablando (referido al FURPS+ por ejemplo).
Supongamos por un momento que el problema que se nos plantea resolver con un sistema es
hacer un aplicativo para administrar la caja de un supermercado, tambin conocido como Punto
de Venta (PDV). En una primera reunin se recogen algunos requerimientos:
La caja debe permitir el ingreso del cdigo de los productos en forma manual o a travs de
una pistola lectora de cdigos de barra.
Si la caja se cae por algn motivo (prdida de conectividad con el servidor, corte de
energa, error en el procesamiento del medio de pago o producto defectuoso, etc), el
sistema debe retomar el proceso inmediatamente despus del ltimo paso realizado.
Solo se aceptan pagos con efectivo, cheques y tarjetas bancarias.
El cajero debe identificarse siempre al principio de su jornada, de modo que podamos
llevar control de las ventas que realiz.
Se estila que la tabla de funciones y de atributos se unan en una sola.
41

De esta manera, se puede definir un documento con la informacin de especificacin general del
sistema y sus funciones de la siguiente forma:
Nombre del Sistema:
Panorama:
Clientes:
Metas:
# Ref:
Funcin:
Descripcin:
Categora:
Atributo
# Ref:
Funcin:
Descripcin:
Categora:
Atributo
Ingreso de Cdigos
Recuperacin de la Venta
Sistema Punto de Venta (SPDV)

D&S a travs de distintos formatos y que agrupa supermercados como Express de
Lder, Hiper Lder y Ekono.
Los cajeros, rea de finanzas, sistema de inventario y SecurePay
Crear un sistema de terminal para el punto de venta que se utilizar en las ventas
del supermercado de manera de:
Entregar mayor automatizacin del pago en las cajas registradoras
Dar soporte a los servicios ms rpido, ms baratos y mejores y a los

procesos de negocio
R1.1
Identificacin del Cajero
El cajero debe identificarse siempre al principio de su jornada, de modo que
podamos llevar control de las ventas que realiz.
Evidente
Categora
R2.1
Registrar los Productos de la Venta
La caja debe permitir que el cajero vaya registrando todos los productos que el
cliente traiga en su carro o canasto y asociarlos a la misma venta.
Evidente
Categora
Debe ser manual o por pistola lectora de cdigos de
Usabilidad
barras.
Implementacin
Debe permitir recuperar una venta desde el punto
Fiabilidad
anterior a la cada.
# Ref:
Funcin:
Descripcin:
R2.2
Registrar el Pago de la Venta
La caja debe permitir que el cajero ingrese el pago de la venta con cualquier
medio de pago habilitado.
Categora:
Evidente
Atributo
Categora
Medios de Pago Habilitados Solo se aceptan pagos con efectivo, cheque y tarjetas
Implementacin
bancarias.
ILUSTRACIN 10. PLANTILLA DE ESPECIFICACIN DE FUNCIONES PARA EL SPDV

Para diferenciar y entregar ms elementos que nos hagan entender el modelo de casos de uso,
veamos la definicin que ya planteamos en la unidad de conceptos y metodologas vista
anteriormente:
42

EL MODELO DE CASOS DE USO ES, BSICAMENTE, EL CONJUNTO DE

TODOS LOS CASOS DE USO, MODELO DE LA FUNCIONALIDAD Y DEL
ENTORNO DEL SISTEMA.
Con esto, nos referimos en que el Modelo de Casos de Uso, definido en la disciplina de
Requerimientos del UP nos habla sobre las funcionalidades del sistema y cmo se comporta con el
entorno, bajo los distintos escenarios en los cuales se desenvuelve.
Es preciso destacar que el modelo de casos de uso siempre usa una visin externa, es decir la del
usuario que utiliza el sistema (usuario final).
CONCEPTOS BSICOS
Pero para entender cmo utilizar y construir los Modelos de Casos de Uso es importante
comprender algunos conceptos relacionados con el tema.
ACTOR
De manera informal, podemos decir que:
ACTORES
SON
ELEMENTOS
QUE
POSEEN
COMPORTAMIENTO
PROPIO, COMO UNA PERSONA, UN SISTEMA INFORMATIZADO U

ORGANIZACIN QUE INTERACTA CON NUESTRO SISTEMA A
MODELAR.
Antes de identificar los casos de uso que componen el modelo, se identifican los actores que van a
participar en este modelo. Pronto veremos cmo los representamos en UML, por ahora nos
quedamos solo con la definicin.
ESCENARIO
Al igual que lo que hicimos con el actor, podemos decir que:
ESCENARIO ES UNA SECUENCIA DE ACCIONES ENTRE LOS ACTORES Y
EL SISTEMA EN ESTUDIO.
Con esto nos referimos a una historia particular de uso del sistema, es decir, alguna serie de
eventos que pueden ocurrir en una ejecucin de nuestra aplicacin que estamos diseando. A
esto tambin se le conoce como Instancia de Caso de Uso.
CASO DE USO
Finalmente, y al parecer el concepto ms esperado, con el que decimos que:
43

UN
CASO
DE
USO
ES
UNA
COLECCIN
DE
ESCENARIOS
RELACIONADOS, QUE DESCRIBE A LOS ACTORES UTILIZANDO EL

SISTEMA PARA UN OBJETIVO ESPECFICO.
Al ver esta definicin podemos decir que el Caso de Uso define las relaciones y acciones de los
actores hacia el sistema, bajo el prisma de un objetivo especfico. En particular, podemos decir que
los Casos de Uso en realidad son requisitos, ante todo son requisitos funcionales (como la F de
los requisitos FURPS+) o de comportamiento. Sin embargo, en algunos casos, los otros
requerimientos aparecer como Casos de Uso tambin, pero ya es poco comn. Lo general es que
sean funcionales.
RESPONSABILIDAD
Lo primero es saber qu es una responsabilidad:
RESPONSABILIDAD ES UNA METFORA CON LA CUAL SE ESPECIFICA
LOS REQUISITOS FUNCIONALES.
Estas metforas se refieren a indicar el qu debe hacer el sistema (anlisis) y no el cmo lo

debe hacer (diseo). A veces ocurre que los analistas tratan de especificar los pasos a seguir en el
caso de uso como si fuese un pseudocdigo o programa, pero eso se debe dejar al diseo.
FORMALIDAD
Los casos de uso definen sus responsabilidades con distintos tipos de formalidad. Estos tipos son:
Breve: Es un resumen conciso de un solo prrafo, normalmente indicando cul es el

escenario principal con xito.
Informal: Es un formato de mltiples prrafos que comprenden varios escenarios, o uno

solo que toma la idea general de esos escenarios.
Completo: Es donde se escriben todos los pasos y variaciones, con secciones de apoyo
como precondiciones y garantas de xito de los escenarios presentados.
Aqu podemos ver que las formas de especificar los casos de uso generalmente varan, y tambin
dependen de la situacin en la que se est trabajando. As en algunos casos nos conviene usar una
formalidad breve, en cambio en otras es una formalidad completa.
ARTEFACTOS DEL MODELO

De la misma forma, encontraremos que el modelo de casos de uso se puede construir a travs de
2 artefactos del lenguaje:
Especificacin de Casos de Uso: Documento que permite describir en detalle y lenguaje

natural las particularidades de cada caso de uso identificado.
44

Diagramas de Casos de Uso: Diagrama que muestra el contexto de todos los casos de uso
del sistema en relacin a los actores del mismo.
PROCESO DE DESARROLLO DEL MODELO

Para crear los entregables del modelo (es decir, los artefactos de ste), se necesita proceder a
travs del uso de tcnicas o recetas. Veamos la tcnica de identificacin y especificacin de los
casos de uso:
IDENTIFICACIN DE CASOS DE USO
Adems de saber cmo se identifican los casos de uso, es importante entender que debemos
mirar el entorno para ver la relacin que tiene el sistema con los actores y sus objetivos. De esta
forma, se describe una receta que nos ayudar a encontrar estos elementos claves en la
definicin de los casos de uso:
PASO 1: ELEGIR EL LMITE DEL SISTEMA
Al comenzar a definir los casos de uso, es importante saber hasta dnde llega el sistema, cul es el
alcance de ste. El problema es que no siempre es fcil determinar el lmite, porque se confunden
responsabilidades del sistema con las funcionalidades desde el punto de vista del usuario.
Es por eso que siempre es ms fcil determinar primero lo que est fuera (actores externos y de
apoyo). Una vez que estos agentes externos al sistema estn claramente identificados, descubrir
los lmites de ste se torna un poco ms sencillo.
Por ejemplo, existe alguna responsabilidad del sistema de caja de supermercado de autorizar y
gestionar los pagos con tarjetas de crdito?, la respuesta es no, porque ese servicio lo da
Transbank, lo que dejara tanto ese objetivo como el actor fuera de nuestro sistema en anlisis.
PASO 2: IDENTIFICAR LOS ACTORES PRINCIPALES Y DE APOYO
Luego de tener claro el lmite del sistema, debemos identificar los actores del modelo. Estos
actores se dividen en tres grupos:
Actores Principales: Son aquellos actores o personas externas al sistema que requieren un
servicio para cumplir sus objetivos especficos. Por ejemplo: El Cajero es un actor que
desea procesar una venta.
Actores de Apoyo: Son actores de segunda categora que prestan servicios de apoyo al
sistema, como otros sistemas (Sistema de Inventario, como por ejemplo para el sistema de
venta).
Actores Pasivos: Son actores que estn interesados en el comportamiento del caso de uso,
pero que no interacta con l. Por ejemplo: SII es un actor pasivo.
En la mayora de los casos, los actores principales son los que nos importaran, ya que ellos
interactan con el sistema a travs de los casos de uso para satisfacer sus objetivos.
PASO 3: IDENTIFICAR LOS OBJETIVOS DE LOS ACTORES
45

Con los actores, es fcil saber cul es su objetivo para utilizar el sistema, ya que ellos se
desprenden de la formalizacin de los requerimientos anteriormente vista. Es por eso, que se
recomienda que cuando se genere la lista de actores, inmediatamente poner al costado el o los
objetivos que tiene.
Una forma es en una tabla como la siguiente:
Actor
...
Objetivo
...
ILUSTRACIN 11. TABLA DE IDENTIFICACIN DE ACTORES Y OBJETIVOS
Los objetivos pueden ser ms de uno, ya que los actores tienen ms de una esperanza del sistema.
De esta forma iremos desarrollando el modelo.
Otra forma de encontrar los objetivos es a travs de eventos externos, los cuales son gatillados
como respuesta a estos objetivos. Por ejemplo, un evento externo es ingresar el producto a la lista
de compras, este evento lo realiza el Cajero cuando pasa el producto por el lector de barras y
corresponden a un grupo de eventos que llamamos procesar una venta. Este ltimo
corresponde a uno de los objetivos del Cajero.
PASO 4: DEFINIR LOS CASOS DE USO
Despus de este proceso, lo que se requiere es identificar cules son los casos de uso del
problema. Este paso puede durar desde minutos (solo descubrir cules son) hasta das (especificar
el detalle de ellos).
Generalmente definiremos los casos de uso por objetivo de cada actor principal. Por ejemplo, si el
objetivo es procesar una venta, entonces el caso de uso asociado ser Procesar Venta. Fjate
que el nombre comienza por un verbo en infinitivo, lo que indica que es una accin del sistema
que satisface el objetivo del actor.
Existen 2 formas de describir los casos de uso dependiendo del detalle y la audiencia que van a
tener. As, los casos de uso sern los siguientes:
CASO DE USO DE ALTO NIVEL
El CU de Alto Nivel describe de manera muy general el objetivo del Caso de Uso y alguna
informacin adicional como los actores y el tipo. Su objetivo es solo mostrar, desde un punto de
vista simple, la funcionalidad sin entrar en el detalle.
La notacin propuesta para este tipo de especificacin es:
Caso de Uso:
Actores:
Tipo:
Descripcin:
ILUSTRACIN
<Nombre de Caso de Uso>

<Lista de agentes externos indicando quin inicia el CU>
<Primario, Secundario u Opcional>
<Descripcin general del proceso que est resolviendo el CU>
12. DOCUMENTO DE ESPECIFICACIN DE CASO DE USO DE ALTO NIVEL
En el caso de los tipos de CU, estos son:
46

Primario: Representan los procesos comunes ms importantes del sistema.
Secundario: Representan los procesos menores o menos recurrentes (raros).
Opcional: Representan los procesos que pueden no ocurrir.
CASO DE USO EXPANDIDO
El CU Expandido describe en detalle, paso a paso, cmo se cumple el objetivo de este CU. Esta
forma de describir el CU no se usa para todos los casos, sino que solo se utiliza para aquellos que
son los principales o aquellos que aportan mayor complejidad al problema.
La notacin propuesta para este tipo de especificacin es:
Caso de Uso:
Actores:
Propsito:
Resumen:
Tipo:
Ref. Cruzadas:
<Nombre del Caso de Uso>

<Lista de agentes externos indicando quin inicia el CU>
<Intencin del CU>
<Descripcin general del CU, que es la misma que se usa en Alto Nivel>
<Primario, Secundario u Opcional> y <Esencial o Real>
<CU y funciones relacionadas>
Curso Normal
<Detalle de la conversacin interactiva entre los actores y el sistema>
Cursos Alternos
<Detalle de la conversacin interactiva entre los actores y el sistema>
ILUSTRACIN 13. DOCUMENTO DE ESPECIFICACIN DE CASO DE USO EXPANDIDA
En el caso de los tipos de CU, adems de los ya vistos en el CU de Alto Nivel, son:
Real: Concretos y que utilizan la tecnologa real con la cual se desarrolla el CU.
Esencial: Tericos y que no poseen detalles de la tecnologa e implementacin.
Adems, la forma de describir los cursos, tanto normal como alternos, debe realizarse en un
formato especfico de modo de que se explique cmo se resuelve el CU.
En el caso del curso normal de eventos, se describe a 2 columnas: Una para las acciones o
interacciones del actor, y la otra para las respuestas del sistema:
1.
2.
4.
Accin del Actor

Accin del actor
Accin del actor
Accin del actor
Respuesta del Sistema

3.
Respuesta del Sistema
Por otro lado, los cursos alternos deben hacer referencia al paso del curso normal de eventos en
donde ocurre el evento y la descripcin de ste.
Paso 3.
1.
2.
3.
Accin alterna
Accin alterna
47


Para complementar el modelo se utiliza una sola la visin general del sistema, actores y la relacin
o interaccin que tienen stos con los Casos de Uso. Esto lo podemos hacer mediante el Diagrama
de Casos de Uso, el que nos permite definir el detalle de todos los CU del Sistema como si fueran
un conjunto de cajas negras. De esta forma, la visin general de las especificaciones, quedan en
una sola mirada para el lector.
La notacin del diagrama es la siguiente:
ILUSTRACIN 14. NOTACIN DE LOS DIAGRAMAS DE CASOS DE USO
Algunas consideraciones respecto a la notacin:
La Asociacin puede utilizar multiplicidad en su definicin (1 a *), en donde es posible

indicar en cada extremo si se relacionan 1 a 1 o 1 a muchos casos de uso para el mismo
actor.
Respecto a las relaciones especficas entre CU, podemos encontrar las siguientes (segunda
columna):
o Inclusin: Define un subcaso, es decir, cuando el CU referenciado est dentro de
el caso general.
o Extensin: Define un caso que, adems de realizar todas las especificaciones del
caso original, define algunos pasos adicionales. Es equivalente a utilizar
especializacin.
48

o Equivalencia: Define cuando los casos de uso poseen los mismos flujos, pero son
realizados por actores diferentes.
o De Requisito: Define cuando un caso de uso debe ser completado antes de que
contine el referenciado.
o Semejanza: Define cuando los casos de uso son similares (en objetivos), pero
poseen actividades diferentes.
Por ejemplo, si continuamos con lo visto sobre el problema del SPDV, podemos disear y definir
un modelo de casos de uso claro con los artefactos mencionados. Vamos paso a paso tal como nos
ensea esta clase:
Nombre del Sistema:
Lmites:
Actores y Objetivos
Actor
Cliente
Cajero
SecurePay
Sistema de Inventario
Sistema de Finanzas
Sistema Punto de Venta (SPDV)
Estados financieros de las ventas.
Administracin de recursos humanos.
Devoluciones y cambios de productos.
Administracin de los medios de pago.
Administracin de inventario.
Objetivo
Realizar una compra de los productos seleccionados.
Pagar el monto de la compra.
Identificarse en el terminal.
Registrar los productos de la venta.
Obtener el valor total de la venta.
Registrar el pago de la venta.
Imprimir el recibo de la venta.
Recibir solicitudes de validacin de cheques.
Recibir transacciones con tarjetas de crdito y dbito.
Recibir notificaciones de los productos egresados de la tienda.
Recibir la informacin de cada venta realizada en un terminal de la tienda.
Especificacin de Casos de Uso

Caso de Uso:
CU1: Autenticar en el Sistema
Actores:
Cajero (I), Cliente
Tipo:
Primario
Descripcin:
Le permite al cajero ingresar su identificacin (usuario y contrasea) de manera
de tener control de quin est realizando una venta.
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU2: Registrar Productos de una Venta

Cajero (I), Cliente, Sistema de Inventario
Primario
Le permite al cajero ingresar cada producto a travs de los cdigos de barra a la
venta actual.
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU3: Validar Medio de Pago

Cajero (I), Cliente, SecurePay
Primario
Le permte al cajero validar en lnea aquellos medios de pago vlidos (cheque,
tarjeta de crdito y dbito).
ILUSTRACIN 15. PLANTILLA DE ESPECIFICACIN DE CASOS DE USO Y GLOSARIO
49

En esta plantilla est el problema del SPDV parcialmente especificado (falta trabajo). De todas
maneras da una idea de cmo se vera la especificacin del problema despus del proceso de
anlisis.
Ahora bien, revisemos cmo se vera esto en un Diagrama de Casos de Uso:
System
CU1: Autenticar en el Sistema
Cajero

SecurePay
ILUSTRACIN 16. DIAGRAMA DE CASOS DE USO DEL SPDV
GLOSARIO
El glosario tiene por objetivo poner en comn entre los diferentes lectores del A/DOO la
terminologa a utilizar, tanto del negocio como de la parte tcnica. Este artefacto tiene la
importancia que, gracias a su informacin, podemos comenzar a definir un diccionario de datos
antes de disear componentes.
No existe una tcnica para encontrar el glosario, pero es recomendable de comenzar a
especificarlo despus de descritas las funciones del sistema o incluso cuando se estn
especificando los casos de uso, ya que van a ir saliendo en forma natural los trminos no
reconocidos por el equipo.
Una estructura bsica (plantilla) se sugiere a continuacin para el glosario:
Trmino
Definicin
ILUSTRACIN 17. DOCUMENTO DEL GLOSARIO
50

Por ejemplo, aqu est parte del glosario al problema que hemos visto durante las secciones
anteriores.
Glosario
Trmino
Punto de Venta
Caja
Medio de Pago
...
Definicin
Lugar del supermercado donde se deben registrar las ventas del local.
Dispositivo fsico que le permite al cajero ingresar datos de la venta.
Forma equivalente a dinero que sirve para realizar pagos sin tener efectivo.
...
ILUSTRACIN 18. GLOSARIO PARA EL PROBLEMA DEL SPDV
MODELO DE DOMINIO
Un paso importante en el anlisis y diseo OO es el modelo de dominio, el cual se utiliza como
inspiracin para el diseo y como entrada para otros artefactos de UP como del diagrama de
secuencia y los contratos. De esta forma, lo definimos como:
EL MODELO DE NEGOCIO, MODELO DE DOMINIO O MODELO
CONCEPTUAL ES UN CONJUNTO DE ARTEFACTOS QUE DEFINEN EL
DOMINIO DE ANLISIS A TRAVS DEL PROCEO Y DE LAS CLASES
CONCEPTUALES, DESCRIBIENDO SUS ASOCIACIONES Y ATRIBUTOS.
An cuando los modelos de dominio son propios de la disciplina de modelado del negocio y no del
anlisis como tal, son requisito del diseo y de otros artefactos del mismo anlisis, es por esa
razn que es importante estudiarlos. Adems, salta a la vista que las disciplinas de UP se van
entrelazando entre s dependiendo de lo que se va haciendo en el anlisis y diseo, como ahora,
que a pesar de que estamos analizando los requisitos funcionales y casos de uso, necesitamos
definir el modelo de dominio para poder continuar.
CONCEPTOS BSICOS
A continuacin algunos conceptos importantes que son necesarios de entender para este modelo.
DOMINIO
Se dice que:
EL DOMINIO O NEGOCIO ES EL ESPACIO EN EL CUAL SE EXTIENDE EL
PROBLEMA PRESENTADO.
Esta sencilla definicin nos permite enmarcar nuestro problema dentro de un ambiente
totalmente controlado. Por ejemplo, si hablamos del dominio sobre el problema del Punto de
Venta en un Supermercado, el dominio se enmarca solo en eso, lo que corresponde al entorno al
punto de venta, no ms ni menos, de manera de que todo lo que definamos tendr que ver con
ese contexto.
51

CLASES CONCEPTUALES
La base del modelo de dominio est primeramente en las clases conceptuales. Es por ello que se
define este concepto como:
UNA CLASE CONCEPTUAL ES UNA IDEA, COSA U OBJETO DEL
NEGOCIO DE ANLISIS Y QUE DEFINEN PARTE DE L A TRAVS DE SU
SMBOLO, INTENSIN Y EXTENSIN.
Como podemos ver, en esta definicin estamos definiendo parte de la notacin UML de las clases
conceptuales a travs de los elementos que la componen. Estos elementos son:
Smbolo: palabras o imgenes que representan una clase conceptual.
Intensin: la definicin de la clase conceptual.
Extensin: el conjunto de ejemplos a los que se aplica la clase conceptual.
Por ejemplo, si consideramos el evento de transaccin de compra de producto como una clase
conceptual, desde el punto de vista del sistema podramos bautizarlo como Venta. Desde el punto
de vista prctico en la construccin del modelo del dominio, solo el smbolo y la intensin suelen
tener la mayor importancia.
Es importante tener clara la diferencia entre estas clases y las clases de componentes de
software que veremos en el diseo, ya que pueden confundirnos, adems de que los modelos de
dominio no sirven en la implementacin.
De esta manera, debemos tener claro que un modelo de dominio no debe contener:
Artefactos de Software, como bases de datos, ventanas, a menos que en el dominio se
estn modelando componentes de software.
Responsabilidades o mtodos de las clases conceptuales, ya que no deben representar las
funcionalidades que tienen.
Una diferencia importante cuando realizamos el anlisis desde el punto de vista de objetos, en vez
de un proceso estructurado, es que centramos el modelo en los objetos y no en las funciones.
PROCESO
Una segunda derivada de este modelo es el anlisis del dominio a travs del proceso que se ve
impactado por el problema planteado, y para ello definiremos que:
UN PROCESO ES CONJUNTO DE ACTIVIDADES O EVENTOS QUE DEBEN
OCURRIR DENTRO DEL DOMINIO PARA SATISFACER EL OBJETIVO O
FIN DE LOS USUARIOS DE STE.
52

A pesar de que esta definicin es ms especfica que la que tiene la palabra original proceso es
porque la estamos especificando dentro del concepto del modelo. De esta manera,
consideraremos al proceso como una vista dinmica del dominio que estamos analizando, y que
ser necesario modelar, de manera de tener la visin completa de qu estamos afectando con
nuestro sistema.

Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos
artefactos son:
Diagrama de Actividades: Diagrama que muestra cmo es el proceso de negocio que se

est interviniendo con el sistema que est en anlisis.
Diagrama de Clases Conceptuales: Diagrama que muestra la relacin de los conceptos

importantes del domino tienen en forma esttica dentro del proceso intervenido por el
sistema en anlisis.
Veamos ahora cmo se desarrollan estos artefactos.

travs del uso de tcnicas o recetas. Veamos la tcnica de identificacin y descripcin del proceso
y de las clases conceptuales:
ESPECIFICACIN DEL PROCESO DE NEGOCIO
La sintaxis de los diagramas de actividad es muy sencilla ya que se asemeja a lo que en otras
metodologas o notaciones se conocen como diagramas de flujo, pero con la salvedad que la
orientacin de estos ltimos se refiere al flujo de datos y los de actividad su centro es el flujo
funcional o de actividades del proceso.
53

Sintaxis Diagrama de Actividad

Accin
Accin
Decisin / Merge
Nodo Inicial
Fork
Nodo Final de Flujo
Join
Flujo de Control
<sin accin enviar>
Nodo Conector
Objeto
Accin
<sin accin recibir>
Envo de Seal
Receptor de Seal
Objeto
Seal de Tiempo
Pines
Excepcin
Precondicin
Nodo Final de Actividad
Info
<<precondicion>>
(condicion)
Calle
<<postcondicion>>
(condicion)
Calle (Swimlane)
Postcondicin
ILUSTRACIN 19.NOTACIN DE LOS DIAGRAMAS DE ACTIVIDADES
Su utilizacin ser un poco ms especfica que respecto a los casos de uso ya identificados. Es
importante notar que, cuando definimos los CU es posible que hayamos encontrado algunos casos
en donde tengamos inclusin, dependencia o generalizacin, pero que desde el punto de vista del
EBP esto no es relevante.
Por ejemplo, en el caso de la caja de supermercado, podemos haber encontrado el siguiente
diagrama de casos de uso:
System

Cajero
SecurePay
ILUSTRACIN 20. DIAGRAMA DE CASOS DE USO DEL SPDV
54

Podemos ver que CU2: Registrar Productos en la Venta no tiene conexin con el CU3: Validar
Medio de Pago ya que la importancia est en focalizar en que sean casos reusables. Sin embargo,
desde el punto de vista del proceso solo es necesario definir el Proceso de Venta, la cual si
incorpora la validacin y proceso pago.
De esta manera, cuando queremos confeccionar el diagrama de actividad del proceso de venta,
nos centraremos en todos los pasos necesarios para realizar una venta especfica:
Iniciar Venta
Ingresar Producto
Venta
[cod valido]
Obtener Informacin
[cod no valido]
Registrar Producto
Rechazar Cdigo
[hay mas productos]
[no hay mas productos]
Calcular Total
[cliente paga]
Registrar Pago
Pago
Imprimir Comprobante
ILUSTRACIN 21. DIAGRAMA DE ACTIVIDADES PARA EL SPDV
Es importante identificar el proceso para el conocimiento del dominio, de manera de que el

diagrama de actividades entregue mayor informacin al problema.
IDENTIFICACIN DE CLASES CONCEPTUALES
Antes de comenzar a descubrir las clases conceptuales, es importante saber que debemos
identificar las clases de los mismos casos de uso ya especificados en el modelo de casos de uso. En
cada iteracin se va definiendo cul o cules son los escenarios a estudiar y referente a ellos se
comienza a definir el modelo de dominio.
55

PASO 1. IDENTIFICAR LAS CLASES CONCEPTUALES

No existe la forma correcta de obtener las clases conceptuales, sino ms bien existen un grupo de
recomendaciones al respecto que nos permiten utilizar las herramientas entregadas por el negocio
para ste proceso prctico.
La literatura menciona dos formas de obtener las clases conceptuales: por clasificacin en
categoras de clases y por identificacin de frases nominales en las especificaciones de casos de
uso. Veamos cada una de estas formas complementndolas con algunos ejemplos:
MTODO 1: IDENTIFICACIN POR CLASIFICACIN DE CLASES CONCEPTUALES
La primera tcnica postula la utilizacin de una lista de categoras de clases conceptuales. Esta lista
comprende un conjunto de clases candidatas a ser conceptuales, acompaadas de ejemplos
tpicos para esas clases, dentro de dominios similares al que estamos analizando.
Estas categoras son:
Objetos tangibles o fsicos: Todos los objetos o elementos fsicos que participan
directamente en el dominio.
Especificaciones, diseos o descripciones de las cosas: Caractersticas o descripciones que
sean de vital importancia para el dominio.
Lugares: Espacios fsicos en donde el dominio toma sentido.
Lneas de la transaccin: Entradas necesarias para la ejecucin del dominio.
Roles de las personas: Roles que puede tomar la gente que participa en el dominio.
Contenedores de otras cosas: Elementos fsicos que sean agrupadores de otros
elementos.
Cosas en un contenedor: Objetos que pueden ser contenidos en un contenedor.
Otros sistemas externos: Sistemas que estn fuera del dominio pero que se requieren
para l.
Conceptos abstractos: Conceptualizaciones u objetos no fsicos que representan un valor
agregado al dominio.
Organizaciones: Secciones y organizaciones que participen en el dominio.
Hechos: Interacciones o eventos que entregan un valor o participan del dominio.
Procesos: Serie de acciones que sean parte del dominio de anlisis.
Reglas y polticas: Restricciones o intereses que puedan ser relevantes en algn proceso.
Catlogos: Contenedores lgicos de informacin.
56

Registro de finanzas, trabajo, contratos, asuntos legales: Elementos de tipo legal o de

validez tributaria.
Instrumentos y servicios financieros: Elementos de importancia que tengan que ver con
las finanzas.
Manuales, documentos, artculos de referencia, libros: Documentacin relacionada con el
dominio.
Por ejemplo, si utilizamos el listado de categoras habituales para el dominio de la venta de un
supermercado, podemos encontrar algunos candidatos para cada categora, los cuales los
ubicaremos en la siguiente tabla:
Categora de Clase Conceptual
Objetos tangibles o fsicos
Ejemplos
Registro
Caja
Producto
Boleta
Especificaciones, diseos o descripciones de las cosas
NombreDelProducto
Lugares
Tienda
Departamento
Lneas de la transaccin
LneaDeVenta
Roles de la gente
Cajero
Supervisor
Cliente
Contenedores de otras cosas
Tienda
CarroDeCompras
Cosas en un contenedor
Producto
Otros sistemas externos
SistemaPagoTransbank
SistemaInventario
Conceptos abstractos
ColaDeClientes
Organizaciones
DepartamentoDePersonal
ProveedorDeProductos
Hechos
Venta
Pago
Empaque
Procesos
Venta
ImpresinDeBoleta
EliminacinDeProducto
Reglas y polticas
ComisionesPorVenta
Catlogos
N/A
Registro de finanzas, trabajo, contratos, asuntos legales
Boleta
Factura
ContratoDeEmpleo
SolicitudDeReposicin
Instrumentos y servicios financieros
Stock
Manuales, documentos, artculos de referencia, libros
ListaDePrecios
CatastroDeCajeros
ILUSTRACIN 22.TABLA DE IDENTIFICACIN DE CLASES CONCEPTUALES SEGN CATEGORAS
Como podemos ver en el ejemplo, tenemos muchos candidatos a ser clases del dominio, sin
embargo, tal como dice su definicin, ellos son solo posibles clases conceptuales que debemos
determinar su validez dentro del dominio de anlisis.
57

MTODO 2. IDENTIFICACIN POR FRASES NOMINALES EN LAS ESPECIFICACIONES
Otra tcnica es identificar candidatas a clases conceptuales desde el escenario, utilizando las
frases nominales de ella. Esto se realiza haciendo un anlisis lingstico de las especificaciones de
los casos de uso del sistema en anlisis.
Por ejemplo, si tomamos el escenario principal de xito del caso de uso Procesar Venta del
ejemplo de la caja del supermercado, tenemos el siguiente escenario:
1.
El Cliente llega a la caja con los productos.
2.
El Cajero comienza una nueva venta en el Sistema.
3.
El Cajero ingresa el producto al Sistema.
4.
El Sistema registra el producto en la lnea de venta indicando el precio y la suma parcial.
Se repiten los pasos 3 y 4 mientras existan productos por ingresar a la venta.

5.
El Cajero solicita el total de la venta al Sistema.
6.
El Sistema presenta el valor total de la venta.
7.
El Cajero le dice al Cliente el total de la venta para que pague.
8.
El Cliente paga al Cajero.
9.
El Cajero ingresa el pago en el Sistema.
10. El Sistema registra la venta en el Sistema de Contabilidad, y la informacin de los productos vendidos en el
Sistema de Inventario.
11. El Sistema emite la boleta/recibo y cierra la venta.
12. El Cajero entrega el recibo al Cliente.
13. El Cliente se retira con el recibo y los productos comprados.
ILUSTRACIN 23.ANLISIS DE CLASES CONCEPTUALES POR FRASES NOMINALES
En este caso solo tomamos el escenario principal de xito a modo de ejemplo, sin embargo es
importante tomar tambin las extensiones del caso de uso, ya que pueden ser fuente de nuevas
clases conceptuales y que servirn en el diseo.
Ntese que hemos subrayado conceptos que despus pueden convertirse en clases conceptuales.
Sin embargo, dependiendo del lenguaje se puede llegar a conceptos diferentes para representar
clases conceptuales equivalentes.
Es por eso que la recomendacin que realizan algunos autores al respecto es que se mezcle esta
tcnica con la anterior de lista de categoras.
OTRAS RECOMENDACIONES PARA REFINAR EL MODELO
Un grupo de recomendaciones para la identificacin de las clases conceptuales se puede enumerar

de la siguiente forma:
Utilice siempre los nombres existentes en el dominio en cuestin. Trate de no usar
conceptos que no sean parte del dominio de anlisis, ya que estos pueden traer consigo
confusin desde el punto de vista conceptual.
58

Excluya siempre las caractersticas y clases conceptuales que sean consideradas

irrelevantes para el negocio de anlisis.
No incluya conceptos o atributos que sean irreales en el domino. Esto quiere decir, que es
importante excluir todo aquellos conceptos que no existan realmente en el domino.
Utilice el concepto de informe solo cuando ste sea un elemento que no redunde en la
informacin entregada por las otras clases conceptuales. En muchos casos, el reporte o
informe (como el recibo) en realidad son un medio de informacin obtenida desde otras
clases conceptuales, lo que llevara a dejarlo fuera del modelo.
Cuando descubra una candidata a clase conceptual en donde posea una caracterstica que
sea un nmero o un nombre que identifica otro concepto, es probable de que en realidad
no sea una clase conceptual sino que un atributo.
Utilice clases conceptuales de especificacin de objetos para mantener la informacin en
la memoria del sistema. Estas clases son tiles considerando siempre que todos en el
negocio tienen amnesia, de manera que esas especificaciones (como el detalle de un
objeto particular) queden como parte de la memoria sistmica del negocio, reduciendo as
la informacin duplicada.
Estas recomendaciones no son nada ms que una gua para ayudar al proceso de identificacin de
las clases conceptuales.
PASO 2. IDENTIFICAR ASOCIACIONES ENTRE CLASES CONCEPTUALES
Las asociaciones, segn UML, son la relacin semntica entre dos o ms clasificadores que implica
conexiones entre sus instancias.
Tal como se detall en la sintaxis de los modelos de dominio, la asociacin debe ir acompaada de
un nombre que define qu tipo de asociacin es. Este nombre indica cul es la relacin entre las
instancias asociadas de alguna forma. Estos nombres son escritos separados por un guin y no por
espacios, por ejemplo, para indicar la asociacin entre la caja y la venta, podemos decir que la
caja registra la actual venta, lo que se traducira en la asociacin registra-la-actual.
Adems del nombre, en algunos casos se puede especificar con una cabeza de flecha la
navegabilidad de la asociacin, es decir, en qu sentido se lee dicha asociacin. Por ejemplo:
contiene
Venta
LineaDeVenta
1..*
ILUSTRACIN 24.EJEMPLO DE ASOCIACIN DE CLASES CONCEPTUALES
Este ltimo detalle generalmente se excluye, porque basta mirar el modelo para darse cuenta de
la navegabilidad del mismo.
59

Por ltimo, en los extremos de las asociaciones van lo que se conoce como Roles. Estos elementos
definen cul es la relacin que se tiene con dicho objeto, por ejemplo, nmero de elementos
(multiplicidad) como veremos ms adelante.
MULTIPLICIDAD DE ASOCIACIONES
Cuando especificamos la multiplicidad debemos indicar en cada lado de la asociacin la cantidad

de objetos con las cuales se relaciona. Estas multiplicidades pueden ser:
A
1 objeto de A se relaciona con 1 y solo 1 objeto de B. Ambos objetos

deben existir (obligatorio)
1..*
1 objeto de A se relaciona con 1 o ms objetos de B. En este caso el

mnimo de objetos de B debe ser 1 (obligatorio).
0..1
1 objeto de A se puede relacionar o no con 1 objeto de B. En este

caso, si no existe el objeto B, A puede seguir existiendo (optativo).
1 objeto de A se puede relacionar o no con objetos de B. En este caso,

no existe un mnimo ni un lmite de objetos de B (optativo).
ILUSTRACIN 25.TABLA DE CLASIFICACIN DE MULTIPLICIDAD
Algunos diagramas requieren multiplicidades ms especficas. En ese caso, el indicador de

multiplicidad es el nmero exacto de objetos relacionados (o en su defecto, los nmeros exactos,
si pueden ser ms de uno). Por ejemplo, A almacena 3 objetos de B en forma obligatoria, por lo
que en la asociacin pondremos un 3 al lado de B.
CRITERIO PARA DEFINIR LAS ASOCIACIONES
La definicin de las asociaciones corresponde a una labor muy delicada, ya que en un anlisis
podra aparecer que todo es relevante para todo, o que todas las clases poseen alguna relacin
con las otras. Es por eso que al momento de definir las asociaciones, es importante definir:
Asociaciones en donde es necesario conservar el conocimiento de la relacin por algn
tiempo.
Asociaciones comunes que son de alta prioridad (parte-de, contenida-en, registra-a).
Otras asociaciones comunes que cumplan con las especificaciones del dominio en anlisis.
No es recomendable poner muchas asociaciones o sobrecargar el modelo con asociaciones
redundantes, porque el beneficio es realmente marginal. Por otro lado, es ms importante definir
las clases conceptuales que las asociaciones (adems, nos daremos cuenta que saltan a la vista las
asociaciones a partir de las clases conceptuales).
El listado de las asociaciones ms comunes es:
A es una parte de B
A est contenido en B
60

A es una descripcin de B
A es una lnea de una transaccin o informe de B
A se conoce/registra/recoge/informa/captura en B
A es miembro de B
A es una subunidad organizativa de B
A utiliza/gestiona B
A se comunica con B
A est relacionado con una transaccin B
A es una transaccin relacionada con otra transaccin B
A est al lado de B
A es propiedad de B
A es un evento relacionado con B
PASO 3. AADIR ATRIBUTOS
Los atributos, en general, son valores de datos lgicos de los objetos. En el modelo de dominio, los
atributos se presentan solo con el nombre, y en algunos casos particulares, podran presentarse
tambin con sus tipos (pero eso es opcional y es poco usado en la prctica), indicndolo despus
del atributo con :.
Para agregar los atributos, debe especificar aquellos valores que son relevantes para entender el
modelo de dominio. Esto quiere decir, que cuando se estn definiendo los atributos, no ponga
todos los valores que se le vengan a la cabeza, sino que los ms importantes para el problema.
De esta forma, y considerando el ejemplo mencionado de Procesar Venta, podemos identificar los
atributos de las clases conceptuales descritas anteriormente. Estos son:
Tienda
direccin: El recibo requiere la direccin de la sucursal.
Producto
cdigo: El producto debe tener un cdigo que lo hace nico.

nombre: El detalle que describe el producto en pantalla.
precio: El precio se usa para calcular el total de la venta.
Venta
fecha, hora: El recibo mostrar la fecha y la hora de la venta.
LneaDeVenta cantidad: Esta entrada se indica en la venta la cantidad comprada.

Pago
cantidad: Sirve para calcular el cambio, si es que excede el valor total.
Ntese que muchas clases conceptuales no las especificamos aqu, an cuando si las usaremos en
el ejemplo final. Solo hemos descrito aquellas a las que le agregaremos los atributos. Las dems,
no requieren algn atributo en particular.
Para concluir, todas las asociaciones y atributos deben ser agregado al diagrama parcial para
completarlo de manera tal que represente el dominio de anlisis.
61

DIAGRAMA DE CLASES CONCEPTUALES

A diferencia de lo visto en el modelo de casos de uso, en este caso la tcnica o proceso se mezcla
con el diagrama, ya que finalmente no hay artefactos intermedios (excepto la tabla de
identificacin de clases conceptuales por categoras) que puedan agregar valor al modelo. Es por
eso que es recomendable que una vez establecidas las candidatas a clases conceptuales se
comience inmediatamente con el diagrama.
La notacin del diagrama es la siguiente:
Notacin Diagramas de Clases Conceptuales

metaclass
Nombre
-a
Metaclase
Asociacin
1..1
0..*
-a
Nombre
-atrib : byte
Agregacin
Clase
1..1
0..*
-a
Composicin
1
Objeto
0..*
Objeto/Instancia
Herencia/Generalizacin
interface
Interfaz
Interfaz
Implementacin de Interfaz
Interfaz
ILUSTRACIN 26.NOTACIN DE LOS DIAGRAMAS DE CLASES CONCEPTUALES
La notacin UML de estos diagramas es similar a la que se utiliza para los diagramas de clases,
porque en realidad eso son, pero sin definir operaciones y solo enumerando atributos. Sin
embargo, la gran diferencia es que las clases definidas en este diagrama son en realidad conceptos
del dominio y no clases de software. Por esta razn, a estas clases se las llama clases
conceptuales ya que son, en realidad una idea, cosa u objeto que representan en forma abstracta
los elementos que participan en dominio de inters.
De la misma manera como hicimos entonces con el Modelo de Casos de Uso, podemos continuar
el ejemplo con el Diagrama de Actividades. En este caso, este diagrama nos define el proceso de
venta, que comienza desde que el cliente llega a la caja, hasta que se retira de ella con los
productos comprados.
El proceso quedara de la siguiente forma:
62

Iniciar Venta
Ingresar Producto
[cod valido]
Obtener Informacin
[cod no valido]
Registrar Producto
Rechazar Cdigo
[hay mas productos]
[no hay mas productos]
Calcular Total
[cliente paga]
Registrar Pago
Imprimir Comprobante
ILUSTRACIN 27.DIAGRAMA DE ACTIVIDADES DEL SPDV
As mismo, el diagrama de clases conceptuales del problema es el siguiente:

inicia
Cliente
contiene
Venta
0..1
Pago
1 genera
0..*
1
registra
LineaDeVenta
1..*
1
0..*
registra
Producto
Caja
se-valida-en
informa
utiliza
Cajero
1
1..*
1..*
contiene
1
SecurePay
Catalogo
alberga
Tienda
1
1
genera
SistemaDeInventario
1
ILUSTRACIN 28.DIAGRAMA DE CLASES CONCEPTUALES DEL SPDV
63

MODELO DE COMPORTAMIENTO
Segn lo que ya hemos dicho, el modelo de comportamiento lo podemos definir como:
UN CONJUNTO DE ARTEFACTOS QUE PERMITEN IDENTIFICAR EL
COMPORTAMIENTO DEL SISTEMA O PARTES DEL MISMO A TRAVS
DE LOS ESCENARIOS PRESENTADOS EN EL MODELO DE CASOS DE
USO Y EN FUNCIN DE LAS CLASES CONCEPTUALES.
Como podemos reafirmar, la idea ahora es analizar el sistema desde el punto de vista funcional
tomando en cuenta los requerimientos y conceptos del dominio como si fuera una o ms cajas
negras.
CONCEPTOS BSICOS
EVENTO
Diremos que:
UN EVENTO ES UNA INTERACCIN QUE EXISTE ENTRE UN ACTOR
EXTERNO Y EL SISTEMA.
Esta definicin tan sencilla tiene su base en lo que ya hemos definido como mensaje al principio
del curso, pero con un matiz especial: no es una interaccin entre objetos sino que entre un actor
y el sistema.
CONTRATO
Una definicin enciclopdica nos indica que:
UN CONTRATO ES UN ACUERDO DE VOLUNTADES QUE GENERAN
DERECHOS Y OBLIGACIONES.
Bsicamente esta definicin puede ser aplicada directamente al modelamiento de

comportamiento, ya que se refiere a una serie de acciones y restricciones que se deben cumplir.
En el contexto del modelo en s, hablaremos siempre de contratos de las operaciones (lo que
veremos en detalle cuando hablemos del artefacto respectivo).
ESTADO
Podemos decir que:
64

UN ESTADO ES UNA CONFIGURACIN NICA DE INFORMACIN EN

UN PROGRAMA O MQUINA.
Como podemos ver el concepto es bastante amplio, ya que hace referencia a un estado en su
forma genera. Sin embargo, tambin podemos encontrar una definicin ms ad-hoc que dice que
es un conjunto particular de instrucciones las cuales sern ejecutadas en respuesta a la entrada de
la mquina.

artefactos son:
Diagrama de Secuencia: Diagrama que muestra cules son los eventos del sistema a partir
de los escenarios descritos en los casos de uso.
Contratos de las Operaciones: Documentos que describen cada operacin del sistema
(eventos entre el actor principal y el sistema) como si fuera una mquina de estados de
tipo caja negra.
Diagrama de Estados: Diagrama que muestra una visin de mquina de estados para
objetos o procesos del dominio.

travs del uso de tcnicas o recetas. Veamos cada una de ellas en detalle.
DIAGRAMAS DE SECUENCIA DE LOS EVENTOS DE CASOS DE USO
Los Casos de Uso describen cmo interactan los actores externos con el sistema de software que
estamos estudiando. Estas interacciones generalmente gatillan eventos sobre el sistema a travs
de operaciones y alguna respuesta que ste le da.
Con esta motivacin, UML define que:
EL DIAGRAMA DE SECUENCIA DEFINE GRFICAMENTE PARA UN
ESCENARIO ESPECFICO DE UN CASO DE USO LOS EVENTOS QUE
GENERAN LOS ACTORES EXTERNOS, EL ORDEN Y LOS EVENTOS ENTRE
LOS SISTEMAS DE APOYO.
Todos los sistemas se ven como cajas negras, es decir, no entramos a mirar cul es su
implementacin o cmo funcionan, sino que interactuamos directamente con ellos.
65

Pero cmo y cundo hacer un diagrama de secuencia del sistema? La teora dice que el diagrama
debe ser hecho tanto para el escenario de xito como para los escenarios alternativos complejos o
frecuentes (por ejemplo, utilizando los medios de pago en nuestro modelo de caja de
supermercado).
Para hacer estos diagramas, se necesita entender algo de la anatoma de ellos. Es por eso que
definimos la notacin UML de los diagramas a continuacin:
Notacin Diagramas de Secuencia
Mensaje
:Objeto
Objeto (Actor/Sistema)
Mensaje o Interaccin
Mensaje
Lnea de Vida
Autodelegacin
Retorno
Activacin
Mensaje de Retorno
Mensaje
Nota / Restriccin
Mensaje Asncrono
Loop
Loop
[cond1]
[cond]
Ciclo
[cond2]
Flujos Alternos
ILUSTRACIN 29. NOTACIN DE LOS DIAGRAMAS DE SECUENCIA
Como es de esperar, existen tambin mensajes en los cuales se puedan crear nuevos objetos.
Estos mensajes se les dice de Creacin y se interpretan como una flecha a una caja de instancia
nueva (a la misma altura). Es decir, no todas las instancias del sistema se ven a la misma altura
(arriba) sino que algunas aparecen dependiendo se van creando.
: Caja
: Venta
2 : nuevo()
ILUSTRACIN 30. MENSAJE DE CREACIN DE OBJETO
Otra particularidad son los llamados Autodelegacin, las cuales corresponde a una autollamada de
alguna actividad o mensaje que se realiza en el mismo objeto.
66

: Pago
5 : registrarPago()
ILUSTRACIN 31. MENSAJE DE AUTODELEGACIN
A partir de toda esta notacin podemos generar los diagramas de secuencia a cualquier nivel del
proyecto, pensando en un anlisis inicial (como en el ejemplo), como as en un anlisis un poco
ms avanzado, con objetos y mensajes entre ellos.
Por ejemplo, el mismo ejemplo que ya habamos visto, lo podemos separar un poco con algunos
objetos conceptuales bien claros:
: Cajero
: Caja
: Venta
1 : iniciarVenta()
2 : nuevo()
4
Loop [p]
: Catalogo
5 : ingresarProducto()
6 : p := obtenerProducto()
8 : agregar()
9
10
11 : finalizarVenta()
12 : t := obtenerTotal()
13 : calcularTotal()
14
15
ILUSTRACIN 32. DIAGRAMA DE SECUENCIA PARA EL PROCESO DE VENTA (SIN PAGO) DEL TPDV.
Como podemos observar en el ejemplo, el flujo se parece mucho al que inicialmente habamos
planteado como solucin, con la diferencia en que incluimos un elemento llamado Venta y otro
67

Caja, en lo que representamos los principales elementos de la venta. En este caso, la caja
representa el aparato fsico con el cul interacta el Cajero y la Venta es un objeto que representa
el carro de compras que trae el Cliente y que permite calcular el valor de la compra y el detalle del
recibo.
Hasta ahora, nuestro anlisis se ha basado en una metodologa basada en los casos de uso, y esto
muchas veces es suficiente para describir el comportamiento del sistema que se est analizando.
Sin embargo, existen otro tipo de artefactos que, en casos particulares, nos sirven para describir
en detalle ciertas operaciones. De esta forma, definimos:
LOS CONTRATOS DE LAS OPERACIONES DEL SISTEMA DESCRIBEN EL
RESULTADO DE LA EJECUCIN DE LAS OPERACIONES DEL SISTEMA EN
FUNCIN DE LOS CAMBIOS DE ESTADO DE LOS OBJETOS DEL
DOMINIO.
Con esta definicin de libro podemos comenzar por preguntarnos cules son las operaciones del
sistema. Ahora bien, veamos primero la sintaxis del contrato antes de pasar al ejemplo de cmo se
describe uno.
Al igual que las especificaciones de los casos de uso, los contratos se escriben como textos bajo
cierta estructura o anatoma. Esta estructura se compone de las siguientes secciones:
Operacin: <Operacin del sistema>
Responsabilidad: <Objetivo de la operacin>
Tipo o Clase: <Sistema, Concepto, Interfaz, Clase>

Ref. Cruzadas: <CU donde aparece>
Notas: <Notas de diseo, algoritmos e informacin>
Excepciones: <Casos excepcionales>
Salida: <Salidas hacia fuera del sistema>
Precondiciones: <Suposiciones acerca del estado antes>
Postcondiciones: <Estado despus de la aplicacin de la operacin>
ILUSTRACIN 33. NOTACIN PARA LOS CONTRATOS DE LAS OPERACIONES
Veamos como ejemplo el CU1. Realizar Venta. El diagrama se secuencias de ese caso de uso sera
el siguente:
68

: Cajero
: Caja
: Catalogo
: Venta
1 : iniciarVenta()
2 : nuevo()
CO1
3
4
Loop [p]
5 : ingresarProducto()
CO2
6 : p := obtenerProducto()
8 : agregar()
9
10
11 : finalizarVenta()
12 : t := obtenerTotal()
13 : calcularTotal()
CO3
14
15
ILUSTRACIN 34. DIAGRAMA DE SECUENCIA CON LAS OPERACIONES DE LA VENTA
Como podemos ver hemos destacado los 3 posible contratos a travs de las operaciones del
sistema (las que vienen del mundo exterior). Utilicemos la operacin ingresarProducto de nuestro
diagrama de secuencia antes mostrado.
Operacin: CO2. ingresarProducto(cod : CodigoBarras, cant : Int)
Responsabilidad: Ingresar un producto representado por cod a la venta en
curso.
Tipo o Clase: Sistema
Ref. Cruzadas: CU1. Realizar Venta
Notas:
Excepciones: - Si cod no existe, error.
Salida:
69


Precondiciones: - Exista una instancia v de tipo Venta.
- Exista una instancia c de CatalogoDeProductos.
Postcondiciones: - Se haya encontrado una instancia p de Producto en el
catlogo c que tenga como valor del atributo cdigo
igual al valor cod entregado.
- Se haya creado una nueva instancia ldv de
LneaDeVenta.
- Se haya asociado p a ldv.
- Se haya cambiado el valor cantidad de ldv por n
entregado.
- Se haya asociado ldv a v.
ILUSTRACIN 35. CONTRATO PARA LA OPERACIN INGRESARPRODUCTO DEL TPDV
Como podemos ver en el ejemplo, el contrato describe el funcionamiento desde el punto de

vista lgico de la operacin en estudio. Es importante hacer notar que las postcondiciones que se
describen en el contrato deben ser consistentes con lo especificado en el Modelo de Dominio, ya
que los tipos y objetos a los cuales se hace referencia, adems de las asociaciones que aparecen,
representan lo especificado en este modelo.
TIPOS DE POSTCONDICIONES
Las postcondiciones son solo de 3 tipos:
De creacin de instancias, que indican cuando se genera una nueva instancia de una clase.
De formacin o rotura de asociaciones, que indican cuando se asocian o desasocian
instancias.
De cambio en atributo, que indican asignaciones de informacin dentro de las instancias.
En nuestro ejemplo,
[Creacin de Instancia] Se crea una instancia de LneaDeVenta ldv.
[Formacin de Asociacin] ldv se asocia a la Venta actual.
[Cambio de Atributo] La cantidad de la ldv pasa a ser igual a cant.
[Formacin de Asociacin] Se asocia un DetalleDelProducto a ldv que corresponde al detalle del
producto identificado por cod.
RECOMENDACIONES
Cuando se estn describiendo los contratos, se tienen que tener en cuenta algunas
recomendaciones bsicas que nos ayudarn a obtener un buen anlisis de las operaciones del
sistema. Estas recomendaciones son:
Utilice los mismos nombres de los eventos utilizados en el diagrama se secuencia como
nombres de las operaciones a estudiar.
70

Los parmetros exprselos en una forma simple, indicando un tipo primitivo o una clase
conceptual del modelo de dominio.
Identifique si los contratos pueden ser utilizados en otros casos de uso, ya que esto le
permitir reutilizar esta informacin en el diseo y mejor an, encontrar patrones
comunes entre los casos de uso.
Las precondiciones deben ser expresadas en verdades absolutas y no supuestos
condicionales, ya que en el contrato no se pone en duda su validez.
Las postcondiciones exprselas siempre como tiempo pasado, es decir, destaque que la
postcondicin es un resultado de una operacin que se realiza antes de que acabe la
ejecucin de la misma.
Para identificar las postcondiciones, realice el siguiente ejercicio mental: tome una
fotografa del escenario antes de la operacin, luego ejecute la operacin a ojos cerrados
como en una caja negra y saque otra nueva fotografa del escenario al finalizar. Compare
ambas fotografa y obtendr las postcondiciones expresadas como un cambio de estado
del escenario.
Por ltimo, no utilice los contratos como requisito de sus anlisis. Los contratos son tiles
cuando describen detalles que no se pueden inferir del modelo de casos de uso ya
desarrollado, por lo que debemos saber elegir cundo utilizarlos y cuando no.
LOS CONTRATOS Y LOS CAMBIOS AL MODELO CONCEPTUAL
Es normal, y tengan la certeza que se toparn con esta situacin, que a partir de los contratos sea
necesario interferir el modelo de dominio o conceptual definido. Es por eso que, cuando
describimos nuestros contratos, podemos encontrar algunos detalles que cambiar. Por ejemplo,
para el contrato de la operacin de finalizarIngreso() del diagrama que hemos estado estudiando
tenemos que hemos incorporado un flag de validacin que avisa cuando la venta es completa.
Este atributo debe estar indicado en el modelo conceptual, ya que desde el punto de vista del
anlisis es un detalle importante, por lo que en la clase Venta del modelo deberemos incorporarlo
como atributo de la clase con alguna notacin adicional:
esCompleta: ValorDeVerdad
esCompleta: Boolean
DIAGRAMAS DE ESTADO
Para complementar la el modelo de comportamiento, se puede definir:
EL DIAGRAMA DE ESTADO REPRESENTA LOS EVENTOS Y ESTADOS
INTERESANTES DE UN OBJETO Y EL COMPORTAMIENTO DE UN
OBJETO COMO REACCIN A UN EVENTO.
Con esta definicin, podemos inferir que los diagramas de estado cobran mucho sentido cuando
queremos ver el comportamiento de los objetos o del mismo caso de uso desde un punto de vista
de caja negra.
La notacin que utilizan los diagramas de estado es:
71

Notacin Diagramas de Estado

Estado
Estado
evento [cond] / actividad
Actividad Regular
Estado
Estado Inicial / Cruce
entry/accion
do/accion
exit/accion
Actividad de Estado
Estado Final
Estado de Trmino
Historial Superficial
Decisin
H*
Historial Recursivo
Estado
Compuesto No Ortogonal
Compuesto Ortogonal
ILUSTRACIN 36. NOTACIN DE LOS DIAGRAMAS DE ESTADO
En el caso de las acciones, stas pueden ser condicionadas (usando la misma nomenclatura del
diagrama de secuencia, con la condicin entre corchetes) y tambin automticas, las cuales se
representan sin ninguna accin sobre la flecha.
Entonces, cul es la utilidad de estos diagramas?.
La respuesta a esta pregunta no es fcil. Si nos vamos a ver directamente los artefactos UML que
participan en el UP, nos encontraremos que no existe un Modelo de Estados que represente algo
en particular. Los diagramas de estado ms bien son complementarios a los artefactos definidos
para cada disciplina, ya que permiten incorporar mayor detalle y entendimiento a algunos
procesos o clases complejas para el entendimiento del pblico objetivo.
De esta forma, para mantener el orden en el proceso unificado adaptado al curso, utilizaremos los
diagramas de estado para un uso muy particular: describir los estados y eventos para los objetos
principales del sistema identificados en el modelo de comportamiento.
Por ejemplo, para nuestro ejemplo de la caja de supermercado, podremos ver que a travs de los
contratos la Venta (o sea las instancias de Venta) son las que ms sufren cambios de estado. En
efecto, en el CO1 el objeto v es creado, en el CO2 se le agrega una instancia de LineaDeVenta
(tantas veces como se realiza esa operacin) y en el CO3 se cambia el estado y se deja como
cerrada.
Veamos el diagrama que define estos estados para un mayor entendimiento:
72

agregar
crearVenta
Creada
En Construccin
entry/fijarFecha
do/asociarLineaDeVenta
calcularTotal
Pagada
exit/asociarPago
exit/cambiarEstado
Calculada
registrarPago
exit/fijarTotal
ILUSTRACIN 37. DIAGRAMA DE ESTADOS PARA EL OBJETO VENTA DEL TPDV
Como se observa en el diagrama, los eventos saltan a la vista en el diagrama de estados como las
operaciones que los gatillan en el diagrama de secuencias, y las actividades de estado aparecen
como los cambios de estado que se describen en los contratos respectivos. Por otro lado, no todas
las transiciones tienen un evento definido, en ese caso no se requiere un evento, sino que es una
transicin automtica (una vez que es Creada, pasa automticamente a En Construccin).
Es importante, entonces, que los eventos se definan de la misma forma como fueron identificados
en los diagramas de secuencia y las actividades como fueron identificadas en los contratos de las
operaciones.
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP)

El Centro Mdico de Especialidades y Laboratorios Clnicos, conocido como CEMELAB, es un
servicio que de atencin mdica (consultas) de diferentes especialidades y laboratorio para
diferentes exmenes mdicos a lo largo de todo el pas. CEMELAB posee convenio con casi todas
las ISAPRES lo que la hace una excelente alternativa.
El gerente general ha decidido implantar un sistema electrnico de fichas mdicas e historial de
pacientes (SEFP) para realizar todo el seguimiento de los pacientes independientemente de donde
se atiendan o realicen los procedimientos indicados por los especialistas. Este sistema de ficha
electrnica est reemplazando al sistema actual de fichas de atencin que tiene cada centro.
Para el diseo del SEFP se ha contratado a su consultora, la cual ha realizado una primera
entrevista obteniendo una descripcin aproximada del proceso y ciclo de vida de la ficha en
cuestin. Esta informacin incluye la siguiente:
1) Cuando un paciente nuevo llega a cualquier centro, se le crea una nueva ficha mdica, la
cual debe ser completada con la informacin bsica del individuo (nombre completo, rut,
direccin, telfono de contacto y correo electrnico si tuviera). Estos datos deben ser
73

ingresados en la recepcin correspondiente (ya sea en el laboratorio como en la recepcin

de atencin mdica).
2) Cuando un especialista atiende a un paciente, ste podr ver la ficha completa del
individuo para poder realizar un seguimiento completo. Esto lo hace a travs del terminal
ubicado en cada box de atencin.
3) Una vez que ha terminado la atencin del especialista, ste debe llenar con la anamnesis
realizada en la entrevista y posterior anlisis realizado. Esta informacin debe incluir fecha
de la atencin, datos de la inspeccin (peso, talla, IMC, temperatura y presin arterial),
observaciones del examen fsico obtenido, diagnstico e indicaciones (alimentaria y
conductual, medicamentos y/o procedimientos clnicos, derivaciones u hospitalizacin).
4) Adems, en cada atencin, el SEFP debe conectarse con un servicio web de la Agenda
Mdica para informar cuando se realizan las atenciones de los especialistas, de manera de
llevar el control y poder cancelar los honorarios mdicos respectivos.
5) Algo similar pasa cuando un paciente va a laboratorio por un procedimiento. En este caso
el tecnlogo mdico o enfermera podr ver la informacin referente a la ltima entrevista
con especialista o aquella que le deriv a dicho procedimiento. As mismo, deber ingresar
cualquier observacin y los resultados obtenidos en el procedimiento (ya sea in situ o
posterior anlisis de los resultados).
6) En caso de ser derivado a un centro asistencial para hospitalizacin, el especialista que lo
deriva podr imprimir un informe mdico que deber presentar en el hospital o clnica que
asista para que lleve toda la informacin de manera ms expedita.
7) El SEFP no debe realizar cobros por bonos o servicios prestados, ni tampoco el control de
remuneraciones y honorarios mdicos del personal.
Lo primero que se debe realizar es un anlisis de los requerimientos en bruto entregados por el
cliente del proyecto (gerente general de CEMELAB). En este caso, esos requerimientos es bruto se
encuentran en el texto entregado como enunciado. Veamos cmo vamos obteniendo la
informacin a travs de los artefactos solicitados.
ESPECIFICACIN DE FUNCIONES
Vamos a realizar una clasificacin preliminar de los requerimientos tomando uno por uno de los
puntos indicados y revisando si podemos identificar de qu tipo son cada una de las situaciones
(segn FURPS+).
En un anlisis simple, podemos obtener que los requerimientos 1 al 6 son del tipo funcional y el
nmero 7 es una restriccin del sistema. Por otro lado, el requerimientos 4 tiene una componente
de interoperatividad con el sistema de agendamiento mdico.
Ahora, especifiquemos los 6 requerimientos funcionales con la tcnica de especificacin de
funciones.
74

Nombre del Sistema:
Panorama:
Clientes:
Metas:
Sistema Electrnico de Fichas de Paciente (SEFP)

CEMELAB, a travs de sus centros mdicos y laboratorios a lo largo del pas
Recepcionistas, Mdicos y Laboratoristas
Crear un sistema de registro electrnico de fichas nicas de pacientes del centro
para:
Centralizar la informacin mdica de cada paciente registrado en el centro
Mantener la informacin en lnea de manera de que cualquier especialista

pueda consultarla en forma oportuna
Entregar la informacin requerida al paciente en caso de hospitalizacin y/o

traslado a otro centro de atencin.
# Ref:
Funcin:
Descripcin:
R1.1
Registro de un Paciente
El sistema debe permitir el registro de un paciente con los datos bsicos de ste
(nombre completo, rut, direccin, telfono de contacto y correo electrnico).
Evidente
Categora
Categora:
Atributo
# Ref:
Funcin:
Descripcin:
Categora:
Atributo
# Ref:
Funcin:
Descripcin:
Categora:
Atributo
# Ref:
Funcin:
Descripcin:
Categora:
Atributo
# Ref:
Funcin:
Descripcin:
Categora:
Atributo
Informacin Segmentada
# Ref:
Funcin:
R1.2
Registro de Anamnesis
El sistema debe permitir que el mdico tratante ingrese el detalle de la atencin
en box incluyendo los procedimientos y medicamentos indicados.
Evidente
Categora
R1.3
Registro de Observaciones en un Procedimiento
El sistema debe permitir que la enfermera o mdico a cargo ingrese las
observaciones durante el procedimiento mdico de un paciente.
Evidente
Categora
R1.4
Registro de Resultados de un Procedimiento
El sistema debe permitir que el tecnlogo mdico ingrese los resultados y las
inferencias segn sea el caso de los procedimientos realizados por el paciente.
Evidente
Categora
R2.1
Consulta de Historial del Paciente
El sistema debe permitir al profesional consultar sobre la historia reciente del
paciente registrada en su ficha.
Evidente
Categora
La informacin debe ser segmentada segn el nivel de
Poltica
acceso del profesional consultante.
R2.2
Actualizacin de Agenda Mdica
75

Descripcin:
Categora:
Atributo
Servicio Web
El sistema debe actualizar el sistema de agendamiento cuando el especialista

cierra la ficha luego de terminada la consulta de un paciente.
Oculto
Categora
La actualizacin debe realizarse a travs de un servicio
Interoperatividad
web prestado por el sistema de agenda mdica.
ILUSTRACIN 38. ESPECIFICACIN DE FUNCIONES DEL SEFP
Con esto ya tenemos gran parte del trabajo hecho, ya que hicimos la primera clasificacin de lo
obtenido de parte del cliente.

A continuacin definiremos el modelo de casos de uso del problema.
A pesar de que no siempre es as, en este caso los casos de uso se parecern mucho a lo que
encontramos como funciones. Veamos la tcnica de a poco para que vayamos descubriendo el por
qu de esta afirmacin tan adelantada.
LMITES DEL SISTEMA
Si observamos las metas de la especificacin funcional, podemos decir que el lmite del sistema
est la creacin y registro del historial mdico de un paciente que ingresa y se atiende en algn
centro de CEMELAB. Sin embargo, tambin podemos decir que excluye:
La administracin de la agenda
La compra de bonos y el pago de los servicios prestados por el centro
El control de remuneraciones y honorarios de profesionales
ACTORES
A partir de los clientes y del texto entregado, podemos decir que los actores del sistema son:
Actor
Recepcionista
Objetivo
Registrar un paciente nuevo para atencin
Imprimir detalle de ficha mdica en caso de derivacin o traslado

Especialista
Consultar ficha del paciente a ser atendido
Ingresar a la ficha del paciente la anamnesis

Enfermera
Consultar ficha del paciente a ser atendido
Ingresar observaciones en procedimiento

Tecnlogo
Ingresar resultados y diagnstico de un procedimiento

Paciente
Ser atendido
Agenda Mdica
Actualizar las horas mdicas cuando se cierre una atencin

ILUSTRACIN 39. TABLA DE ACTORES Y OBJETIVOS DEL SEFP
ESPECIFICACIN DE CASOS DE USO DE ALTO NIVEL

Por ltimo, con los objetivos e intersectados con la especificacin de funciones, describiremos los
casos de uso del sistema:
76

Caso de Uso:
Actores:
Tipo:
Descripcin:
CU1: Registrar Paciente

Recepcionista (I), Paciente
Primario
Cuando llega un paciente nuevo, ste debe ser registrado en el sistema y su ficha
ser creada. La informacin necesaria para este registro es nombre completo, rut,
direccin, telfono y correo electrnico.
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU2: Consultar Historial

Especialista/ Enfermera (I)
Primario
Antes de la atencin, el encargado deber revisar la ficha del paciente.
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU3: Registrar Anamnesis

Especialista (I), Paciente
Primario
Al terminar la atencin mdica, el mdico tratante ingrese el detalle de la atencin
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU4: Registrar Observaciones por Procedimiento

Enfermera (I)
Secundario
Durante un procedimiento, la enfermera puede ingresar observaciones que le
parezcan relevantes para el anlisis del mismo.
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU5: Registrar Resultado de Procedimiento

Tecnlogo (I)
Primario
Al analizar una muestra, el tecnlogo debe ingresar los resultados clnicos en la
ficha, as como tambin el diagnstico preliminar si procede.
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU6: Generar Traslado

Recepcionista (I), Especialista, Paciente
Opcional
En caso de un traslado (derivacin u hospitalizacin), se debe emitir un informe
indicando el ltimo diagnstico y procedimientos asociados a ste.
Caso de Uso:
Actores:
Tipo:
Descripcin:
CU7: Actualizar Agenda Mdica

Especialista (I)
Primario
Cada vez que el especialista cierra una atencin mdica, sta debe ser actualizada en
la agenda mdica.
ILUSTRACIN 40. ESPECIFICACIN DE CASOS DE USO DE ALTO NIVEL PARA EL SEFP
Con estos 7 CU vamos a trabajar, pero solo 5 usaremos su forma expandida.

ESPECIFICACIN DE CASOS DE USO EXPANDIDOS
A continuacin, especificaremos los casos de uso expandidos para aquellos que sean de tipo
primario.
Caso de Uso:
Actores:
Propsito:
Resumen:

Recepcionista (I), Paciente
Realizar el registro de un paciente nuevo en el SEFP.
Cuando llega un paciente nuevo, ste debe ser registrado en el sistema y su ficha
77

ser creada. La informacin necesaria para este registro es nombre completo, rut,
direccin, telfono y correo electrnico.
Tipo: Primario y Esencial
Ref. Cruzadas: R1.1
Curso Normal
Acciones de los Actores
Respuestas del Sistema
1. Paciente llega al mesn de atencin y entrega
su RUT.
2. Recepcionista ingresa RUT en el sistema para
3. Sistema confirma que el paciente es nuevo y
confirmar que es nuevo.
solicita informacin bsica.
4. Recepcionista solicita al paciente informacin.
5. Paciente entrega a Recepcionista informacin
solicitada.
6. Recepcionista ingresa la informacin en el
7. Sistema registra la informacin y crea la ficha
sistema.
electrnica informando accin.
8. Recepcionista entrega RUT al Paciente.
Cursos Alternos
(3a) Si el paciente ya existe, informa al Recepcionista y termina el CU.
(7a) Si el RUT ya est registrado con otra informacin, alerta al Recepcionista y solicita confirmacin para
actualizar informacin.
Caso de Uso:
Actores:
Propsito:
Resumen:

Especialista/Enfermera (I)
Consultar aspectos relevantes de la ficha previos a la atencin.
Antes de la atencin, el encargado deber revisar la ficha del paciente utilizando el
RUT de ste.
Ref. Cruzadas: R2.1
Curso Normal
1. Especialista/Enfermera ingresa el RUT del
2. Sistema obtiene ficha del paciente y muestra
paciente en el sistema.
informacin.
Cursos Alternos
(2a) Si el paciente no existe, lo informa y termina el CU.
Caso de Uso:
Actores:
Propsito:
Resumen:
1.
3.
5.

Especialista (I), Paciente
Registrar la informacin resultante de la consulta mdica.
Al terminar la atencin mdica, el mdico tratante ingrese el detalle de la atencin
Ref. Cruzadas: R1.2, CU7
Curso Normal
Especialista ingresa el RUT del paciente.
2. Sistema encuentra la ficha mdica, abre la
atencin mdica y solicita informacin sobre los
datos de la inspeccin y observaciones al
examen fsico.
Especialista ingresa datos de peso, talla, presin 4. Sistema registra informacin de la inspeccin y
arterial, temperatura, etc. y las observaciones si
solicita informacin sobre diagnstico del
las hubiera.
paciente.
Especialista ingresa el diagnstico.
6. Sistema registra el diagnstico y solicita
informacin sobre procedimientos,
78

medicamentos e indicaciones.
Especialista ingresa los procedimientos,
8. Sistema registra informacin y cierra la atencin
medicamentos e indicaciones entregadas al
mdica (CU7).
paciente.
Cursos Alternos
(2a) Si la ficha no existe, informa al Especialista y termina el CU.
7.
Caso de Uso:
Actores:
Propsito:
Resumen:

Tecnlogo (I)
Registrar la informacin de anlisis y diagnstico del procedimiento realizado.
Al analizar una muestra, el tecnlogo debe ingresar los resultados clnicos en la ficha,
as como tambin el diagnstico preliminar si procede.
Ref. Cruzadas: R1.4
Curso Normal
1. Tecnlogo ingresa el RUT del paciente.
2. Sistema encuentra la ficha mdica, solicita
informacin sobre la fecha de la muestra, los
resultados del examen y diagnstico en caso de
ser necesario.
3. Tecnlogo ingresa datos obtenidos de la
4. Sistema registra informacin y cierra la ficha.
muestra y en caso de que aplique se ingresa el
diagnstico.
Cursos Alternos
(2a) Si la ficha no existe, informa al Tecnlogo y termina el CU.
Caso de Uso:
Actores:
Propsito:
Resumen:

Especialista
Enviar un mensaje al Sistema de Agenda Mdica (SAM) de cierre de atencin.
Al cerrar una ficha por atencin mdica, el sistema debe generar un mensaje al SAM
para informar que el especialista ha dado trmino a la atencin.
Ref. Cruzadas: R2.2, CU3
Curso Normal
1. Especialista cierra la atencin mdica (CU3).
2. Sistema registra el cierre de la ficha y enva un
mensaje al SAM indicando el cierre de la
atencin.
3. Sistema recibe confirmacin de parte del SAM
de que se ha realizado la transaccin y termina
el CU.
Cursos Alternos
(3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una
alerta al administrador del sistema, quin debe cursar manualmente el proceso.
ILUSTRACIN 41. ESPECIFICACIN DE CU EXPANDIDOS PARA EL CASO SEFP
En este ltimo CU, en el Curso Alterno (3a) se menciona que debe existir un administrador del
sistema. Esto es porque no se ha mencionado que pasa con la conectividad y comunicacin entre
ambos sistema (SAM y SEFP), de modo que ha sido una sugerencia en los requerimientos. Es
importante validarlo con el cliente final antes de cerrar la iteracin y utilizar dicha informacin
para el anlisis del sistema.
79


Para este caso, el Diagrama de Casos de Uso no es muy simple, ya que incorpora conexiones entre
casos de uso (CU3 y CU7, tal como aparece en su especificacin expandida). Veamos el resultado:
System
CU6: Generar Traslado

Recepcionista
Especialista
Agenda Mdica
<<include>>
CU7: Actualizar SAM
CU2: Consultar Ficha
Enfermera
CU4: Registrar Observaciones
CU5: Registrar Resultados

Tecnlogo
ILUSTRACIN 42. DIAGRAMA DE CASOS DE USO DEL SEFP
El hecho de que aparezca el include entre el CU3 y el CU7 quiere explicar de que el CU7 est
siempre incluido en el CU3 (es un subproceso, pero en este caso es sobre otro sistema).
GLOSARIO
A continuacin, veamos un glosario para el problema:
Trmino
Ficha Mdica
Registro
Box
Anamnesis
Datos de la Inspeccin
Diagnstico
Procedimiento
Agenda Mdica (SAM)
Definicin
Registro electrnico (en este caso) en donde queda almacenada toda la historia
mdica de un paciente.
Proceso a travs del cual se guarda la informacin ingresada por un usuario.
Espacio fsico donde se realiza la anamnesis.
Proceso de revisin que realiza un especialista en un box de atencin a un
paciente.
Informacin que resulta de un examen fsico realizado por un especialista en un
box de atencin (peso, talla, temperatura y presin arterial).
Inferencia que realiza el especialista como resultado del examen fsico.
Cualquier tipo de examen fsico o psicolgico que puede solicitar el especialista.
Sistema externo necesario para registrar cuando un especialista cierra una
atencin mdica.
ILUSTRACIN 43. GLOSARIO PARA EL SEFP
80

Este glosario resumido (ya que podramos encontrar muchos ms trminos para este problema)
solo muestra un ejemplo de cmo van describindose las diferentes definiciones de, en este caso,
los conceptos del dominio.
MODELO DE DOMINIO
Para este modelo comenzaremos con los Diagramas de Actividades que representan los procesos
relacionados con el caso, y luego realizaremos un Diagrama de Clases Conceptuales que soporte el
dominio en cuestin.
DIAGRAMA DE ACTIVIDADES
El enfoque que utilizaremos ser el ver el diagrama de actividades global a partir de las
transiciones que tiene la ficha de un paciente desde su generacin y su uso posterior.
De esta manera, el diagrama nos muestra los diferentes carriles-de-nado para los actores y
entidades que utilizan la ficha o realizan actividades como resultado del uso de la ficha. As, el
diagrama comienza por el recepcionista (ya sea en el laboratorio como en la consulta mdica) el
cual registra la informacin bsica de la ficha (crear).
A continuacin hemos indicado un conector de decisin para diferenciar si el siguiente flujo (por
consulta mdica o por procedimiento). De esta manera diferenciamos el paso dependiendo del
actor principal. Cada uno de esos flujos termina en un conector con una X de manera de que
podamos volver al flujo principal en la decisin para el siguiente flujo.
Finalmente, notaremos que no tiene una actividad de trmino, ya que la ficha no se destruye en el
dominio, sino que una vez que el paciente ingresa al esquema, se mantendr desde ese momento
en adelante.
81

Recepcionista
Especialista
Sistema de Agenda Mdica
Laboratorista
[paciente ingresa al centro]

Crear Ficha de Paciente
[paciente entra a toma de muestra]

[paciente entra a consulta]
Ver Ficha de Paciente
Ver Ficha de Paciente
Realizar el Procedimiento
Realizar la Consulta
[no hay observaciones]

Registrar la Anmnesis
[hay observaciones]
Registrar Observaciones
Registrar Trmino de Atencin
[derivacin a centro asistencial]

Realizar Anlisis
[no hay derivacin]

Imprimir Informe Mdico
Registrar Resultados
ILUSTRACIN 44. DIAGRAMA DE ACTIVIDADES DEL SEFP

Tal como vimos en clases, lo que vamos a realizar es utilizar ambos mtodos de identificacin de
clases conceptuales para luego ir dibujando el diagrama general. Veamos primero entonces la lista
de categoras:
Objetos tangibles o fsicos
Especificaciones, diseos o descripciones de las cosas
Ejemplos
InformeDeDerivacion
DetalleDeInforme
ResultadoProcedimiento
DetalleAnamnesis
CentroMedico
Recepcin
ConsultaMedica
BoxDeProcedimiento
Anamnesis
Procedimiento
Recepcionista
Especialista
Laboratorista
Lugares
Lneas de la transaccin
Roles de la gente
82

Ejemplos
Paciente
Contenedores de otras cosas
Cosas en un contenedor
Otros sistemas externos
AgendaMedica
Conceptos abstractos
Anamnesis
Procedimiento
FichaDePaciente
Organizaciones
Hechos
Procesos
Anamnesis
Procedimiento
Reglas y polticas
Catlogos
RegistroDeFichas
Registro de finanzas, trabajo, contratos, asuntos legales
Instrumentos y servicios financieros
Manuales, documentos, artculos de referencia, libros
InformeDeDerivacion
ILUSTRACIN 45. IDENTIFICACIN DE CLASES CONCEPTUALES SEGN CATEGORAS PARA EL SEFP
Note que aparecen las mismas clases en varias categoras. Veamos ahora las frases nominales de
los escenarios de casos de uso:
Caso de Uso:

Curso Normal
9. Paciente llega al mesn de atencin y entrega
su RUT.
10. Recepcionista ingresa RUT en el sistema para
11. Sistema confirma que el paciente es nuevo y
confirmar que es nuevo.
solicita informacin bsica.
12. Recepcionista solicita al paciente informacin.
13. Paciente entrega a Recepcionista informacin
solicitada.
14. Recepcionista ingresa la informacin en el
15. Sistema registra la informacin y crea la ficha
sistema.
electrnica informando accin.
16. Recepcionista entrega RUT al Paciente.
Cursos Alternos
(3a) Si el paciente ya existe, informa al Recepcionista y termina el CU.
(7a) Si el RUT ya est registrado con otra informacin, alerta al Recepcionista y solicita confirmacin para
actualizar informacin.
Caso de Uso:

Curso Normal
3. Especialista/Enfermera ingresa el RUT del
4. Sistema obtiene ficha del paciente y muestra
paciente en el sistema.
informacin.
Cursos Alternos
(2a) Si el paciente no existe, lo informa y termina el CU.
Caso de Uso:
9.

Curso Normal
Especialista ingresa el RUT del paciente.
10. Sistema encuentra la ficha mdica, abre la
atencin mdica y solicita informacin sobre los
datos de la inspeccin y observaciones al
83

11. Especialista ingresa datos de peso, talla, presin
arterial, temperatura, etc. y las observaciones si
las hubiera.
13. Especialista ingresa el diagnstico.
examen fsico.
12. Sistema registra informacin de la inspeccin y
solicita informacin sobre diagnstico del
paciente.
14. Sistema registra el diagnstico y solicita
informacin sobre procedimientos,
medicamentos e indicaciones.
16. Sistema registra informacin y cierra la atencin
mdica (CU7).
15. Especialista ingresa los procedimientos,

medicamentos e indicaciones entregadas al
paciente.
Cursos Alternos
(2a) Si la ficha no existe, informa al Especialista y termina el CU.
Caso de Uso:

Curso Normal
5. Tecnlogo ingresa el RUT del paciente.
6. Sistema encuentra la ficha mdica, solicita
informacin sobre la fecha de la muestra, los
resultados del examen y diagnstico en caso de
ser necesario.
7. Tecnlogo ingresa datos obtenidos de la
8. Sistema registra informacin y cierra la ficha.
muestra y en caso de que aplique se ingresa el
diagnstico.
Cursos Alternos
(2a) Si la ficha no existe, informa al Tecnlogo y termina el CU.
Caso de Uso:

Curso Normal
4. Especialista cierra la atencin mdica (CU3).
5. Sistema registra el cierre de la ficha y enva un
mensaje al SAM indicando el cierre de la
atencin.
6. Sistema recibe confirmacin de parte del SAM
de que se ha realizado la transaccin y termina
el CU.
Cursos Alternos
(3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una
alerta al administrador del sistema, quin debe cursar manualmente el proceso.
ILUSTRACIN 46. FRASES NOMINALES PARA ESCENARIOS DEL SEFP
Como podemos ver, en los diferentes escenarios encontramos un lenguaje mixto, en donde nos
podemos referir de diferentes formas a los mismo conceptos, por lo que es importante no solo
tomar lo que dice, sino que formalizar tambin el concepto como tal, ya que en el diagrama de
clases conceptuales es donde debe quedar finalmente el concepto que ser utilizado finalmente
en el sistema.
Ahora, completemos con los otros 2 pasos de la tcnica el diagrama de clases conceptuales y
veamos el resultado final:
84

DetalleDeFicha
+rut
+nombre
+direccion
+telefono
+email
FichaDePaciente
es-descrita-por
Paciente
posee
1
0..1
crea
Recepcionista
1
contiene
+cotiene
0..*
Laboratorista
0..*
Procedimiento
1
1
es-descrita-por
ingresa
Especialista
Anamnesis
1
es-descrita-por
DetalleAnamnesis
DetalleProcedimiento
0..1
+datos_inspeccion
+observaciones
+indicaciones
+otros
+observaciones
0..1 +resultados
+diagnostico
ingresa
ILUSTRACIN 47. DIAGRAMA DE CLASES CONCEPTUALES DEL SEFP
Este diagrama puede ser la primera aproximacin para el futuro diseo de clases y por supuesto
un insumo importante para los siguientes artefactos y modelos de anlisis y diseo.
En este caso comenzaremos con los Diagramas de Secuencia que representan los eventos que
ocurren en cada caso de uso, luego realizaremos los Contratos asociados a las operaciones
principales del sistema y por ltimo algunos Diagramas de Estado para los objetos principales del
sistema.
Para especificar los diagramas de secuencia es importante hacerlos a travs de los escenarios
encontrados en los casos de uso. Segn lo expuesto en este problema, los escenarios alternos son
sencillos, as que, donde corresponda, se utilizarn los cursos alternos como parte del mismo
diagrama. Veamos el escenario del primer caso de uso:
85

: Recepcionista
Sistema
1 : validarRut()
CatalogoDePacientes
2 : pacienteExiste()
3 : ack
4
: DetalleDeFicha
5 : ingresarDetalle()
6 : nuevo()
7
8 : asociarDetalle()
10
ILUSTRACIN 48. DIAGRAMA DE SECUENCIA PARA EL CU1. REGISTRAR PACIENTE
Es posible observar en este diagrama que gran parte de la carga se la estara llevando el objeto
DetalleDeFicha (adelantndonos para cuando lleguemos a los diagramas de estado). Sigamos con
los dems CU y sus respectivos diagramas:
Funcionario
Sistema
1 : consultar()
CatalogoDePacientes
2 : buscar()
3
4
ILUSTRACIN 49. DIAGRAMA DE SECUENCIA PARA EL CU2. CONSULTAR HISTORIAL
Al igual que en el caso anterior, este diagrama no es ms que una traduccin del escenario
realizado para el CU. Veamos el siguiente:
86

: Especialista
Sistema
CatalogoDePacientes
d : DetalleDeFicha
1 : consultar()
2 : buscar()
3:d
: DetalleAnamnesis
5 : registrarInformacin()
6 : crear()
7 : det
8 : registrarAnamnesis()
10
ILUSTRACIN 50. DIAGRAMA DE SECUENCIA PARA EL CU3. REGISTRAR ANAMNESIS
En este caso podemos ver que se complejiza un poco la lgica, sin embargo debemos destacar un
par de puntos.
1. Resumimos los 3 ingresos que existen en el escenario en 1 sola operacin (con la lgica de
que la filla se llena sin registrar la informacin hasta el final).
2. La creacin del objeto DetalleAnamnesis es porque segn el modelo de dominio,
DetalleDeFicha solo sabe registrar DetalleAnamnesis a travs de una Anamnesis (la cual
puede ser generad dentro de DetalleFicha como una lnea de transaccin).
3. Las operacines de consultar, en realidad es la misma utilizada en el CU2.
Sigamos con el siguiente CU:
87

: Laboratorista
Sistema
1 : consultar()
CatalogoDePacientes
d : DetalleDeFicha
2 : buscar()
3:d
4
: DetalleProcedimiento
5 : registrarInformacion()
6 : crear()
7 : det
8 : registrarProcedimiento()
10
ILUSTRACIN 51. DIAGRAMA DE SECUENCIA PARA CU5. REGISTRAR RESULTADO DE PROCEDIMIENTO
En este caso vemos una similitud muy obvia con el CU3, tanto as que a estas alturas podramos
generalizarlo de manera de que sea ms reutilizable. Sin embargo, para efectos prcticos,
sigamos con el anlisis tal cual.
AgendaMedica
Sistema
: Especialista
1 : cerrarAtencin()
2 : cierreFicha()
3 : ack
ILUSTRACIN 52. DIAGRAMA DE SECUENCIA PARA EL CU7. ACTUALIZAR AGENDA MDICA
En el ltimo CU analizado solo tenemos el hecho del cierre de la atencin mdica y en este caso
son operaciones hacia fuera del sistema, as que es poca la interaccin.
Con estos diagramas completamos el anlisis del comportamiento a travs de las secuencias, y
pasaremos a ver los contratos.
88


Una vez que ya se han realizado todos los diagramas de secuencia, se debe comenzar identificado
cules son las operaciones principales para luego ir describindolas a travs de la estructura
planteada para los contratos. Veamos entonces los contratos del problema.
Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
CO1. validarRut(rut)
Validar que el RUT exista dentro del catalogo de pacientes
Sistema
CU1
Si el RUT existe, se aborta el resto del CU
- Exista una instancia r de tipo CatalogoDePacientes
- No se haya encontrado una instancia f de FichaDePaciente
dentro de r que tenga asociada una instancia d de
DetalleDeFicha que tenga como atributo rut el valor del
parmetro rut.
Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
CO2. ingresarDetalle(rut, nombre, direccion, fono, email)

Crear y agregar la informacin bsica del paciente a la ficha
Sistema
CU1
- Se haya creado una instancia d de tipo DetalleDeFicha
- Se hayan fijado los atributos rut, nombre, direccin,
telfono e email con los valores entregados por parmetro.
- Se haya creado una instancia f de tipo FichaDePaciente
- Se haya asociado d a f
Operacin:
Responsabilidad:
CO3. consultar(rut)
Obtiene la informacin de la ficha del paciente a partir del
rut ingresado.
Sistema
CU2, CU3, CU5
Si la ficha no existe, devuelve un valor nulo.
- Exista una instancia r de CatalogoDePacientes
- Se haya encontrado una instancia p de DetalleDePaciente
cuyo atributo rut sea igual al valor del parmetros rut.
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
CO4. registrarInformacion(objeto)
Registra en la ficha del paciente la informacin entregada en
forma de objeto.
Sistema
CU3, CU5
Objeto puede tomar valores de DetalleAnamnesis y
-
89

Salidas:
Precondiciones
Postcondiciones:
- Exiasta una instancia d de DetalleDePaciente

- Se haya asociado objeto a d.
Operacin:
Responsabilidad:
CO5. cerrarAtencion(especialista)
Enva una notificacin al sistema de agenda mdica
indicando el trmido de la atencin del especialista.
Ref. Cruzadas: CU7
Notas: Utiliza XML para construir la llamada al SAM.
Excepciones: Salidas: Un mensaje intersistemas para el SAM
Precondiciones Postcondiciones: ILUSTRACIN 53. CONTRATOS DE LAS OPERACIONES DEL SEFP
Como podemos ver en los contratos expuestos, se hicieron varias optimizaciones en las
operaciones, generalizando las que habamos originalmente encontrado en los diagramas. Esto
permitir un menor riesgo desde el punto de vista del diseo e implementacin futura.
DIAGRAMAS DE ESTADOS
Como ltima parte del anlisis vamos a realizar algunos diagramas de estados que nos permiten
identificar los cabios de estado de los objetos principales.
En particular, uno de los objetos que sufre cambios es la instancia de FichaDePaciente que
representa a un paciente particular. Veamos cmo queda el diagrama de estados en este caso
(considerando todos los contratos del modelo).
nuevo
Disponible
entry/fijarDetalleDePaciente
[es atendido]
En Llenado
do/asociarDetalle
ILUSTRACIN 54. DIAGRAMA DE ESTADOS PARA FICHADEPACIENTE DEL SEFP
Como podemos ver en el diagrama, los estados en realidad son pocos, ya que no pasa por muchos
cambios (solo se ven las asociaciones dadas por los contratos).
Es importante hacer notar que, a pesar de que este sea una visin del anlisis del comportamiento
no necesariamente es la nica. Esto es muy importante desde el punto de vista del problema final,
ya que si la consistencia es buena, no requiere mayor perfeccionamiento.
90

UNIDAD III. EL DISEO ORIENTADO AL

OBJETO
Durante este captulo veremos cmo realizar el diseo de software y componentes
a partir del dominio analizado en la unidad anterior.
91

FUNDAMENTOS DEL DISEO DE SOFTWARE

El diseo del software se encuentra en el ncleo tcnico de la ingeniera del software y se aplica
independientemente del modelo de diseo de software que se utilice. Una vez que se analizan y
especifican los requisitos del software, el diseo del software es la primera de las tres actividades
tcnicas -diseo, generacin de cdigo y pruebas- que se requieren para construir y verificar el
software.
La visin que hasta este punto se ha obtenido del software es mayormente realizada desde el
punto de vista funcional, lo que por supuesto es muy til cuando se trata de comprender el
dominio y tambin el cmo va a funcionar el sistema.
Sin embargo, el resultado del A/DOO (Anlisis y Diseo Orientado al Objeto) debe ser un modelo
cuya orientacin sea, tal como dice su nombre, orientado a objetos, lo que permitira luego a los
programadores realizar una construccin en lenguajes que utilizan ese paradigma (Java, C++, C#,
Eiffel, etc).
De esta manera, el Diseo Orientado al Objeto no es ms que una disciplina que permite
aproximar a los programadores el sistema de anlisis en un entorno orientado al objeto. As, los
artefactos principales de sta tiene como finalidad describir las componentes y objetos del sistema
para su construccin (arquitectura).
LA ARQUITECTURA DEL SOFTWARE

La arquitectura del software alude a la estructura global del software y a las formas en que la
estructura proporciona la integridad conceptual de un sistema. En su forma ms simple, la
arquitectura es la estructura jerrquica de los componentes del programa (mdulos), la manera en
que los componentes interactan y la estructura de datos que van a utilizar los componentes. Sin
embargo, en un sentido ms amplio, los componentes se pueden generalizar para representar
los elementos principales del sistema y sus interacciones.
Un objetivo del diseo del software es derivar el anlisis en una representacin arquitectnica de
un sistema. Esta representacin sirve como marco de trabajo desde donde se llevan a cabo
actividades de diseo ms detalladas como la especificacin de las clases del sistema. Un conjunto
de patrones arquitectnicos permiten que el ingeniero del software reutilice los conceptos del
dominio a nivel de diseo y obtener informacin de ms bajo nivel en forma natural.
En textos sobre ingeniera de software se describe un conjunto de propiedades que debern
especificarse como parte de un diseo arquitectnico:
Propiedades estructurales: Este aspecto de la representacin del diseo arquitectnico

define los componentes de un sistema y la manera en que esos componentes se
empaquetan e interactan unos con otros.
Propiedades extra-funcionales: La descripcin del diseo arquitectnico deber ocuparse

de cmo la arquitectura de diseo consigue los requisitos para el rendimiento, capacidad,
fiabilidad, seguridad, capacidad de adaptacin y otras no funcionales.
92

Familias de sistemas relacionados: El diseo arquitectnico deber dibujarse sobre

patrones repetibles que se basen comnmente en el diseo de familias de sistemas
similares.
Adems, la arquitectura se basa en diferentes vistas de la arquitectura del sistema desde una
perspectiva dada. Cada vista es una ventana a travs de la cual se observa a la arquitectura para
identificar informacin relevante o ideas claves, ignorando todo lo que no sea parte del punto de
vista elegido. Se sugieren 6 tipos bsicos de vistas de la arquitectura:
Vista Lgica: Muestra la organizacin conceptual del software en funcin de las capas,
subsistemas, paquetes, frameworks, clases e interfaces ms importantes. Resume la
funcionalidad de los elementos del software importantes, como cada subsistema. Muestra
los escenarios de realizacin de casos de uso destacados que ilustran aspectos claves del
sistema. Esta vista utiliza diagramas de paquetes, diagramas de clases y diagramas de
interaccin en UML.
Vista de Proceso: Muestra los procesos e hilos de ejecucin, sus responsabilidades,

colaboraciones y la asignacin a ellos de los elementos lgicos (capas, subsistemas, clases,
etc). Esta vista utiliza diagramas de clases y diagramas de interaccin en UML.
Vista de Despliegue: Muestra el despliegue fsico de los procesos y componentes sobre los
nodos de proceso y la configuracin de la red fsica entre los nodos. Esta vista utiliza
diagramas de despliegue en UML.
Vista de Datos: Muestra la vista global de datos persistentes, la correspondencia del

esquema de objetos a datos persistentes (normalmente en una base de datos relacional),
el mecanismo de correspondencia de objetos a una base de datos, procedimientos
almacenados y disparadores (triggers). Esta vista utiliza diagramas de clases para
representar el modelo de datos en UML.
Vista de Casos de Uso: Muestra un resumen de los casos de uso ms significativos para los
requisitos no funcionales, es decir, aquellos casos de uso que, mediante la
implementacin, cubren parte significativa de la arquitectura o que influyen en muchos
elementos de ella. Esta vista utiliza diagramas de casos de uso en UML.
Vista de Implementacin: Muestra el modelo de implementacin del sistema en funcin

de una descripcin resumida de los entregables y cosas que crean entregables (como el
cdigo fuente). Esta vista utiliza diagramas de paquetes, diagramas de componentes y
texto que representa el modelo.
Todas estas vistas son opcionales, pero se sugiere encarecidamente documentar las vistas lgica,
de proceso, de casos de uso y de despliegue. En algunos casos es posible identificar otras vistas
como la de seguridad, por lo que en este caso se deja abierta la opcin de agregar las vistas
necesarias para definir la arquitectura del problema en estudio.
Es fcil ver que gran parte de la arquitectura de software es abarcado con el anlisis y diseo que
hacemos en este curso, pero depende mucho donde y cundo iremos describiendo eso. En
93

particular, la arquitectura se define en un documento llamado Software Architectural Document

(SAD) el cual permite ver las diferentes vistas del sistema.
En este caso, solo nos vamos a referir a la Vista de Implementacin, ya que es la nica que nos
permitir mostrar la informacin relevante para el diseo de software.
El diseo arquitectnico pretende orientar al arquitecto en algunas lneas de trabajo, como las
siguientes:
Organizar el sistema de acuerdo a la arquitectura elegida.
Descomponer modularmente el sistema.
Incorporar medidas de control frente a los mdulos definidos.
A continuacin veremos algunos aspectos bsicos con los cuales debe trabajar el arquitecto antes
de llegar a obtener un diseo completo5.
CONCEPTOS BSICOS
REFINAMIENTO
Podemos definir que:
EL REFINAMIENTO ES UN PROCESO DE ELABORACIN, EN DONDE SE
COMIENZA CON UN ALTO NIVEL DE ABSTRACCIN PARA LUEGO DAR
LA CAPACIDAD DE IR DETALLANDO MS Y MS CADA FUNCIN DEL
SISTEMA.
El refinamiento paso a paso es una estrategia de diseo descendente propuesta originalmente por
Niklaus Wirth.
En cada paso (del refinamiento), se descompone una o varias instrucciones del programa dado en
instrucciones ms detalladas. Esta descomposicin sucesiva o refinamiento de especificaciones
termina cuando todas las instrucciones se expresan en funcin de cualquier computadora
subyacente o de cualquier lenguaje de programacin. De la misma manera que se refinan las
tareas, los datos tambin se tienen que refinar, descomponer o estructurar, y es natural refinar el
programa y las especificaciones de los datos en paralelo.
En muchos casos, dentro del modelo arquitectnico tambin se incluye el modelamiento de datos, sin
embargo para la ingeniera de software son modelos diferentes.
94

Todos los pasos del refinamiento implican decisiones de diseo. Es importante que el
programador conozca los criterios subyacentes (para decisiones de diseo) y la existencia de
soluciones alternativas.
COMPONENTE
Diremos que:
UN
COMPONENTE
ES
UNA
PORCIN
DEL
SISTEMA
CUYO
FUNCIONAMIENTO NO DEPENDE DE LOS SERVICIOS OFRECIDOS POR

OTROS COMPONENTES Y DEFINE INTERFACES PARA COMUNICARSE
CON ELLOS.
Este concepto bsico, cuya descripcin tambin se le conoce como subsistema, es la unidad a
travs de las cuales vamos a ir refinando nuestro diseo.

artefactos son:
Factores de la Arquitectura: Documento que describe cules son las influencias que tienen
los factores crticos en las variaciones en el sistema.
Decisiones de la Arquitectura: Documento que describe las soluciones a los factores de la

arquitectura y cmo afectan al diseo de software.
Diagrama de Componentes: Diagrama que muestra una visin tcnica de la organizacin

de los componetes segn la arquitectura realizada.

El anlisis de la arquitectura se realiza a travs de 2 artefactos bsicos mencionados.
A continuacin veremos cmo se construyen cada uno de manera de mostrar la ruta con la cual
llegaremos al diseo detallado (de clases).
ESPECIFICACIN DE LOS FACTORES DE LA ARQUITECTURA

Los Factores de la Arquitectura se definen a travs de una tabla en donde se especifican cules son
las influencias que tienen los factores crticos en las variaciones en el sistema. Esta informacin
viene directamente del anlisis de requisitos, ya que se basa en la clasificacin FURPS+ de
requerimientos para identificar los factores crticos que pueden afectar el diseo del software (por
95

lo general, todo lo que tiene que ver con la usabilidad, rendimiento, fiabilidad, soporte y el resto
de las categoras no funcionales de requerimientos).
La sintaxis del documento es la siguiente tabla:
Factor
Medidas y Escenarios de
Calidad
Variabilidad
Impacto
Prioridad
para el Exito
Dificultad o
Riesgo
ILUSTRACIN 55. TABLA DE FACTORES DE LA ARQUITECTURA
Segn la especificacin de la tabla de factores, cada campo corresponde a:
Factor: Indica cul es el factor que se est especificando.
Medidas y Escenarios de Calidad: Indica cuales son las medidas en los cuales ese factor es
crtico para el sistema, indicando restricciones necesarias para eso.
Variabilidad: Indica la flexibilidad actual y la evolucin que puede tener el factor a travs
del tiempo.
Impacto: Indica el impacto que tiene el factor en las personas involucradas, arquitectura
del sistema y en otros factores.
Prioridad para el xito: Indica cul es la prioridad que tiene este factor para el xito del
sistema.
Dificultad o Riesgo: Indica el nivel de riesgo que tiene este factor si no es considerado.
Adems, los factores van agrupado por la categora FURPS+ a la cual pertenecen, de manera de
abordar cada uno de ellos con soluciones respectivas.
Por ejemplo, en el caso del problema del TPDV, la definicin de uno de los principales factores de
la arquitectura quedara de la siguiente forma.
Factor
Medidas y Escenarios de
Variabilidad
Impacto
Prioridad
Calidad
para el Exito
Factores de Implementacin
Lector de
Cuando un producto pasa
Debe tener ingreso
Bajo
Alta
Cdigos de
por la caja, el lector de
alternativo va teclado
Barras
cdigos debe leer
directamente el cdigo de
barras de la etiqueta
ILUSTRACIN 56. TABLA DE FACTORES DE LA ARQUITECTURA DEL SPDV
Dificultad o
Riesgo
Media
Veamos ahora el complemento a este documento.

ESPECIFICACIN DE LAS DECISIONES DE LA ARQUITECTURA
Luego de obtenida la tabla de factores, se deben indicar las soluciones que se plantearn por cada
categora de factores y as detectar aquellas que afectan directamente al diseo.
96

Para ello, se debe completar un documento de la siguiente forma:

Categora: <Nombre de la categora de factores>
Resumen: <Resumen del factor y de la solucin propuesta>
Factores: <Enumeracin de los factores relacionados>
Solucin: <Detalle de la solucin propuesta>
Motivacin: <Justificacin del problema y la solucin>
Temas Abiertos: <Factores que no quedan resueltos y que se relacionan con el tema>
Alternativas: <Alternativas a la solucin propuesta>
ILUSTRACIN 57. TABLA DE DECISIONES DE LA ARQUITECTURA
Es fcil ver que es importante dejar en un solo documento ambos artefactos, ya que son
complementarios. Desde el punto de vista acadmico los seguiremos viendo en forma separada.
El tercer artefacto, un poco independiente a los anteriores, define la visin ms cercana al diseo
de clases, que es la de definir los componentes del sistema.
Tal como dice su nombre, el modelo de componentes ilustra los componentes de software que se
usarn para construr el sistema, ya sean desde el punto de vista de organizacin de elementos del
diseo (clases) como tambin la identificacin de componentes reusables que no sea necesario
re-hacer.
De esta manera, este artefacto tiene dos objetivos bsicos:
Organizar el sistema en componentes independientes y que permitan la reusabilidad.
Reutilizar componentes de acuerdo a su funcionalidad dentro del problema.
La sintaxis es la siguiente:
ILUSTRACIN 58. NOTACIN DE LOS DIAGRAMAS DE COMPONENTES
En el proceso de desarrollo utilizado en el curso, este artefacto lo matizaremos de manera tal que
nos permita organizar nuestro sistema antes de desarrollar el modelo de diseo como tal. De esta
manera es importante determinar cmo vamos a identificar la componentes.
Para ello diremos que son componentes o paquete de clases:
97

El conjunto de clases que permiten acceder a los datos del sistema (clases que
representan temes y catlogos, por ejemplo).
El conjunto de clases que est relacionado con la interfaz del sistema (controladores).
El conjunto de clases que representa un grupo de requerimientos de una misma

naturaleza (modularmente hablando).
Sin embargo a este nivel no tenemos que saber qu clases componen cada conjunto nombrado, ya
que solo lo estamos organizando de manera funcional. De esta manera, la regla general sera la
tercera de la lista, ya que podra cumplir con las otras anteriores fcilmente.
Adems, distinguimos entre paquete o componente solo conociendo el estilo de programacin
que usaremos. Por ejemplo, si usamos Java, podemos hacer nuestro diagrama considerando
paquetes de clases (con la notacin de paquete) y en el caso de usar ActiveX o libreras
compiladas, podemos hablar de componentes.
Con estas sencillas reglas, generalizando el problema del supermercado podramos determinar el
siguiente diagrama de componentes:
ILUSTRACIN 59. DIAGRAMA DE COMPONENTES DEL SPDV
Como vemos en este diagrama, agrupamos por tipo de requerimientos dentro del supermercado:
lo que tiene que ver con la operacin de la tienda dentro del paquete Tienda, lo que tiene que ver
con la operacin de la bodega dentro del paquete Bodega, y lo que tiene que ver con las
operaciones financieras en el paquete Finanzas. Adems, se definieron unas interfaces que
casualmente representan los conceptos del dominio que nos enlazan con dichos paquetes
(CatlogoDeProductos y RegistroDeVentas), lo que por supuesto nos define el tipo de interaccin
que tendr Tienda con los paquetes vinculados (Bodega y Finanzas).
MODELO DE DISEO
El Modelo de Diseo es, por esencia, el principal modelo en la fase de diseo del UP, sin embargo
contiene varios artefactos y tcnicas necesarias para completar el diseo. Principalmente, y lo que
veremos en este curso, el Modelo de Diseo se centrar en 2 artefactos: Diagramas de
Colaboracin y Diagrama de Clases.
98

CONCEPTOS BSICOS
Veamos algunos conceptos bsicos con los que nos toparemos al desarrollar este modelo.
REALIZACIN DE CASO DE USO
Podemos decir que:
LA REALIZACIN DE UN CASO DE USO DESCRIBE CMO SE REALIZA EL
CASO DE USO PARTICULAR EN EL MODELO DE DISEO, EN FUNCIN
DE LOS OBJETOS DEL SISTEMA QUE COLABORAN ENTRE S.
Si analizamos un poco ms esta definicin, lo que queremos decir es que en la realizacin, el

arquitecto se preocupa de describir el diseo de uno o ms escenarios de un caso de uso,
utilizando los objetos del sistema.
De esta forma, los casos de uso nos definen los eventos del sistema, que se muestran
explcitamente en los diagramas de secuencia de eventos (en el anlisis). Luego de eso, estos
eventos pueden ser descritos en contratos de las operaciones del sistema (tambin del anlisis).
As, los eventos del sistema representan los mensajes que inician los diagramas de interaccin, los
cuales representan el modo en el que los objetos interactan para llevar a cabo las tareas
requeridas (realizacin). Por ltimo, la estas interacciones ocurren entre objetos que se inspiran
en las clases conceptuales del modelo de dominio, adems de otras clases de objetos.
RESPONSABILIDAD
Podemos definir inmediatamente que:
LA RESPONSABILIDAD ES UN CONTRATO U OBLIGACIN DE UN
OBJETO EN CUANTO A SU COMPORTAMIENTO.
En efecto, las responsabilidades nos definen ciertos parmetros de las obligaciones que poseen los
objetos dentro del modelo de diseo. En este contexto, se definen 2 tipos de responsabilidades:
Conocer: Con esta responsabilidad, el objeto tiene el conocimiento de los datos privados
encapsulados, objetos relacionados y cosas que puede derivar o calcular (ej: La Venta
conoce la fecha y la hora de la venta, las Lneas de Venta asociadas a la venta y el precio
total de la venta).
Hacer: Con esta responsabilidad, el objeto tiene el poder de hacer algo l mismo como
crear un objeto o realizar un clculo, iniciar una accin en otros objetos y controlar y
coordinar actividades en otros objetos (ej: La Venta es responsable de crear Lneas de
Venta y generar un descuento en el Inventario).
Las responsabilidades del conocer generalmente se pueden inferir desde el modelo de dominio,
ya que es fcil detectarlas con los atributos de las clases conceptuales.
99

Sin embargo, las responsabilidades no son lo mismo que los mtodos, an cuando tienen una
estrecha relacin: los mtodos se implementan para llevar a cabo responsabilidades. En efecto,
para que se cumplan las responsabilidades identificadas, es necesario implementarlas a travs de
uno o ms mtodos que actan solos o colaboran entre ellos. Por ejemplo, para cumplir con la
responsabilidad de la clase Venta que conoce el total de la venta, podemos definir un mtodo
getVenta, el cual utiliza los mtodos getSubtotal de la clase Lnea de Venta quien le entrega el
valor total de cada lnea de venta (precio x cantidad) para calcular el total de la venta.
PATRONES DE DISEO
En el contexto de la tecnologa de objetos, podemos definir que:
UN PATRN ES UN PAR PROBLEMA - SOLUCIN CON NOMBRE QUE
SE PUEDE APLICAR EN NUEVOS CONTEXTOS, CON CONSEJOS ACERCA
DE CMO APLICARLO EN NUEVAS SITUACIONES Y DISCUSIONES
SOBRE SUS COMPROMISOS.
Algo elevado, no?. Pues si analizamos un poco esta definicin, podemos inferir lo que los autores
nos intentan decir. Los patrones son una especificacin analtica reutilizable, con una estructura
que responde a la siguiente:
Nombre
Solucin
Problema [que resuelve]
Ms que especificar ideas nuevas, los patrones pretender codificar conocimiento, estilos y
principios existentes y que se han probado que son realmente vlidos. Esto quiere decir, que entre
ms trillados y extendidos, mejor.
Todos los patrones poseen nombres sugerentes, ya que definen en un solo concepto lo que estn
resolviendo. Es por eso que los autores han procurado en definir estos nombres de una forma
estndar para que los diseadores los utilicen como lenguaje comn. De esta forma,
encontraremos nombres tan esotricos y descriptivos como Experto en Informacin, Creador,
Factora, Variaciones Protegidas, etc.
Los patrones de diseo nos ayudan a determinar las clases conceptuales que son ms aptas o que
realmente compondrn nuestro software. Ahora bien, utilizar cualquiera de las clases
conceptuales es un verdadero crimen, ya que estas clases representan el mundo real, por lo que
no necesariamente corresponden a las clases de software. Es por eso que, como el proceso de
desarrollo es iterativo, se define una regla bsica:
Si hay clases relevantes en el Modelo de Diseo previo, considerar esa como posible clase
de diseo real.
100

Si no hay clases relevantes, o no hay Modelo de Diseo previo, mire en el Modelo de

Dominio e intente utilizar (o ampliar) sus representaciones para inspirar la creacin de las
correspondientes clases de diseo.
He aqu nuestro primer indicio de donde podemos encontrar las clases de diseo. Por otro lado,
para comenzar el diseo por responsabilidades, primero debemos definir las responsabilidades del
Sistema en general para luego delegar o desarrollar responsabilidades internas utilizando los
patrones. Es por eso que podemos relacionar los artefactos convenientemente diciendo:
El Caso de Uso sugiere los eventos del sistema que se muestran explcitamente en los
Diagramas de Secuencia del sistema.
Opcionalmente, podran describirse los detalles de los efectos de los eventos del sistema
en trminos de los cambios de los objetos del dominio en los Contratos de las Operaciones
del sistema.
Los eventos del sistema representan los mensajes que inician los Diagramas de
Interaccin, los cuales representan el modo en el que los objetos interactan para llevar a
cabo las tareas requeridas (Realizacin de Casos de Uso).
Los Diagramas de Colaboracin comprenden la interaccin de mensajes entre objetos de
software cuyos nombres se inspiran algunas veces en los nombres de las clases del
Modelo del Dominio, adems de otras clases de objetos.
Ms adelante, cuando analicemos los patrones de diseo GRASP y GoF veremos cmo esta
definicin se concreta en una lista de reglas que podemos usar al realizar nuestros casos de uso.

artefactos son:
Diagrama de Colaboracin: Diagrama que muestra cules son las operaciones y cmo
interactan entre s los objetos de diseo del sistema.
Diagrama de Clases de Diseo: Diagrama que muestra una visin esttica de las clases del
sistema, representando los tipos de objetos que se requieren para realizar la interaccin
modelada en los diagramas de colaboracin.

travs del uso de tcnicas o recetas. Veamos cada una de ellas en detalle.
DIAGRAMAS DE COLABORACIN
UML nos dice que:
101

EL DIAGRAMA DE COLABORACIN DEFINE GRFICAMENTE PARA UN

ESCENARIO
ESPECFICO
DE
UN
CASO
DE
USO
LAS
RESPONSABILIDADES GENERADAS ENTRE LOS OBJETOS DE DISEO

DEL SISTEMA A PARTIR DE LAS OPERACIONES DEL SISTEMA.
Como podemos ver en la definicin encontramos cosas parecidas a los diagramas de secuencia, y
esto tiene que ver porque vienen de un mismo tipo de diagramas (en UML se conocen como
diagramas de interaccin). Sin embargo, el hincapi de estos diagramas o su motivacin tiene que
ver en disear las responsabilidades delegadas a partir de la operacin de sistema (que ya
conocemos) en los objetos internos del sistema. A este proceso de inferencia de responsabilidades
se le conoce como aplicacin de responsabilidades.
Para hacer estos diagramas, se necesita entender algo de la anatoma de ellos. Es por eso que
definimos la notacin UML de los diagramas a continuacin:
Notacin Diagramas de Colaboracin/Comunicacin

:Objeto
Objeto
:Objeto
Objeto Mltiple
...
Cdigo
n: Expresion
n: [cond] Expresion
n*: [cond] Expresion
Mensaje
Mensaje Condicionado
Mensaje Cclico
}
n: var := mensaje(param: Tipo, ...) : TipoRetorno
Sintaxis de los mensajes
ILUSTRACIN 60. NOTACIN DE LOS DIAGRAMAS DE COLABORACIN
Debemos destacar que los diagramas de colaboracin los utilizaremos para describir las
operaciones del sistema identificadas en los diagramas de secuencia con el detalle de operacin y
diseo interno tal como ya lo hemos dicho. De esta manera, tendremos diagramas por cada una
de las operaciones.
Un ejemplo de diagrama podemos verlo en el caso del TPDV (caja de supermercado). Si elegimos
la operacin de agregarProducto(cod, cant) en donde se agrega a la venta en curso una cantidad
determinada de cierto cdigo de producto podemos obtener el siguiente diagrama:
102

ILUSTRACIN 61. DIAGRAMA DE COLABORACIN DE INGRESAR PRODUCTO PARA TPDV
Este diagrama es el reflejo de la lista de postcondiciones que se definen en el contrato de la

operacin indicada. Estas postcondiciones son:
Que se haya encontrado una instancia p de tipo Producto en c (de tipo Catalogo) cuyo
atributo codigo tenga el mismo valor que el parmetro cod (responsabilidades 2 y 3).
Que se haya creado una instancia ldv de tipo LineaDeVenta (responsabilidad 5).
Que se haya asociado p a ldv (responsabilidad 7).
Que se haya cambiado el atributo cantidad de ldv por el valor del parmetro cant
(responsabilidad 6).
Que se haya asociado ldv a v (responsabilidad 4, solo por entregar el control de la creacin
a Venta).
La intensin de mostrar el diagrama no es dar la frmula de cmo se realizan sino ms bien ilustrar
la forma cmo se utiliza la notacin anteriormente mostrada, ya que debemos seguir un proceso
con el cual obtendremos este diagrama a partir del uso de patrones de diseo.
PATRONES DE DISEO GRASP
Los Patrones Generales de Software para la Asignacin de Responsabilidades (GRASP) no son
ms que un conjunto patrones de diseo que nos ayudarn a definir nuestras responsabilidades,
El programa StarUML no permite poner mensajes sin secuencia, por lo que el diagrama qued con la
operacin del sistema indicada por la responsabilidad nmero 1. Sin embargo, segn lo visto en clases, no es
relevante.
103

es decir, describen los principios fundamentales del diseo de objetos y la asignacin de

responsabilidades, expresados en forma de patrones.
La asignacin habilidosa de responsabilidades es extremadamente importante en el diseo de
objeto, ya que a menudo tiene lugar durante la creacin de los diagramas de interaccin, tal como
dijimos antes, pero adems con mayor seguridad se realizar durante la programacin. A travs de
patrones, este trabajo se hace mucho ms fcil, ya que no requieren de una validacin antes de
ser implementados porque se est tan seguro de su validez gracias a su vasta utilizacin en
diferentes problemas.
En un principio, analizaremos algunos patrones bsicos y que se refieren a aspectos
fundamentales del diseo. Sin embargo, existen otros que podran aparecer durante el estudio
posterior.
Para la definicin de cada patrn utilizaremos la pseudo-notacin sugerida anteriormente
(Nombre, Solucin, Problema [que resuelve]).
PATRN DE EXPERTO DE INFORMACIN
NOMBRE: EXPERTO DE INFORMACIN (O EXPERTO)
Solucin: Asignar una responsabilidad al experto en informacin la clase que tiene la

informacin necesaria para realizar la responsabilidad.
Problema: Quin debera ser el responsable de conocer una informacin particular?
La informacin es una parte importante de los objetos, ya que definen sus caractersticas y su
naturaleza. Es por ello que identificar el objeto que realmente debe contener una informacin
particular se convierte en una preocupacin que durante la realizacin de los casos de uso debe
ser resuelta. De esta manera, al identificar estos objetos, estaremos definiendo informacin
relevante para el diagrama de clases de diseo.
Por ejemplo, veamos el contrato de la operacin ingresarProducto:
104


Responsabilidad: Ingresar un producto representado por cod a la venta en
curso.
Ref. Cruzadas: CU1. Realizar Venta
Notas:
Excepciones: - Si cod no existe, error.
Salida: CO2. ingresarProducto(cod : CodigoBarras, cant : Int)
Operacin:
Precondiciones: - Exista una instancia v de tipo Venta.
- Exista una instancia c de CatalogoDeProductos.
Postcondiciones: - Se haya encontrado una instancia p de Producto en el
catlogo c que tenga como valor del atributo cdigo
igual al valor cod entregado.
- Se haya creado una nueva instancia ldv de
LneaDeVenta.
- Se haya asociado p a ldv.
- Se haya cambiado el valor cantidad de ldv por n
entregado.
- Se haya asociado ldv a v.
ILUSTRACIN 62. CONTRATO DE OPERACIN INGRESAR PRODUCTO DEL SPDV
Para poder encontrar un producto dentro del catlogo, es importante saber quin tiene los
cdigos de cada producto de manera de compararlo con el cdigo entregado por el cajero a travs
de la caja (lector de cdigos o teclado).
De esta manera, preguntamos entonces quin debe ser el responsable de conocer el cdigo de
un producto?. Parece una pregunta sencilla de responder, porque el modelo conceptual de este
problema lo plantea de forma explcita, pero en realidad debemos hacer la pregunta de todas
maneras. La respuesta, entonces, queda claramente respondida diciendo que la clase Producto
(que en este caso es clase conceptual) es el responsable de saber cul es su propio cdigo, ya que
es parte de su definicin desde los requisitos. Sin embargo, como la operacin llega a la caja,
debemos delegar la responsabilidad de realizar la bsqueda del producto que tenga el cdigo
indicado en el contrato a la clase que trabaja ms estrechamente con el producto: la clase
Catlogo.
De esta manera, el diagrama se comienza a dibujar de la siguiente forma:
105

ILUSTRACIN 63. DELEGACIN DE RESPONSABILIDAD DE EXPERTO DE INFORMACIN
A pesar de que a travs del patrn es muy claro en asignar las responsabilidades de experto,
existen algunos casos en los cuales la solucin propuesta por ste vaya en contra de otros
patrones de asignacin de responsabilidad. Es por eso que es importante tener una visin general
de todos los patrones antes de comenzar a dar responsabilidades indiscriminadamente (si lo
vemos recursivamente, es una gran responsabilidad entregar responsabilidades). Los buenos
diseadores no son aquellos que se cien al pie de la letra a recetas, sino ms bien, aquellos que
poseen la visin de considerar todos los factores del problema para disear la mejor de las
soluciones, o al menos la que mejor se ajusta a l.
PATRN DE CREADOR
NOMBRE: CREADOR DE INSTANCIAS (O CREADOR)
Solucin: Asignar la responsabilidad a la clase B de crear instancias de la clase A si cumple uno o

ms de los siguientes casos:
B agrega objetos de A
B contiene objetos de A
B registra instancias de objetos de A
B utiliza ms estrechamente objetos de A
B tiene los datos de inicializacin que se pasar a un objeto de A cuando sea creado
B es un creador de los objetos A
Si se puede aplicar ms de una opcin, inclnese por una clase B que agregue o contenga la clase
A.
Problema: Quin debera ser el responsable de la creacin de una nueva instancia de alguna
clase?
La creacin de instancias es una actividad muy comn en sistema orientados a objetos, por lo que
esta responsabilidad parecera algo trivial. Sin embargo, una asignacin adecuada de ella puede
106

hacer que nuestros diseos puedan soportar bajo acoplamiento, mayor claridad y alta
reutilizacin.
Por ejemplo en el mismo ejemplo de ingresarProducto, podemos buscar al creador de instancias
de la clase LineaDeVenta.
Si solo nos basamos en lo que dice el contrato y continuando con cada postcondicin, la creacin
de la lnea de venta quedara en manos de Caja. Si aplicamos las condiciones del patrn
tendramos que:
Caja tiene los datos de inicializacin de LineaDeVenta (producto y cantidad)
Sin embargo esto no es suficiente ya que debemos cumplir con al menos 2 caractersticas listadas.
Si seguimos bajando en el diagrama de clases conceptuales, podemos consultar por Venta, ya que
por naturaleza es contenedor de LineaDeVenta. Listemos las caractersticas que cumple Venta
para ser creador:
Venta contiene objetos de LineaDeVenta
Venta utiliza estrechamente objetos de LineaDeVenta (de hecho lo requiere para varias
operaciones del sistema)
Venta no tiene los datos de inicializacin de LineaDeVenta, pero puede tenerlo (por
delegacin de la caja)
De esta forma, podemos rpidamente hacer que Venta tenga 3 caractersticas convirtindola en
un mejor candidato para ser creador de LineaDeVenta. Si tratamos de buscar otro no
encontraremos una clase que tenga mejores condiciones, as que el diagrama sera el siguiente:
ILUSTRACIN 64. DELEGACIN DE RESPONSABILIDAD DE CREADOR DE INSTANCIAS
107

Al igual que todos los patrones que estamos viendo, ellos definen una gua ms que una receta,
por lo que el arquitecto es quien definir si lo que se presume a travs del patrn es en realidad un
buen candidato. Esto puede pasar cuando analizamos el patrn de Creador en casos en donde
requerimos utilizar instancias recicladas.
PATRN DE CONTROLADOR
NOMBRE: CONTROLADOR
Solucin: Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una
clase que representa una de las siguientes opciones:
Representa el sistema global, dispositivo o subsistema (controlador de fachada).
Representa un escenario de caso de uso en el que tiene lugar el evento del sistema
(controlador de sesin o de caso de uso).
A menudo este es nombrado como <Nombre>Controlador, <Nombre>Manejador o
<Nombre>Coordinador.
Problema: Quin debe ser responsable de gestionar un evento de entrada al sistema?
Antes que todo, un evento de entrada al sistema no es ms que un evento generado por un actor
externo. Se asocian con las operaciones del sistema que son las respuestas a esos eventos, tal
como se relacionan los mensajes y los mtodos.
Es importante tener en claro que las clases de tipo Controlador se refiere a clases que no
pertenecen a la interfaz del usuario (la caja), sino que define el mtodo para la operacin del
sistema.
Siguiendo con el ejemplo de ingresarProducto, tenemos que la operacin del sistema debe ser
recibida por alguien. En este caso tenemos 2 alternativas:
a) Caja es la clase que representa el sistema completo (en esta caso la clase sera
CajaControlador)
b) Venta es la clase que representa el CU Registrar Venta (y en este caso quedara como
VentaControlador)
La eleccin es del arquitecto, por lo que la mejor opcin depende de la complejidad. Si el sistema
es grande, a lo mejor separar el controlador lo hace ms especializado para cada uno de los
subproblemas, pero si no, si el problema no es muy grande, un controlador nico es ms sencillo
de implementar.
En este caso quedara el diagrama:
108

ILUSTRACIN 65. IDENTIFICACIN DEL CONTROLADOR DE LAS OPERACIONES DEL SISTEMA
Como vemos en el diagrama, en realidad lo nico que estamos incorporando es la primera clase,
pero sin cambiar responsabilidades internas, an cuando es ms recomendable el anlisis antes de
cualquier otro patrn. Adems, cuando analicemos las otras operaciones, lo primero que
deberemos preguntar es si el controlador anteriormente identificado aplica a las nuevas
operaciones o no, por lo general si (sobre todo si representa al sistema completo como el de
ingresarProducto).
De los patrones que veremos en este curso, este es uno de los complejos de utilizar, porque posee
muchas aristas. Sin embargo, existen algunas recomendaciones al respecto que pueden ser tiles
de analizar:
Siempre utilice controladores de bajo acoplamiento y alta cohesin, algo que
aprenderemos en los siguientes patrones.
No trate de saturar los controladores con funciones de todo tipo. Recuerde que puede
utilizar controladores modulares dependiendo del caso de uso o componente
determinada.
Antes de crear una clase controlador, siempre verifique que su diseo ya no tiene una que,
en forma innata, puede tomar ese rol.
No entregue funciones del controlador a la interfaz del usuario.
PATRN DE ALTA COHESIN
NOMBRE: ALTA COHESIN
Solucin: Asignar una responsabilidad de manera que la cohesin permanezca alta.

Problema: Cmo mantener la complejidad manejable?
Antes de poder responder a esta pregunta, nos preguntamos qu es la cohesin. Este concepto
tiene relacin a la fuerza con la que se relacionan y el grado de focalizacin de las
responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas y
que no hace gran cantidad de trabajo tiene una alta cohesin.
Para nosotros, es mucho ms importante que nuestros objetos posean una alta cohesin, ya que
los objetos una baja cohesin nos complica ms el problema. Los objetos de baja cohesin son
difciles de entender, reutilizar, mantener y delicados, es decir, constantemente afectados por los
cambios.
109

Por ejemplo, en el caso de la operacin ingresarProducto, tenemos que la complejidad de las

clases se mantienen en un nivel bajo, ya que cada una de las responsabilidades asignadas son de
una naturaleza innata a la concepcin de la clase respectiva (el controlador solo controla, la Venta
solo crea LineaDeVenta, el Catlogo solo consulta Productos, etc).
Existen en la literatura muchas recomendaciones con respecto a la cohesin en el diseo
orientado a objetos, es por eso que debe ser un factor muy importante cuando se trabajo con l.
Sin embargo, y como ya hemos querido destacar a travs de estas pginas, el nivel de cohesin
debe ser considerado siempre con la compaa de otros patrones como el de acoplamiento y
experto. De hecho, el ejemplo utilizado, adems de ser de Alta Cohesin, cumple con la
condicin de Bajo Acoplamiento segn lo que vamos a ver a continuacin.
PATRN DE BAJO ACOMPLAMIENTO
NOMBRE: BAJO ACOPLAMIENTO
Solucin: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo.

Problema: Cmo soportar bajas dependencias, bajo impacto al cambio e incremento de la
reutilizacin?
Grandes preguntas que todos nos hacemos cuando diseamos software. Lo primero es entender
que acoplamiento se refiere a una medida de fuerza con que un elemento est conectado a, tiene
conocimientos de y confa en otros elementos. En otras palabras, un bajo (o dbil) acoplamiento
de un elemento es cuando ste no dependen mucho de otros elementos.
De esta forma, si tuviramos elementos con alto acoplamiento, se presentan problemas de que los
cambios en las clases relacionadas fuerzan a cambios locales, son difciles de entender en forma
aislada y de reutilizar puesto que su uso requiere la presencia adicional de las clases de las que
depende.
Por ejemplo, tal como dijimos en el patrn anterior, la asignacin de responsabilidades de
ingresarProducto, adems de ser de alta cohesin, es de bajo acoplamiento en algunas partes, ya
que la dependencia de clases que hay entre el Controlador y las clases relacionadas con la venta
(Venta LineaDeVenta Producto) y la coleccin de productos (Catlogo Producto) es baja.
En estos casos de hecho son independientes entre s, porque una de ellas no afecta a la otra.
Al igual como hemos mencionado, es importante utilizar este patrn en relacin a los dems, ya
que, como vimos en el ejemplo, estn estrechamente relacionados.
Por otro lado, algunos indicadores de acoplamiento en algunos lenguajes se pueden detectar en
los siguientes casos:
A tiene un tributo que hace referencia a una instancia de B.
Un objeto de A invoca los servicios de un objeto de B.
A tiene un mtodo que referencia a una instancia de B, o al propio B de alguna forma
(parmetro o tipo de retorno).
110

A es una subclase directa o indirecta de B.

A es una interfaz y B implementa esa interfaz.
Estos indicadores deben ser considerados solo como eso, ya que si fusemos extremadamente
rigurosos, la orientacin al objeto no podra ser realizada, ya que no usaramos interfaces,
asignaciones de objetos, etc. Es por eso que el diseador debe tener en cuenta estos detalles para
mantener un Bajo Acoplamiento pero nunca intentar eliminarlo (usar lo mnimo necesario para
el sistema en desarrollo).
Un tema particular en donde el acoplamiento no es malo es cuando se utilizan libreras estables
y extendidas, es decir, aquellas libreras en donde estamos seguros que si cambia algo funcional
dentro, nuestros desarrollos no se vern afectados mayormente.
OTROS PATRONES GRASP
Los 5 patrones antes vistos corresponden a los bsicos que se utilizan en el GRASP para
determinar responsabilidades en las realizaciones. A continuacin enumeraremos otros patrones
que son importantes ya que entregan informacin o definen tcnicas para la implementacin y
que complementan nuestro anlisis de operaciones.
NOMBRE: POLIMORFISMO
Solucin: Cuando una responsabilidad posee varias alternativas para comportamientos similares,
se asignarn a los tipos en que el comportamiento presenta las variantes.
Problema: Cmo manejar las alternativas basadas en el tipo?
NOMBRE: FABRICACIN PURA
Solucin: Asignar un conjunto altamente cohesionado de responsabilidades a una clase artificial

que no pertenece al dominio. De esta manera, lo que estamos haciendo es crear un nuevo tipo o
clase que no tiene otra funcin ms que mantener nuestro sistema altamente cohesivo, de bajo
acoplamiento y potenciando la reutilizacin de componentes.
Problema: Quin es el responsable de mantener la alta cohesin y el bajo acoplamiento cuando
ya no tenemos ms alternativas en nuestro modelo?
Cuando para el problema planteado el uso de las clases del dominio nos provoca que nuestro
modelo se est transformando en uno con mala cohesin y acoplamiento, es necesario buscar una
solucin an cuando esta no se encuentre en el alcance conceptual.
NOMBRE: INDIRECCIN
Solucin: Se asigna la responsabilidad a un objeto intermedio, de manera tal que medie entre
componentes o servicios para que no terminen directamente acoplados. De esta manera ese
intermediario crea una indireccin entre el resto de los componentes o servicios.
Problema: De qu manera podemos desacoplar los objetos para as mantener una potencial
reutilizacin y un bajo acoplamiento? Quin debe tener la responsabilidad de mediar para
mantener la indireccin entre las componentes?
111

NOMBRE DEL PATRN: NO HABLES CON EXTRAOS

Solucin: Se asigna la responsabilidad a un objeto directo del cliente para que colabore con un
objeto indirecto, de modo que el cliente no necesite saber nada del objeto indirecto. Este patrn
establece que en un mtodo, los mensajes solo deberan enviarse a los siguientes objetos:
El objeto this.
Un parmetro del mtodo.
Un atributo de this.
Un elemento de una coleccin que sea atributo de this.
Un objeto creado al interior del mtodo.
De esta manera, los objetos directos con conocidos del cliente, en cambio los indirectos son
extraos, y un cliente solo debera tener conocidos, pero no extraos. Por lo tanto, con este
patrn estamos no acoplando el conocimiento de los objetos indirectos ni las representaciones
internas de los objetos directos al cliente.
Problema: Quin debe ser el responsable de evitar conocer la estructura de los objetos
indirectos?
Si un objeto cliente conoce la estructura interna de otros objetos presenta alto acoplamiento. Si
un objeto cliente conoce las conexiones y representacin interna de otros, cmo podr entonces
hacerlo sin acoplarse al conocimiento de la estructura de su objeto servidor o de los
indirectos?
PATRONES DE DISEO GOF
Los Patrones de Diseo GoF (Gang of the Four7) son un grupo de patrones que los autores
actualmente utilizan en su mayora como la base para el diseo. Si bien es cierto, GRASP daba
algunos indicios de cmo hacer el diseo OO, con GoF se incluyen conceptos mucho ms
especficos como constructores, adaptadores, puentes, entre otros y que son muy tiles al
momento de disear un sistema orientado al objeto.
A diferencia de GRASP, los patrones GoF se describen en base a una estructura un poco ms
compleja, pero la base es la misma, y es la siguiente:
Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la
comunidad (normalmente se expresa en ingls).
Clasificacin del patrn: creacional, estructural, de comportamiento o de sistema.
Intencin: Qu problema pretende resolver el patrn?
Gang of The Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
112

Tambin conocido como: Otros nombres de uso comn para el patrn.
Motivacin: Escenario de ejemplo para la aplicacin del patrn.
Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn.
Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el
patrn.
Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que

participan en el patrn.
Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes.
Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin

del patrn.
Im<plementacin: Tcnicas o comentarios oportunos de cara a la implementacin del

patrn.
Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn.
Usos conocidos: Ejemplos de sistemas reales que usan el patrn.
Patrones relacionados: Referencias cruzadas con otros patrones.
Para que no entremos en tanto detalle veamos ahora una pequea descripcin de los patrones
GoF segn su clasificacin:
PATRONES CREACIONALES
Los patrones de diseo creacionales son todos aquellos que se aplican en la creacin de instancias
de objetos en general. Estos patrones son:
Abstract Factory (Fbrica abstracta): Permite trabajar con objetos de distintas familias de
manera que las familias no se mezclen entre s y haciendo transparente el tipo de familia
concreta que se est usando.
Builder (Constructor virtual): Abstrae el proceso de creacin de un objeto complejo,

centralizando dicho proceso en un nico punto.
Factory Method (Mtodo de fabricacin): Centraliza en una clase constructora la creacin

de objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica para
elegir el subtipo que crear.
Prototype (Prototipo): Crea nuevos objetos clonndolos de una instancia ya existente.
Singleton (Instancia nica): Garantiza la existencia de una nica instancia para una clase y la
creacin de un mecanismo de acceso global a dicha instancia.
113

PATRONES ESTRUCTURALES
Los patrones de diseo estructurales define objetos como estructuras de control que sirven en
diferentes formas. Estos patrones incluyen:
Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de
otro modo no podra utilizarla.
Bridge (Puente): Desacopla una abstraccin de su implementacin.
Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple
se tratase.
Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente.
Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o
grupo de interfaces de un subsistema.
Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen
idntica informacin.
Proxy: Mantiene un representante de un objeto.
PATRONES DE COMPORTAMIENTO
Los patrones de diseo de comportamiento definen algunos tipos de comportamientos de los
objetos y entregan informacin de cmo realizar dichos comportamientos. Estos patrones son:
Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben

llevar los mensajes para que los objetos realicen la tarea indicada.
Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha

operacin sin necesidad de conocer el contenido de la misma.
Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as
como las herramientas necesarias para interpretarlo.
Iterator (Iterador): Permite realizar recorridos

independientemente de la implementacin de estos.
Mediator (Mediador): Define un objeto que coordine la comunicacin entre objetos de

distintas clases, pero que funcionan como un conjunto.
Memento (Recuerdo): Permite volver a estados anteriores del sistema.
Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma

que cuando un objeto cambie de estado se notifique y actualicen automticamente todos
los objetos que dependen de l.
State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie
su estado interno.
114
sobre
objetos
compuestos

Strategy (Estrategia): Permite disponer de varios mtodos para resolver un problema y

elegir cul utilizar en tiempo de ejecucin.
Template Method (Mtodo plantilla): Define en una operacin el esqueleto de un

algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases
redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarqua de clases sin
modificar las clases sobre las que opera.
PATRONES DE SISTEMA
Los patrones de diseo de sistema definen algunas caractersticas que dependen de la
arquitectura y que deben ser reflejadas en las realizaciones. Estos patrones son:
MVC (Modelo Vista Controlador): Divide un componente o un subsistema en tres partes

lgicas: modelo, vista y controlador, facilitando la modificacin o personalizacin de cada
parte.
Session (Sesin): Ofrece una forma de que los servidores de sistemas distribuidos sean
capaces de distinguir los clientes, permitiendo que las aplicaciones asocien el estado con la
comunicacin entre el cliente y el servidor.
Worker Thread (Thread trabajador): Mejora la productividad y minimiza la latencia media.
Callback (Retrollamada): Permite que un cliente se registre en un servidor para ciertas

operaciones. De esta forma, el servidor puede notificar al cliente cuando la operacin ha
finalizado.
Succesive Update (Actualizacin Sucesiva): Ofrece a los clientes una forma de recibir
actualizaciones continuas.
Router (Encaminador): Desacopla mltiples fuentes de informacin de los objetos de esa

informacin.
Transaction (Transaccin): Agrupa una coleccin de mtodos de forma que todos ellos
finalicen correctamente o fallen de forma colectiva.

El resultado del diseo (y que por supuesto es de todo nuestro trabajo en este curso) por
excelencia es el Diagrama de Clases de Diseo (DCD). Por eso, comenzaremos diciendo que:
LOS DIAGRAMAS DE CLASES DE DISEO SON FIGURAS QUE
MUESTRAN LA ESPECIFICACIN DE LAS CLASES E INTERFACES DE
SOFTWARE QUE PARTICIPAN EN LA SOLUCIN.
115

A partir de esta definicin podemos entender, por lo tanto, que el DCD contiene realmente el
software como debe ser programado. En ellos encontramos toda la especificacin necesaria para
la implementacin, ya que en ellos se describen los atributos, tipos relevantes y mtodos que
responden a las responsabilidades que cada clase posee.
As, lo que encontraremos en este detalle es:
Clases, asociaciones y atributos
Interfaces, con sus operaciones y constantes
Mtodos
Tipos de datos
Navegabilidad
Dependencias
Por lo tanto, el nivel de detalle es alto porque a partir de este diagrama se deben escribir las
estructuras de clases que compondrn el sistema a implementar, y tambin gran parte de la lgica
interna de cada uno de los mtodos. De esta manera, la construccin del sistema est muy
completa, dejando poco trabajo para la fase de implementacin real.
La notacin que se utiliza en estos diagramas es muy parecida a la que usamos en el diagrama de
clases conceptuales. Sin embargo, es importante diferenciarlos, ya que en los DCD estamos
especificando las clases de software que sern implementadas y no solo conceptos que
representan elementos del negocio. Esta notacin UML es la siguiente:
116

Notacin Diagramas de Clases

metaclass
Nombre
-a
Metaclase
Asociacin
1..1
0..*
-a
Nombre
-atrib : byte
Agregacin
Clase
1..1
0..*
-a
+oper() : char
Composicin
1
Objeto
0..*
Objeto/Instancia
Herencia/Generalizacin
datatype
TipoDeDatos
Tipo de Dato
Implementacin de Interfaz
interface
Interfaz
Interfaz
Interfaz
Dependencia
Param
Clase
Tipo Parametrizado
Nota
Paquete
Paquete
{}
Restriccin
ILUSTRACIN 66. NOTACIN PARA LOS DIAGRAMAS DE CLASES DE DISEO
Veamos un ejemplo en el cual se nota la diferencia entre el modelo conceptual y las clases de
diseo. Tomemos la asociacin que hay entre Caja y Venta en el problema del supermercado. Para
el diagrama de clases conceptuales, tenemos lo siguiente:
ILUSTRACIN 67. ASOCIACIN A NIVEL DE CLASES CONCEPTUALES
Despus de las realizaciones, este diagrama se convierte en algo ms parecido a:
ILUSTRACIN 68. ASOCIACIN A NIVEL DE CLASES DE DISEO
117

Ms adelante descubriremos notacin adicional para otro tipo de situaciones especficas y que se
relacionan con nuevos patrones de asignacin de responsabilidades. Slo es importante recordar:
Considerar cul es la audiencia del DCD nos dar el nivel de detalle.
El DCD es un apoyo y una base para la implementacin, por lo es necesario evitar el detalle
exhaustivo cuando ste pueda provocar confusin.
TCNICA DE CONSTRUCCIN DE LOS DCD
En el proceso normal de generacin del DCD, todo comienza por identificar las clases de diseo a
partir de los diagramas de interaccin. An cuando esto ya lo hemos hecho de manera parcial, es
bueno que reunamos toda la informacin en un solo diagrama.
PASO 1: IDENTIFICACIN DE LAS CLASES DE DISEO Y SUS ATRIBUTOS
Lo primero que hacemos es dibujar las clases que se encuentran en los diagramas de interaccin y
les ponemos los atributos identificados en el Modelo de Dominio:
ILUSTRACIN 69. IDENTIFICACIN DE LAS CLASES DE DISEO
IDENTIFICANDO LOS NOMBRES DE LOS MTODOS DE LAS CLASES DE DISEO
Una vez que eso se encuentra dibujado, comenzamos aadiendo los nombres de los mtodos de
manera anloga a las responsabilidades identificadas en las realizaciones. De esta forma, los
mensajes que encontramos en los diagramas de interaccin se convierten en mtodos fsicos de la
clase:
ILUSTRACIN 70. IDENTIFICACIN DE UN MTODO A PARTIR DE UNA COLABORACIN
118

De esta forma, nuestro DCD va creciendo y se convierte en:
ILUSTRACIN 71. IDENTIFICACIN DE MTODOS DE LAS CLASES
Algo muy importante al bautizar los mtodos es tener en cuenta algunas cuestiones que definen
un buen diseo:
La instanciacin o inicializacin de objetos no es una cuestin estndar para todos los
lenguajes orientados al objeto, por lo que generalmente se omiten en los DCD (en Java,
nos referimos a los constructores).
Cuando se hace referencia a la obtencin de valores de un objeto (mtodo de obtencin o
de acceso) o al cambio de valores de un objeto (mtodo de mutacin o de cambio) se
utiliza generalmente el nombre como get/set ms el atributo que acceden. Por
ejemplo, existe el mtodo getCodigo en la clase Producto que entrega el total de la venta.
Sin embargo, no se requiere especificar en el DCD todos los mtodos accesadores o
mutadores, ya que implicara tener una lista muy grande de mtodos que son irrelevantes
para el diseo, es por eso que solo aparecen aquellos que son relevantes o que generan
algn valor para el diseo.
La sintaxis que se utilice en los DCD debera corresponder a la sintaxis bsica de UML y no
a alguna en particular del lenguaje de implementacin. Idealmente la traduccin se debe
realizar cuando se implemente el cdigo que representa el diseo deseado. Sin embargo,
en ninguna parte UML niega el uso de otra sintaxis en sus diagramas, por lo que queda a
criterio del diseador finalmente.
AGREGANDO INFORMACIN DE LOS TIPOS DE DATOS
La informacin de tipos de datos en los DCD es relevante, ya que agrega informacin de bajo nivel
para los desarrolladores o para las herramientas que generan el cdigo en forma automtica. Sin
embargo, la decisin de agregar los tipos de datos y los parmetros a los mtodos pasa por una
definicin del diseador considerando que:
Si se est utilizando una herramienta CASE que genera cdigo en forma automtica, el
detalle de los tipos debe ser exhaustivo y concordante con el lenguaje que se utilizar en
la implementacin.
119

Si el DCD es solo para que lo vean los desarrolladores, agregar muchos detalles de tipos y
parmetro podra complicar el modelo ms que aclararlo porque se convierte en mucho
ruido para ellos. En este caso la recomendacin es utilizar tipos de datos lgicos que
representen la informacin a guardar (por ejemplo, Texto, Nmero, CdigoDeBarras, etc).
Sin embargo, tomar la decisin en si agregar o no el detalle debe ser considerado la audiencia que
deber utilizar este modelo, ya que si para la audiencia son obvios algunos de los tipos y
parmetros del DCD, es posible omitirlos.
ASOCIACIONES Y NAVEGABILIDAD EN LOS DCD
Como es de esperar, el DCD no est completo si no asociamos las clases entre ellas. Estas
asociaciones son similares y contrastadas con las que generamos en el Modelo Conceptual, ya que
responden al mismo principio con las que se generaron esas. De esta forma, antes de poner una
asociacin, es necesario preguntarse qu asociaciones se requieren para satisfacer la visibilidad
y las necesidades de memoria actuales que se indican en los diagramas de interaccin?. Esta
visibilidad requerida es necesaria en los siguientes casos comunes:
Cuando A enva un mensaje a B.
Cuando A crea una instancia de B.
Cuando A necesita mantener una conexin a B.
Una vez que se ha encontrado la asociacin, es necesario adems darle el concepto de
navegabilidad. Con esto, se le da un nivel de dependencia a la asociacin, lo que se traduce en
visibilidad de atributo:
ILUSTRACIN 72. AGREGANDO ASOCIACIONES CON NAVEGABILIDAD
De esta forma, CajaControlador tiene una visibilidad de atributo de Venta, lo que se traduce que la
clase CajaControlador posea un atributo de tipo Venta. Pero dnde queda ese atributo en el
DCD?. Es posible que opcionalmente se ponga ese atributo sobre la flecha hacia el lado del tipo de
destino (Venta), pero no es absolutamente necesario ya que se puede nombrar posteriormente en
la implementacin.
En nuestro ejemplo de la caja del supermercado, el DCD se convierte en:
120

ILUSTRACIN 73. DIAGRAMA DE CLASES DE DISEO PARCIAL PARA EL SPDV
Como ven en el ejemplo, el DCD es bastante simple de ver, sin embargo se ha construido a partir
de los diagramas de interaccin de las realizaciones. No se incluyeron los tipos de datos ni
parmetros de mtodos, porque la audiencia es acadmica y no nos entrega un valor agregado
ms que confundirnos en el modelo de diseo.
Ntese adems que el DCD que es mucho menos extenso que el modelo conceptual, porque se
basa netamente en el diseo del sistema que responde a los eventos del mismo.
RELACIONES DE DEPENDENCIA ADICIONALES
As mismo como la navegabilidad representa la visibilidad de atributo, debemos de alguna forma

representar la visibilidad de parmetro, local o global. Esto se hace con flechas punteadas que
indican cules son las clases que requieren esa relacin. De esta forma, nuestro diagrama ejemplo
pasa a conformarse de la siguiente forma:
Se han omitido los tipos de datos en el diagrama de manera totalmente intencional, para la visin
completa de ste en el documento.
121

ILUSTRACIN 74. DIAGRAMA DE CLASES DE DISEO REFINADO PARA EL SPDV
En el ejemplo, aparece una visibilidad de parmetro entre Venta y Producto, ya que el mtodo
crearLineaDeVenta requiere una instancia de Producto para ser asociada en LineaDeVenta (en
donde si est la visibilidad de atributo explcita en el DCD).
VISIBILIDAD DE ATRIBUTOS Y MTODOS
Hasta ahora todos los diagramas que hemos visto muestran unos pequeos signos en su
definicin. Estos signos no son adornos ni tampoco es casualidad que ah estn, sino que
representan la visibilidad que tienen los atributos y la visibilidad que tienen los mtodos en el
modelo.
UML no obliga a utilizar esto modificadores, pero nos daremos cuenta que algunos CASE los ponen
por defecto como - a los atributos y + a los mtodos. Por qu es esto?
El modificador - indica que el atributo o mtodo es privado, esto quiere decir que el
alcance que tiene es solo dentro de la clase en la cual est definido.
El modificador + indica que el atributo o mtodo es pblico, lo que significa que el
alcance que tiene es dentro y fuera de la clase.
Por defecto en UML, si estos modificadores no se especifican en el DCD, se supondr que los
atributos son privados y los mtodos son pblicos.
CUERPO DE LOS MTODOS
Por ltimo, y opcionalmente, es posible utilizar cuerpos de cdigo en los mtodos que
especifiquen cmo se implementan con pseudocdigo o algn lenguaje en particular. Sin
embargo, debemos recordar que todo el detalle que pongamos en el DCD es para apoyar la etapa
de implementacin y no debe significar mayor complejidad para los desarrolladores.
Desde el punto de vista de notacin, el cuerpo de los mtodos va sin la firma del mtodo
(encabezado) y solo se describe el contenido, de la siguiente forma:
122

ILUSTRACIN 75. REPRESENTACIN EN LA CODIFICACIN DE LA CLASE
TEMAS COMPLEMENTARIOS
GENERALIZACIN
La generalizacin se refiere a la definicin de subtipos a raz de una definicin similar respecto a

diferentes objetos. Esta definicin se puede utilizar a partir del modelo conceptual, sin embargo
tampoco es tarde utilizarlo en el diseo.
Para la notacin se agrega la utilizacin de un nuevo tipo de asociacin.
La clase B es un subtipo de la clase A cuando sta ltima posee
caractersticas comunes, pero la primera posee caractersticas y/u
operaciones que le permiten realizar acciones particulares para dicha
clase. En ese sentido, la definicin de la clase B contiene el 100% de las
caractersticas y operaciones de A, pero no al revs.
Por ejemplo, si definimos los tipos de pago en el punto de venta, podramos decir que existe una
jerarqua de tipos respecto a las clases de pagos que se pueden utilizar (PagoEnEfectivo,
PagoConTarjeta, PagoConCheque). De esta forma el modelo quedara definido como:
ILUSTRACIN 76. GENERALIZACIN DE LOS TIPOS DE PAGO EN EL SPDV
Existe una regla simple para definir si existe una razn para definir un subtipo.
123

El subtipo tiene algn atributo particular de inters.

El subtipo tiene alguna operacin particular de inters.
El subtipo se opera con un concepto diferente para el subtipo, en relacin a lo relevante
de ste.
El subtipo representa alguna entidad fsica que se comporta en manera diferente al
supertipo.
AGREGACIN
La agregacin se utiliza cuando existe una dependencia directa entre dos clases, de manera de que
la clase dependiente no puede existir sin su generadora.
Para la notacin se utiliza un rombo pintado indicando la clase generadora:
La clase A agrega uno o ms objetos de B.
Es importante definir la agregacin cuando sta corresponda. Por ejemplo en el caso del Punto de
Venta podemos encontrar agregacin en algunas clases del DCD como Venta y LineaDeVenta, ya
que no pueden existir referencias a una LineaDeVenta si no existe la Venta primero. Es por eso que
la relacin queda as:
ILUSTRACIN 77. AGREGACIN DE PRODUCTOS EN EL SPDV
COMPOSICIN
La composicin se utiliza cuando no existe una dependencia directa entre dos clases, pero si se
requiere tener una referencia de la otra.
Para la notacin se utiliza un rombo en blanco indicando la clase que necesita tener relacin:
La clase A compone uno o ms objetos de B.
Al igual como lo hicimos con la agregacin, la definicin se debe realizar correctamente solo
cuando una de ellas requiere tener una referencia de la otra en su definicin (atributos). Por
ejemplo en el caso del Punto de Venta podemos encontrar composicin en el DCD entre Catalogo
y Producto, ya que los productos de la tienda siempre deben existir por si solos, pero el catlogo
es solamente el medio para que puedan acceder a l. Es por eso que la relacin queda as:
124

ILUSTRACIN 78. COMPOSICIN DE LNEAS DE VENTA EN EL SPDV

Ahora continuaremos la realizacin del ejemplo del sistema electrnico de ficha de pacientes que
comenzamos a desarrollar la unidad anterior, complementando lo que se refiere a los modelos de
diseo y los componentes del sistema.
En este ejemplo solo nos referiremos al diagrama de componentes del modelo.
La primera premisa para nuestro diagrama es que separaremos las capas de interfaz grfica de las
funcionales (negocio) y operativa, es decir, utilizaremos un modelo de 3 capas de diseo
arquitectnico.
CAPA FUNCIONAL
La capa funcional estar compuesta de 3 componentes bsicos y que son separados por su
naturaleza:
Gestin de la Ficha (creacin y consulta de la ficha de un paciente)
Gestin de la Consulta Mdica (ingreso de anamnesis)
Gestin de los Procedimientos (ingreso de observaciones y resultados)
Ahora bien, tanto la capa Consulta Mdica como la capa Procedimiento requieren trabajar con la
ficha, por lo que tambin existirn algunas dependencias entre ellas:
125

ILUSTRACIN 79. ASOCIACIONES ENTRE LOS COMPONENTES FUNCIONALES
Como podemos ver, las interfaces que exponemos para la comunicacin entre los paquetes nos
definen algunas operaciones que se realizarn en los diagramas de colaboracin. De esta manera,
estamos obligando que las clases las debamos discriminar de acuerdo a la naturaleza del
componete:
Componente Ficha: Todas las clases que operen con la ficha.
Componente Consulta Mdica: Todas las clases que operen con la anamnesis.
Componente Procedimiento: Todas las clases que operen con los procedimientos.
Es fcil ver que el centro del negocio est en las clases que controlan las fichas de los pacientes y
que el resto en realidad no es tan relevante como habamos pensado, por lo que nos sugiere que
en realidad no necesitamos tantos componentes, sino que solo uno principal y que contenga todas
las operaciones del sistema con la ficha, sin embargo, para el ejemplo, mantendremos la
consistencia con el diseo realizado y seguiremos mantenindolo por separado.
Lo que nos queda ahora es exponer los servicios que van hacia la interfaz grfica y completar el
diagrama con la capa completa:
ILUSTRACIN 80. CAPA FUNCIONAL DEL SEFP
CAPA DE INTERFAZ
Las operaciones expuestas en la capa funcional (que particularmente son solo las de sistema) no
son para que las use el usuario final directamente, sino que para que sean gatilladas a partir de la
interfaz. De esta manera, podramos (y optimizando el diagrama anterior) organizar el sistema de
la siguiente manera:
126

ILUSTRACIN 81. CAPAS DE INTERFAZ Y FUNCIONAL DEL SEFP
Lo que finalmente describimos es una componente grfica por lugar donde funcionar el sistema y
relacionamos con qu servicio expuesto se comunican dichas componentes directamente. As
podemos discriminar cmo organizar tambin los programas de la interfaz grfica fcilmente.
CAPA DE DATOS
Por ltimo, debemos tambin comunicarnos con la capa de datos, la cual es la que gestiona las
tablas de la base de datos y muestra los servicios expuestos necesarios para trabajar con la capa
funcional. Este sera entonces el diagrama final de componentes del sistema:
ILUSTRACIN 82. CAPAS DE COMPOENTES DEL SEFP
127

Como podemos notar, el Registro de Fichas es una componente que representa la interaccin con
la base de datos directamente. De esta manera, cuando se desea, por ejemplo, realizar una
bsqueda de una ficha por el rut, es necesario que se obtenga la ficha desde la base (a travs de
un select de la tabla respectiva).
En particular, solo se exponen 2 servicios bsicos que son consultar y registrar (similar a un
select y un update en SQL), los cuales son consumidos solo por la componente de Ficha.
MODELO DE DISEO
Para poder realizar el diseo es necesario que recordemos un artefacto que no da el primer indicio
del diseo del sistema: el diagrama de clases conceptuales:
1
DetalleDeFicha
+rut
+nombre
+direccion
+telefono
+email
FichaDePaciente
es-descrita-por
Paciente
posee
1
0..1
crea
Recepcionista
1
+cotiene
contiene
0..*
Laboratorista
0..*
Procedimiento
1
1
ingresa
Especialista
Anamnesis
1
es-descrita-por
1
es-descrita-por
1
DetalleAnamnesis
0..1
+datos_inspeccion
+observaciones
+indicaciones
+otros
+observaciones
0..1 +resultados
+diagnostico
ingresa
ILUSTRACIN 83. DIAGRAMA DE CLASES CONCEPTUALES DEL SEFP
En la construccin del modelo de diseo, comenzaremos con los Diagramas de Colaboracin que
representan las realizaciones de las operaciones del sistema a partir de los objetos de diseo que
participan.
Para esto utilizaremos los Patrones de Diseo (GRASP y GoF) de manera de normalizar la
asignacin de responsabilidades a un buen diseo.
Finalmente transformaremos esta informacin en un Diagrama de Clases de Diseo completo en
donde se describe el detalle del sistema antes de su implementacin.
128

Los diagramas de colaboracin realizan las interacciones necesarias para que lo objetos colaboren
bajo el objetivo de cumplir las operaciones de cada caso de uso. Por lo tanto, el diseo de
responsabilidades lo realizaremos en funcin de cada contrato descrito en el modelo de
comportamiento.
Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
Validar que el RUT exista dentro del catalogo de pacientes
Sistema
CU1
Si el RUT existe, se aborta el resto del CU
- Exista una instancia r de tipo CatalogoDePacientes
- No se haya encontrado una instancia f de FichaDePaciente
dentro de r que tenga asociada una instancia d de
DetalleDeFicha que tenga como atributo rut el valor del
parmetro rut.
ILUSTRACIN 84. CONTRATO DE LA OPERACIN VALIDARRUT
Lo primero que debemos buscar en este caso es qu objeto debe ser el controlador de la
operacin. Es fcil ver que como no tuvimos nunca una clase que represente nada fsico del
sistema, siempre utilizamos Sistema como tal. As que, como estamos hablando de aplicar el
patrn de controlador, deberemos decidir si:
Lo utilizamos como un controlador general del sistema (SistemaControlador, por ejemplo).
Lo utilizamos como un controlador modular (RegistroControlador, por ejemplo).
Para que podamos probar los controladores modulares, en este caso elegiremos la segunda
opcin. Adems, que el ejemplo es bastante bueno para que podamos separar las funciones en
cada mbito de la atencin mdica.
Si seguimos aplicando otros patrones, por ejemplo, para validar el rut debemos identificar de
quin es la responsabilidad de conocer o mantener conocimiento de las fichas de los pacientes.
Con el patrn de experto podemos determinar que ese es el CatlogoDePacientes, que ya
tenamos identificado anteriormente. Por ltimo, sabiendo que el experto de informacin de
conocer el rut de un paciente es DetalleDeFicha, y aplicando el patrn de cadena de
responsabilidad (de GoF), podemos llevar la responsabilidad desde el controlador hasta el mismo
objeto para entregar el valor del rut pidindole a CatalogoDePacientes, luego a FichaDePaciente y
que realice la validacin si existe una ficha (esperamos respuesta negativa por supuesto).
De esta manera, el primer diagrama de colaboracin quedara como sigue:
129

ILUSTRACIN 85. DIAGRAMA DE COLABORACIN PARA VALIDARRUT
De una forma anloga, podemos revisar el segundo contrato:

Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
CO2. ingresarDetalle(rut, nombre, direccion, fono, email)

Crear y agregar la informacin bsica del paciente a la ficha
Sistema
CU1
- Se haya creado una instancia d de tipo DetalleDeFicha
- Se hayan fijado los atributos rut, nombre, direccin,
telfono e email con los valores entregados por parmetro.
- Se haya creado una instancia f de tipo FichaDePaciente
- Se haya asociado d a f
ILUSTRACIN 86. CONTRATO DE LA OPERACIN INGRESARDETALLE
Es fcil ver que debemos primero buscar si el anterior controlar de las operaciones aplica en sta,
y la respuesta es s, porque seguimos en el mismo mdulo (CU) de registro de paciente.
Por otro lado, como debemos crear un DetalleDeFicha, debemos buscar el mejor creador ese tipo
de objetos. Como sabemos, la clase que usa ms estrechamente estos objetos es FichaDePaciente,
sin embargo tambin es parte del contrato crear un objeto de ese tipo, as que podemos realizar
esa creacin en cadena, delegando la responsabilidad al mejor creador de FichaDePaciente, y que
se lo podemos entregar de inmediato al CatalogoDePacientes (ya que l es quien necesitar
utilizar esas instancias de aqu en adelante).
Por ltimo, finalmente necesitamos obtener el experto de la informacin del detalle del paciente y
es DetalleDeFicha, lo que nos permite mejorar la creacin de ese tipo de objetos delegndole toda
esa informacin a su creador (FichaDePaciente) y permitiendo que la creacin se lleve a cabo en
una sola responsabilidad encapsulada.
El diagrama de colaboracin quedara as:
130

ILUSTRACIN 87. DIAGRAMA DE COLABORACIN PARA INGRESADETALLE
Notemos que en este caso particular, la existencia de la relacin con el catlogo no estaba definida
en el contrato, pero la aplicacin de los patrones de diseo nos permiti descubrir esta relacin.
Por otro lado tampoco aparece en forma explcita el cumplimiento de la postcondicin de asociar
d a f, pero por la delegacin de la creacin quedan asociadas esas instancias.
El siguiente contrato es:
Operacin:
Responsabilidad:
CO3. consultar(rut)
Obtiene la informacin de la ficha del paciente a partir del
rut ingresado.
Ref. Cruzadas: CU2, CU3, CU5
Notas: Excepciones: Si la ficha no existe, devuelve un valor nulo.
Salidas: Precondiciones - Exista una instancia r de CatalogoDePacientes
Postcondiciones: - Se haya encontrado una instancia p de DetalleDePaciente
cuyo atributo rut sea igual al valor del parmetros rut.
ILUSTRACIN 88. CONTRATO DE LA OPERACIN CONSULTAR
Para buscar el controlador, primero debemos consultarnos si se aplica el anterior. En este caso no
lo es, porque no estamos en el registro de un paciente, pero tampoco estamos en algn CU
particular, ya que esta operacin es transversal a los CU2, CU3 y CU5.
A pesar de ello, como la naturaleza de la operacin tiene que ver con obtener la informacin de la
ficha del paciente, podremos crear un nuevo controlador modular llamado FichaControlador, que
permite realizar las operaciones bsicas de consulta o manipulacin de la ficha9.
Por otro lado, como estamos buscando una ficha particular, debemos aplicar exactamente la
misma idea de lo aplicado en el CO1. De esta manera, podemos cambiar nuestra primera
realizacin para mejorar y aplicar este contrato en forma equivalente.
As, las colaboraciones corregidas para aplicar esta operacin tambin seran:
Note que las operaciones anteriormente analizadas tambin tienen que ver con la ficha, por lo que una
mejora sera juntarlas todas en este mismo controlador, quedando 3 operaciones (CO1, CO2 y CO3).
131

ILUSTRACIN 89. DIAGRAMA DE COLABORACIN PARA VALIDARRUT MODIFICADO
ILUSTRACIN 90. DIAGRAMA DE COLABORACIN PARA INGRESARDETALLE MODIFICADO
Por ltimo, la colaboracin del CO3 sera:
ILUSTRACIN 91. DIAGRAMA DE COLABORACIN PARA CONSULTAR
Como podemos ver, la naturaleza de la operacin es la misma, pero la respuesta que se espera es
diferente del controlador. El siguiente contrato es:
Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
ILUSTRACIN 92.
CO4. registrarInformacion(objeto)
Registra en la ficha del paciente la informacin entregada en
forma de objeto.
Sistema
CU3, CU5
Objeto puede tomar valores de DetalleAnamnesis y
- Exiasta una instancia d de DetalleDePaciente
- Se haya asociado objeto a d.
CONTRATO DE LA OPERACIN REGISTRARINFORMACION
132

Primero, esto tiene diferentes matices, ya que est siendo generalizada una operacin que no
tendran el mismo controlador, as que seran vistas en forma diferente (como 2 contratos aparte).
De esta forma, el primero ser recibido por ConsultaControlador, el cual manejar las operaciones
realizadas por el especialista en la consulta mdica. La otra ser gestionada por
ProcedimientoControlador, que tiene que ver ms con las operaciones realizadas durante un
procedimiento mdico.
Ahora si comenzamos a ver el primer caso como registrarAnamnesis() tendremos el detalle
necesario para aplicar los patrones de creador y experto que nos lleve al primer diagrama de
colaboracin:
ILUSTRACIN 93. DIAGRAMA DE COLABORACIN DE REGISTRARANAMNESIS
De una manera anloga podemos realizar la operacin respecto al registro del procedimiento
quedando el diagrama de la siguiente forma:
ILUSTRACIN 94. DIAGRAMA DE COLABORACIN DE REGISTRARPROCEDIMIENTO
Lo relevante de este anlisis, es que como el detalle necesario es por cada una de las clases, es
necesario que hayamos separados las operaciones para cada caso, ya que, tal como vimos en
clase, se convertirn en los mtodos de cada una de las clases (y las clases destino son las mismas).
133

Por ltimo, veamos el ltimo contrato del dominio:

Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
ILUSTRACIN
CO5. cerrarAtencion(especialista)
Enva una notificacin al sistema de agenda mdica
indicando el trmino de la atencin del especialista.
Sistema
CU7
Utiliza XML para construir la llamada al SAM.
Un mensaje intersistemas para el SAM
95. CONTRATO DE LA OPERACIN CERRARATENCION
Como podemos ver, esta operacin tiene que ver con la consulta mdica (y de hecho es una
operacin de secundaria, ya que es una notificacin). Sin embargo, este contrato no aporta
informacin al sistema como tal, porque solo elabora un mensaje a un sistema externo, lo que no
se ve reflejado en las postcondiciones.
Una vez analizado por completo las operaciones del sistema, podemos plantear paso a paso el
diagrama de clases de diseo. Veamos cmo va quedando:
Con un simple paso por los diagramas de colaboracin, podemos identificar las siguientes clases:
ILUSTRACIN 96. IDENTIFICACIN DE CLASES DE DISEO Y ATRIBUTOS
En el diagrama, adems pusimos desde ya los atributos que vienen desde el diagrama de clases
conceptuales, ya que a priori sabemos que esos valores se mantendrn para el diseo.
134

El siguiente paso es completar con la informacin de los tipos de datos de los atributos y sus
visibilidades correctas:
ILUSTRACIN 97. DETALLE DE VISIBILIDAD Y TIPOS DE DATOS DE ATRIBUTOS
Es fcil detectar que la informacin almacenada es mayormente de texto, ya que todos los datos
generados por los especialistas mdicos son de ese tipo.
Siguiendo con las definiciones aprendidas en la tcnica de creacin del diagrama de clases de
diseo, podemos obtener ahora los mtodos de cada una de las clases a partir de los diagramas de
colaboracin dibujados en la seccin anterior. As, podemos asociar los siguientes mtodos
encontrados a las siguientes clases:
FichaControlador: validarRut, ingresarDetalle, consultar.
ConsultaControlador: registrarAnamnesis.
ProcedimientoControlador: registrarProcedimiento.
CatalogoDePacientes: buscar, crearFichaDePaciente.
FichaDePaciente: consultarRut, crear, crearAnamnesis, crearProcedimiento.
DetalleDeFicha: getRut, crear.
Anamnesis: crear.
DetalleDeAnamnesis: crear
135

Procedimiento: crear
DetalleDeProcedimiento: crear
De esta manera, el diagrama quedara de la siguiente forma detallado:
ILUSTRACIN 98. DESCRIPCIN DE LOS MTODOS DE LAS CLASES
10
El paso siguiente es incorporar las asociaciones de acuerdo a la cercana de las clases del diagrama.
Esto es bastante rpido de identificar porque basta con responder cualquiera de las 3 situaciones
indicadas anteriormente:
A es un creador de objetos de tipo B
A agrega objetos de tipo B
A necesita mantener conocimiento de los objetos de tipo B
De esta manera, el diagrama que estamos completando pasara a ser de la siguiente forma:
10
Las clases fueron reorganizadas para alcanzar a ver mayor detalle en el documento.
136

ILUSTRACIN 99. DESCRIPCIN DE ASOCIACIONES ENTRE LAS CLASES
Como podemos ver incorporamos tambin el concepto de composicin en varias de esas

asociaciones, por el hecho de ser creadores de otros objetos.
Observemos por un momento la relacin entre Procedimiento DetalleDeProcedimiento y
Anamnesis DetalleDeAnamnesis. Podemos notar una semejanza con la caja del supermercado,
porque en este caso Procedimiento y Anamnesis estn jugando el papel de lnea de venta, por lo
que es posible resumir esa sobrecarga de clases (ya que ambas hacen lo mismo) en una sola que
permita almacenar ambos tipos de registros.
Para hacer esto, y aprovechar de utilizar la generalizacin en el diagrama, incorporaremos la clase
RegistroDeFicha (que reemplazar Procedimiento y Anamnesis como lnea de venta) y una clase
DetalleDeRegistro que ser la superclase que incorporar ambos tipos de registros.
Adems, si vemos la forma en que se comportan las operaciones de las clases, podemos notar que
no existen dependencias, por lo que no debemos incorporar ms detalle y podemos mostrar
finalmente el siguiente diagrama de clases de diseo como una primera versin de nuestro SEFP:
137

ILUSTRACIN 100. DIAGRAMA DE CLASES DE DISEO DEL SEFP
138

UNIDAD IV: INTRODUCCIN A LA

IMPLEMENTACIN
Gracias a la metodologa UP planteada, la construccin del software se torna un
poco ms sencilla, ya que con el diagrama de clases de diseo, ms las
especificaciones que se encontraron en las realizaciones a travs de la visibilidad y
los mensajes definidos, nos permiten al menos tener una estructura rpida de
implementar. En este captulo veremos una tcnica utilizada principalmente por
las herramientas CASE en el mbito para transformar estos modelos en cdigos
de programas.
139

FUNDAMENTOS DE LA IMPLEMENTACIN DEL SOFTWARE

La implementacin del software es la parte en donde se concretan los diseos realizados y se
codifica gran parte del sistema final que se est definiendo.
CODIFICACIN DE CALIDAD
Los especialistas deben perseguir la obtencin de programas de calidad. Para ello se establece
una serie de factores que determinan la calidad de un programa:
Correccin: Un programa es correcto si hace lo que debe hacer tal y como se estableci en
el anlisis y diseo.
Claridad: Es muy importante que el programa sea lo ms claro y legible posible, para
facilitar as su desarrollo y posterior mantenimiento.
Eficiencia: Se trata de que el programa, adems de realizar aquello para lo que fue creado
(es decir, que sea correcto), lo haga gestionando de la mejor forma posible los recursos
que utiliza.
Portabilidad: Un programa es portable cuando tiene la capacidad de poder ejecutarse en

una plataforma, ya sea hardware o software, diferente a aqulla en la que se elabor.
ESTNDARES DE CODIFICACIN
Los estndares de codificacin se refieren a un conjunto de reglas y lineamientos que se usan al
escribir los cdigos fuentes de un software. El uso de un estndar particular ayuda a los
programadores a leer y entender el cdigo evitando los errores de la mejor manera.
Un buen estilo de programacin (o estndar) es difcil de definir ya que depende del lenguaje de
programacin seleccionado, sin embargo existen algunos aspectos comunes a ellos que ayudan a
tener un estndar definido:
Apariencia del Cdigo: Los estndares apuntan a que el cdigo debe ser de fcil
entendimiento humano. De esta forma se pueden utilizar algunas tcnicas bsicas como
indentacin, alineamiento vertical, espaciado y tabuladores.
Nombrado de Variables: Una buena seleccin de nombres de variables indica que ellas
deben ser nombradas segn su funcin. La utilizacin de nombres deficientes de variables
solo complican el entendimiento del cdigo fuente.
Valores Booleanos en Estructuras de Decisin: Es mejor siempre evitar la utilizacin de

condicionales para obtener un valor booleano. En su lugar, es mejor realizar operatoria de
valores de verdad para calcular el resultado booleano.
Bucles y Estructura de Control: El uso de estructuras de control para bucles tambin es

parte de un buen estilo de programacin.
140

HERRAMIENTAS CASE
Las CASE-Tools o Herramientas CASE (Computer Aided Software Engineering, Ingeniera de
Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a aumentar
la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos de
tiempo y de dinero.
Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del
software en tareas como el proceso de realizar un diseo del proyecto, calculo de costes,
implementacin de parte del cdigo automticamente con el diseo dado, compilacin
automtica, documentacin o deteccin de errores entre otras.
A pesar de que las CASE-Tools nacieron en los aos 70, actualmente siguen siendo una gran ayuda
en el mbito de la ingeniera de software y sobretodo en etapas menos tcnicas como el anlisis y
diseo.
El modelo de implementacin define el mapeo que debemos hacer del diseo de software
realizado a travs de los artefactos del UP con la codificacin. De esta manera podemos definirlo
en dos partes:
Definicin de las Clases (a partir de los DCD)
Definicin de los Mtodos (a partir de las colaboraciones)
A continuacin veremos algunos aspectos bsicos con los cuales debe trabajar el arquitecto antes
de llegar a obtener un diseo completo.
CONCEPTOS BSICOS
CDIGO
Podemos definir que:
EL CDIGO ES LA SINTAXIS DE LOS PROGRAMAS, EN UN LENGUAJE
DE MQUINA PARTICULAR, Y QUE REPRESENTAN EL DISEO
ESPECIFICADO.
Lo que estamos definiendo tan sencillamente es que utilizaremos cdigo para especificar la
implementacin.
En este caso, en lenguaje de programacin que usaremos para los ejemplos ser Java por su
orientacin al objeto y pertinencia con la carrera.
141


En particular, en este modelo no utilizaremos algn artefacto UML en especfico, sin embargo
definiremos como artefactos dos productos que utilizaremos en el curso:
Diagrama de Clases de Implementacin: Diagrama complementario que especifica detalle

tcnico en el diagrama de clases de diseo (como normalizacin de tipos de datos al
lenguaje de programacin) e incorpora informacin de cdigo para las clases.
Estructura de Clases: Estructura de programas que se obtiene de la transformacin del

diagrama de clases de implementacin en el lenguaje de programacin seleccionado.

El proceso de desarrollo de ambos artefactos se reduce en realidad a una sola tcnica, sin
embargo la especificaremos a continuacin de manera segmentada para un mejor entendimiento
de ellos.
DIAGRAMA DE CLASES DE IMPLEMENTACIN
Tal como ya habamos mencionado, el artefacto cumbre de la fase de diseo es el que
conocemos como Diagrama de Clases de Diseo (DCD), pero solo lo mencionamos. Ahora tenemos
la oportunidad de justificarlo mostrando cmo el DCD se transforma en una estructura de clases.
Veamos el DCD del Punto de Venta para que vayamos agregando las definiciones de las clases de
implementacin:
ILUSTRACIN 101. DIAGRAMA DE CLASES DE DISEO DEL SPDV
142

Lo primero que debemos hacer es, entonces, adoptar el diagrama y convertir todos aquellos tipos
de datos y definiciones funcionales para convertirlas en elementos del lenguaje de programacin
seleccionado. Pensemos en Java, entonces el diagrama anterior quedara transformado a:
ILUSTRACIN 102. DIAGRAMA DE CLASES DE NORMALIZADO AL LENGUAJE JAVA
Ahora que ya lo tenemos normalizado, debemos saber de dnde vamos sacando los cdigos
respectivos de cada clase. La regla es siempre comenzar desde la menos acoplada (ms especfica)
a la ms acoplada. En el ejemplo, podemos definir el siguiente orden de acoplamiento:
Producto
Pago
LneaDeVenta
Catalogo
Venta
CajaControlador
Luego de saber el orden de implementacin, se debe comenzar poniendo los cdigos de las clases
desde la definicin que ya se ha encontrado en el DCD, lo que llamaremos atributos y mtodos
simples. De esta manera, la clase se va construyendo a partir directamente de la definicin que
dice el DCD.
Por ejemplo, tomemos LineaDeVenta para comenzar la definicin:
143

LineaDeVenta
-cantidad: short
+new(p: Producto, cant: short): LineaDeVenta
-setProducto(p: Producto)
-setCantidad(cant: short)
+obtenerSubTotal(): double
public class LineaDeVenta {

private short cantidad;
public LineaDeVenta(Producto p, short cant) { }
private void setProducto(Producto p) { }
private void setCantidad(short cant) { }
public double obtenerSutotal() { }
}
ILUSTRACIN 103. DEFINICIN DE CDIGO PARA LA CLASE LINEADEVENTA
Esto lo debemos hacer para todas las clases del DCD, de manera que tenemos una primera
estructura bsica de la estructura de clases.
Otro tipo de atributos que se derivan de los DCD son los conocidos como de referencia y que
representan aquellos atributos que son definidos a raz de la relacin que tienen las clases. De esta
manera, cada vez que veamos una asociacin en el diagrama de clases, entonces estaremos
pensando que en la implementacin debemos referenciar la clase dependiente a travs de un
atributo.
Por ejemplo, en la relacin entre LineaDeVenta y Producto podemos obtener claramente un
atributo de referencia. Este se ve en la clase Linea de Venta:
Producto
-codigo: long
-glosa: String
-p -precio: double
1 +getCodigo(): long
+getPrecio(): double
1
LineaDeVenta
-cantidad: short

/* ATRIBUTOS */
private Producto p; // Atributo de Referencia
/* OPERACIONES */
public LineaDeVenta(Producto p, short cant) { }
private void setProducto(Producto p) { }
private void setCantidad(short cant) { }
public double obtenerSutotal() { }
}
ILUSTRACIN 104. IDENTIFICACIN DEL ATRIBUTO DE REFERENCIA DE LINEADEVENTA
Para este caso lo estamos haciendo a partir de una composicin. En el caso del lenguaje Java,
tanto la composicin como la agregacin se representan de la misma forma, sin embargo, cuando
estemos utilizando lenguajes cuya representacin se torna diferente, entonces debemos
preocuparnos de si hablamos de composicin y no de agregacin.
144

Otro tema importante es cuando hablamos del nombre del papel que se usa en el DCD. Algunos
diagramas utilizan en el extremo dependido un atributo que indica el nombre de la relacin. De
esta forma, ese papel debe ser usado como nombre del objeto de referencia.
Otra consideracin importante cuando se agregan los atributos de referencia es cuando estamos
hablando de los contenedores (como en el caso del ejemplo que son los objetos de tipo Producto
sobre el Catalogo o las LineasDeVenta sobre la Venta).
Cuando se trata de poner la multiplicidad en el cdigo nos vemos con la complicacin de que no
existe forma directa en algunos lenguajes para hacerlo. De esta manera, lo que se hace
tradicionalmente, por ejemplo en Java, es utilizar una clase intermediaria que relacione el
contenedor con lo contenido de la forma adecuada. As, a pesar de que no aparece en el DCD esta
clase, se hace directamente.
Por ejemplo, para hacer la relacin entre Venta y LineaDeVenta, podemos agregar la clase Vector,
la que en Java permite poner un grupo de objetos en un solo contenedor. De esta forma, la
definicin quedara de la siguiente forma:
public class Venta {
/* ATRIBUTOS */
private Date fecha;
private Vector ldv; // Atributo de grupo
private Pago p;
/* OPERACIONES */
public Venta (Date fecha) { }
private void setFecha(Date fecha) { }
public void crearLDV(Producto p, short cant) { }
public double obtenerTotal() { }
public void crearPago(double monto, byte tipo) { }
}
Venta
-fecha: Date
+new(fecha: Date): Venta
-setFecha(fecha: Date)
+crearLDV(p: Producto, cant: short)
+obtenerTotal(): double
+crearPago(monto: double, tipo: byte)
1..*
-ldv
LineaDeVenta
-cantidad: short
ILUSTRACIN 105. ESPECIFICANDO ATRIBUTOS DEL CONTENEDOR VENTA
En este ejemplo, podemos ver que qued puesto un objeto Vector llamado ldv que,
conceptualmente, no es ms que un conjunto de objetos de LineaDeVenta agrupados en Venta.
De esta manera, cada vez que se cree una nueva LineaDeVenta, tenemos que agregarlo al
Vector, no solo referenciando la variable, sino que utilizando las operaciones de ste ltimo.
Otro paso que a travs de esta tcnica es posible realizar es describir los mtodos que se
encontraron como mensajes y responsabilidades en los diagramas de colaboracin. De esta
manera, podemos escribir los cuerpos de los mtodos (al menos en parte) mirando estos
diagramas.
Veamos el ejemplo de la operacin agregarProducto de CajaControlador. Su diagrama de
colaboracin (parte de l) sera:
145

ILUSTRACIN 106. COLABORACIN PARA AGREGARPRODUCTO EN LA VENTA ACTUAL
Ntese que los mensajes que salen de CajaControlador estn representando parte del cuerpo del
mtodo agregarProducto de CajaControlador. Por lo tanto, si revisamos la secuencia y vamos
agregando las llamadas respectivas a la definicin de la clase, tenemos:
public class CajaControlador {
private Catalogo c;
private Venta v;
public void iniciarVenta() { }
public void agregarProducto(long cod, short cant) {
Producto p;
p = c.buscar(cod);
v.crearLDV(p, cant);
}
public void registrarPago(double monto, byte tipo) {}
CajaControlador
-c
+iniciarVenta()
+agregarProducto(cod: long, cant: short)
+registrarPago(monto: double, tipo: byte)
Catalogo
1 +buscar(cod: long): Producto
0..*
-v
Venta
-fecha: Date
+new(fecha: Date): Venta
-setFecha(fecha: Date)
+crearLDV(p: Producto, cant: short)
+obtenerTotal(): double
+crearPago(monto: double, tipo: byte)
ILUSTRACIN 107. ESPECIFICACIN DEL CUERPO DE LA OPERACIN AGREGARPRODUCTO
Como se puede ver ac aparecen directamente los mtodos que ya definimos en cada clase y
hasta el orden de llamada relativa por supuesto a la responsabilidad en cuestin. En este caso
ingresarProducto queda aparentemente definido en su totalidad, por lo tanto no requiere agregar
nada ms para que sea un procedimiento programado.
Finalmente, con esta documentacin tendremos un gran diagrama de clases con comentarios que
especifican cada clase de diseo como si fuera una fuente de informacin tcnica para la
programacin.
146

ILUSTRACIN 108. DIAGRAMA DE CLASES DE IMPLEMENTACIN PARA EL SPDV
ESTRUCTURA DEL CDIGO

Una vez de aplicados todos los pasos, ahora es importante escribir cada una de las clases. Las
herramientas CASE nos ayudan en este proceso y la salida seran las clases formales, pero como
ejercicio, en este caso, lo haremos a mano.
La tcnica para escribir el cdigo es muy sencilla: basta recorrer el diagrama de clases de
implementacin y comenzar a describir las clases con el detalle esperado.
El resultado entonces de realizar este proceso completo para el caso del SPDV sera el siguiente:
CAJACONTROLADOR
public class CajaControlador {
private Catalogo c;
private Venta v;
public void iniciarVenta() {
this.v = new Venta((Date) System.currentTimeMilis());
}
public void agregarProducto(long cod, short cant) {
Producto p;
p = this.c.buscar(cod);
this.v.crearLDV(p, cant);
}
public void registrarPago(double monto, byte tipo) {
this.v.crearPago(monto, tipo);
}
}
147

VENTA
public class Venta {
private Date fecha;
private Vector ldv;
private Pago p;
public Venta (Date fecha) {
this.setFecha(fecha);
}
private void setFecha(Date fecha) {
this.fecha = fecha;
}
public void crearLDV(Producto p, short cant) {
LineaDeVenta l = new LineaDeVenta(p, cant);
this.ldv.addElement(l);
}
public double obtenerTotal() {
double suma = 0.0;
for(int i=0; i<this.ldv.size(); i++) {
suma += this.ldv.elementAt(i).obtenerSubTotal();
}
return suma;
}
public void crearPago(double monto, byte tipo) {
this.p = new Pago(monto, tipo);
}
}
LINEADEVENTA
private Producto p;
public LineaDeVenta(Producto p, short cant) {
this.setProducto(p);
this.setCantidad(cant);
}
private void setProducto(Producto p) {
this.p = p;
}
private void setCantidad(short cant) {
this.cantidad = cant;
}
public double obtenerSutotal() {
return this.cantidad * this.p.getPrecio();
}
}
PAGO
public clas Pago {
private double monto;
private byte tipo;
148

public Pago(double monto, byte tipo) {
this.setMonto(monto);
this.setTipo(tipo);
}
private void setMonto(double monto) {
this.monto = monto;
}
private void setTipo(byte tipo) {
this.tipo = tipo;
}
}
CATALOGO
public class Catalogo {
private Vector cdp;
public Producto buscar(long cod) {
for(int i=0; i<this.cdp.size(); i++) {
if (this.cdp.elementAt(i).getCodigo() == cod)
return this.cdp.elementAt(i);
}
}
}
PRODUCTO
public class Producto {
private long codigo;
private String glosa;
private double precio;
public long getCodigo() {
return this.codigo;
}
public double getPrecio() {
return this.precio;
}
}
Luego de esto, es importante que los programadores incorporen en cada uno de los mtodos el
detalle y estructuras de control necesarias que permitan que el sistema opere de manera efectiva
y correcta segn las especificaciones de requisitos realizadas al principio del curso.

Ahora completaremos la realizacin del ejemplo del sistema electrnico de fichas de pacientes,
complementando lo que se refiere al modelo de implementacin del sistema.
En este modelo especificaremos solo la estructura de clases a partir del DCD y usando Java.
149

Describiremos el diagrama de clases de implementacin, utilizando el DCD de la unidad anterior.

Para ello entonces pasaremos por los pasos bsicos indicados en la tcnica de desarrollo del
modelo respectivo.
Primero, comencemos normalizando los tipos de datos al lenguaje elegido (Java). El diagrama de
clases quedara algo parecido a lo siguiente:
ILUSTRACIN 109. DIAGRAMA DE CLASES DE DISEO CON TIPOS DE DATOS JAVA DEL SEFP
Luego de realizado esto, se van describiendo las clases a travs de anotaciones en el diagrama
considerando no solo los atributos explcitos, sino que tambin operaciones complejas y atributos
de asociacin.
Para el caso de las asociaciones mltiples que existen en este diagrama, vamos a utilizar una
estructura Vector de objetos para que vaya acumulando los objetos del tipo de destino sin
necesidad de conocer el nmero de elementos que finalmente vamos a registrar.
De esta manera, tendremos un diagram parecido a este:
150

ILUSTRACIN 110. DIAGRAMA DE CLASES DE IMPLEMENTACIN COMPLETO DEL SEFP
El siguiente paso (que aparece en la tcnica vista en este captulo) indica incorporar lgica de
programacin en el diagrama, sin embargo, dada la complejidad de ste, vamos a optar por
escribir el cdigo (estructura de clases) a partir de lo ya obtenido, y luego incorporar lgica
programtica.
ESTRUCTURA DE CLASES
La estructura obtenida corresponde a las clases, con sus atributos y las firmas de todos los
mtodos identificados. Sin embargo, vamos a aprovechar de incorporar lgica en los mtodos de
las clases segn corresponda.
A continuacin el listado de las clases desde las menos acopladas a las ms acopladas:
public class DetalleDeAnamnesis {
private String datos_inspeccion;
private String observaciones;
private String indicaciones;
private String otros;
public DetalleDeAnamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
this.setDatos_Inspeccion(inspeccion);
this.setObservaciones(observaciones);
this.setIndicaciones(indicaciones);
this.setOtros(otros);
}
private void setDatos_Inspeccion(String inspeccion) {
this.datos_inspeccion = inspeccion;
}
private void setObservaciones(String observaciones) {
this.observaciones = observaciones;
}
private void setIndicaciones(String indicaciones) {
this.indicaciones = indicaciones;
}
151

private void setOtros(String otros) {
this.otros = otros;
}
}
public class DetalleDeProcedimiento {
private String observaciones;
private String resultados;
private String diagnostico;
public DetalleDeProcedimiento(String observaciones, String resultados,
String diagnostico) {
this.setObservaciones(observaciones);
this.setResultados(resultados);
this.setDiagnostico(diagnostico);
}
private void setObservaciones(String observaciones) {
this.observaciones = observaciones;
}
private void setResultados(String resultados) {
this.resultados = resultados;
}
private void setDiagnostico(String diagnostico) {
this.diagnostico = diagnostico;
}
}
public class DetalleDeFicha{
private int rut;
private String nombre;
private String direccion;
private String fono;
private String email;
public DetalleDeFicha (int rut, String nombre, String direccion,
String fono, String email) {
this.setRut(rut);
this.setNombre(nombre);
this.setDireccion(direccion);
this.setFono(fono);
this.setEmail(email);
}
public int getRut() {
return this.rut;
}
private void setRut(int rut) {
this.rut = rut;
}
private void setNombre(String nombre) {
this.nombre = nombre;
}
private void setDireccion(String direccion) {
this.direccion = direccion;
}
private void setFono(String fono) {
this.fono = fono;
}
private void setEmail(String email) {
this.email = email;
}
}
152

public class Procedimiento {
private DetalleDeProcedimiento detalle;
public Procedimiento(String observaciones, String resultados,
this.detalle = new DetalleDeProcedimiento(observaciones,
resultados, diagnostico);
}
}
public class Anamnesis {
private DetalleDeAnamnesis detalle;
public Anamnesis(String inspeccion, String observaciones,
this.detalle = new DetalleDeAnamnesis(inspeccion, observaciones,
indicaciones, otros);
}
}
public class FichaDePaciente {
private DetalleDeFicha detalle;
private Vector procedimientos;
private Vector anamnesis;
public FichaDePaciente(int rut, String nombre, String direccion,
this.detalle = new DetalleDePaciente(rut, nombre, direccion,
fono, email);
}
public DetalleDePaciente consultarRut(int rut) {
return this.detalle;
}
public void crearAnamnesis(String inspeccion, String observaciones,
Anamnesis anam = new Anamnesis(inspeccion, observaciones,
this.anamnesis.addElement(anam);
}
public void crearProcedimiento(String observaciones, String resultados,
Procedimiento proc = new Procedimiento(observaciones,
resultados, diagnostico);
this.procedimientos.addElement(proc);
}
}
public class CatalogoDePacientes {
private Vector fichas;
public FichaDePaciente buscar(int rut) {
for(int i=0; i<this.fichas.size(); i++) {
if (this.fichas.elementAt(i).getRut() == rut)
return this.fichas.elementAt(i);
}
}
public void crearFichaDePaciente(int rut, String nombre,
String direccion, String fono, String email) {
FichaDePaciente ficha = new FichaDePaciente(rut, nombre,
direccion, fono, email);
this.fichas.addElement(ficha);
}
}
153

public class ConsultaControlador {
private FichaDePaciente paciente;
public void registrarAnamnesis(String inspeccion, String observaciones,
this.paciente.crearAnamnesis(inspeccion, observaciones,
}
}
public class ProcedimientoControlador {
private FichaDePaciente paciente;
public void registrarProcedimiento(String observaciones,
String restultados, String diagnostico) {
this.paciente.crearProcedimiento(observaciones, resultados,
diagnostico);
}
}
public class FichaControlador {
private CatalogoDePacientes fichas;
public void validarRut(int rut) {
FichaDePaciente f = this.fichas.buscar(rut);
}
public void ingresarDetalle(int rut, String nombre, String direccion,
this.fichas.crearFichaDePaciente(rut, nombre, direccion,
fono, email);
}
public void consultar(int rut) {
FichaDePaciente f = this.fichas.buscar(rut);
}
}
154

ANEXOS
155

PLANTILLA DE DOCUMENTACIN DEL A/DOO

A continuacin se presenta una estructura para documentar el proceso de anlisis y desarrollo
orientado al objeto planteado en este documento. Es importante recordar que esta
documentacin se realizar para cada iteracin del proceso de desarrollo, por lo que es importante
priorizar las funciones a abordar en cada una de ellas.
ESPECIFICACIN DE REQUISITOS
En esta seccin se describe la visin funcional del sistema a la luz de los requerimientos
expresados por el cliente final.
IDENTIFICACIN DEL SISTEMA
El sistema se describe de la siguiente forma:
Nombre del Sistema:
Panorama:
Clientes:
Metas:
ESPECIFICACIN DE FUNCIONES
La especificacin funcional del sistema se detalla a travs de las siguientes funciones:
# Ref:
Funcin:
Descripcin:
Categora:
Atributo
Categora

En esta seccin se describen los casos de uso, su detalle y la relacin que tienen con las funciones
determinadas en la seccin anterior. Es importante incorporar el detalle de cada iteracin
priorizado de manera de mantener coherencia con lo que se realize a travs del proceso de
desarrollo complete.
CASOS DE USO DE ALTO NIVEL
Los casos de uso encontrados en esta iteracin son los siguientes:
Caso de Uso:
Actores:
Tipo:
Descripcin:
Es importante destacar que solo los CU principales sern expandidos a continuacin.

156

CASOS DE USO EXPANDIDOS

El detalle de los casos de uso identificados es el siguiente:
Caso de Uso:
Actores:
Propsito:
Resumen:
Tipo:
Ref. Cruzadas:
Curso Normal

A continuacin se muestra grficamente la relacin de los actores con los casos de uso
especificados.
<INSERTAR DIAGRAMA>
GLOSARIO
En esta seccin se describen los conceptos ms importantes del dominio y que impactan en su
entendimiento.
Trmino
Definicin
MODELO DE DOMINIO
En esta seccin se describen los artefactos que muestran la visin de negocio y el contexto en el
cual se desarrollar el sistema.
DIAGRAMA DE ACTIVIDADES
Los procesos se describen de la siguiente forma:
<INSERTAR DIAGRAMAS POR PROCESO>
El dominio se observa en el siguiente diagram:
<INSERTAR DIAGRAMA>
En esta seccin se describen los artefactos que describen el comportamiento del sistema.
157

Los casos de uso se describen en los siguientes diagramas de secuencia:
<INSERTAR DIAGRAMAS POR CASO DE USO>
Las operaciones del sistema se describen a travs de los siguientes contraltos:
Operacin:
Responsabilidad:
Tipo o Clase:
Ref. Cruzadas:
Notas:
Excepciones:
Salidas:
Precondiciones
Postcondiciones:
DIAGRAMAS DE ESTADO
Los cambios de estado de los objetos del sistema se describen en los siguientes diagramas:
<INSERTAR DIAGRAMAS POR OBJETO>
En esta seccin se describen las decisiones de la arquitectura que afectan a la organizacin de los
programas finales.
El diagrama que define la distribucin de componentes es el siguiente:
<INSERTAR DIAGRAMA>
MODELO DE DISEO
En esta seccin se describe en detalle el diseo del sistema a partir de las operaciones de ste y
completando con una vision tcnica de las clases de diseo.
Las operaciones se realizan en el sistema de la siguiente forma:
<INSERTAR DIAGRAMAS POR OPERACION DE SISTEMA>
El diagrama de clases que define el sistema es el siguiente:
<INSERTAR DIAGRAMA>
158

En esta seccin se describen las labores de preparacin de la codificacin.
El diagrama de clases normalizado y preparado para la codificacin es:
<INSERTAR DIAGRAMA>
ESTRUCTURA DE CLASES
La estructura bsica de clases que se deriva del diseo es:
<INSERTAR ESTRUCTURA DE CLASES>
159

GUA DE USO DE STARUML

Para complementar este apunte, presentamos una gua rpida de uso de StarUML, que es el
software con el cual fueron desarrollados todos los modelos grficos que aqu se describen,
incluyendo no solo la utilizacin formal, sino que tambin el uso de trucos que nos ayuden a
producir modelos de acuerdo a las tcnicas y recomendaciones aqu planteadas.
Adems, la idea central es permitir al alumno aprender a utilizar una herramienta CASE de acceso
liberado (al menos hasta la creacin de este documento) tanto a nivel acadmico como en su
desarrollo profesional.
INTRODUCCIN A LAS HERRAMIENTAS CASE

Las CASE-Tools o Herramientas CASE (Computer Aided Software Engineering, Ingeniera de
Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a aumentar
la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos de
tiempo y de dinero.
Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del
software en tareas como el proceso de realizar un diseo del proyecto, calculo de costes,
implementacin de parte del cdigo automticamente con el diseo dado, compilacin
automtica, documentacin o deteccin de errores entre otras.
HISTORIA
Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un producto que
analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos
generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement Language) y la
aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem Statemente
Analyzer).
Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos
informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y
trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM
haba conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus
mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de
vida del software.
Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las
Big CASE ha muerto completamente abriendo el mercado de diversas herramientas ms
especficas para cada fase del ciclo de vida del software.
OBJETIVOS
Los objetivos que buscan resolver las herramientas CASE son:
160

Mejorar la productividad en el desarrollo y mantenimiento del software.
Aumentar la calidad del software.
Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos.
Mejorar la planificacin de un proyecto
Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la

bsqueda de soluciones para los requisitos.
Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las

pruebas de errores y la gestin del proyecto.
Ayudar a la reutilizacin del software, portabilidad y estandarizacin de la documentacin
Gestionar globalmente todas las fases de desarrollo de software con una misma
herramienta.
Facilitar el uso de las distintas metodologas propias de la ingeniera del software.
CLASIFICACIN DE LAS HERRAMIENTAS

Las herramientas CASE no tienen una sola clasificacin. De acuerdo a diferentes caractersticas, las
herramientas pueden ser agrupadas por:
Plataforma
Fases del ciclo de vida que cubren
Arquitectura de aplicaciones que producen
Funcionalidades
Veamos las clasificaciones de cada una:

PLATAFORMAS
La clasificacin por plataforma indica sobre qu arquitectura fsica trabajan (sistema operativo,
hardware, etc). En particular, la clasificacin tradicional al igual que cualquier lenguaje es la
siguiente:
Multiplataforma
Windows
Unix/Linux (y sus diferentes sabores)
MacOS
Otros
161

Tambin existen software compatibles entre plataformas, pero definitivamente depende un poco
del fabricante y de la tecnologa que utilicen para hacer cada herramienta.
FASES DEL CICLO DE VIDA DEL SOFTWARE
Esta es la clasificacin ms habitual de las herramientas, y se ha definido en 3 niveles:
Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin, anlisis de
requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y diseo de la

aplicacin.
Lower CASE (L-CASE), herramientas que semiautomatizan la generacin de cdigo, crean

programas de deteccin de errores, soportan la depuracin de programas y pruebas.
Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las
herramientas de desarrollo rpido de aplicaciones11.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin
excluyente entre s, ni con la anterior:
Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo

software, desde anlisis hasta implementacin.
MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado,

los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden
ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con
nuestros elementos, restricciones y relaciones posibles.
CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de

software.
IPSE (Integrated Programming Support Environment), herramientas que soportan todo el

ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la
configuracin.
ARQUITECTURAS PRODUCIDAS
En esta clasificacin se han definido los siguientes tipos de arquitectura producida:
11
Monoltica. Donde el software se estructura en grupos funcionales muy acoplados.
Cliente-servidor. Donde el software reparte su carga de cmputo en dos partes

independientes pero sin reparto claro de funciones.
Arquitectura de Tres Capas. Especializacin de la arquitectura cliente-servidor donde la

carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la
presentacin (interfaz de usuario), otra para el clculo (donde se encuentra modelado el
Ver http://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicaciones
162

negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relacin
con la siguiente.
Otras arquitecturas menos utilizadas incluyen la de pipeline, entre pares, en pizarra, orientada a
servicios y mquinas virtuales.
FUNCIONALIDADES
De acuerdo a sus funcionalidades, las herramientas se pueden agrupar de la siguiente forma:
Herramientas de generacin semiautomtica de cdigo.
Editores UML.
Herramientas de Refactorizacin de cdigo.
Herramientas de mantenimiento como los sistemas de control de versiones.
UML CASE-TOOL: STARUML

FICHA TCNICA
Nombre: StarUML
Empresa: Ninguna (Proyecto Open Source)
Versin Actual: 5.0
Tipo de Licencia: Open Source
Costos: Ninguno
Plataforma: Microsoft Windows
Idiomas: Ingls
Pgina Web: http://staruml.sourceforge.net/
DESCRIPCIN
Es un proyecto Open Source, por lo que es de descarga gratuita. Su ltima versin liberada a la
fecha de construccin de este apunte es la 5.0 y posee soporto para la notacin 2.0 de UML. Estn
continuamente en recoleccin de contribuidores quienes son premiados utilizando sus nombres
como valores aleatorios cuando se crean objetos.
Cada proyecto puede ser utilizado con estndares de diferente naturaleza (estilo Rational, UML
estndar, MDA, COM-Compatible, o personalizable).
Adems, posee capacidad de generacin de cdigos en C, C++, C#, Java, Visual Basic, VB.Net,
Delphi, JScript, VBScript, etc.
163

FUNCIONALIDADES
A continuacin veremos las diferentes funcionalidades para trabajar con la herramienta.
CREACIN DE UN PROYECTO
Al momento de iniciar StarUML, el arquitecto debe crear un nuevo proyecto, el cual define el
mbito de desarrollo de los modelos y artefactos que se desea realizar.
StarUML organiza los proyectos (modelos-artefactos) de acuerdo un estilo que debe ser
seleccionado al momento de ser creado. La idea central es que el estilo posee una organizacin de
modelos o vistas que deben ser completadas con los artefactos de UML por el arquitecto.
ILUSTRACIN 111. VENTANA DE INICIO DE STARUML
Los estilos de modelamiento disponible en la versin 5.0 son:
Aproximacin Estndar
Aproximacin Rational
Aproximacin de Componentes UML
Aproximacin de Modelo 4+1
Aproximacin Personalizada
El estilo utilizado para el desarrollo de los artefactos presentados en este apunte fue Rational, ya
que es el ms cercano al proceso de desarrollo personalizado que se utiliz, sin embargo, no se
descarta crear una aproximacin especial adecuada para el curso en el futuro12.
Adems, independientemente el tipo de aproximacin, StarUML no limita los artefactos a utilizar
en cada estilo, sino que finalmente es el arquitecto quien tiene la labor de organizar de la mejor
forma cada proyecto a desarrollar.
12
Este curso seguir siendo impartido y se pretende mejorar con el uso de StarUML.
164

Veamos en detalle cada aproximacin para entender las secciones siguientes:

APROXIMACIN ESTNDAR
La aproximacin estndar organiza el proyecto de acuerdo a 5 modelos:
Modelo de Casos de Uso: El centro de este modelo es el Diagrama de Casos de Uso, el cual
detalla el ambiente y la interaccin del sistema desde el punto de vista funcional a travs
de la utilizacin del artefacto del mismo nombre.
Modelo de Anlisis: El centro de este modelo es el Diagrama de Clases, en el cual se

define una primera aproximacin de la estructura de clases de diseo del sistema.
Modelo de Diseo: El centro de este modelo es el mismo Diagrama de Clases, sin

embargo, la utilizacin es para refinar la informacin preparando la implementacin.
Modelo de Implementacin: El centro de este modelo es el Diagrama de Componentes,

en donde se pueden organizar las clases de diseo modularmente segn lo aprendido en
este apunte.
Modelo de Despliegue: El centro de este modelo es el Diagrama de Despliegue (no

analizado en este apunte), en el cual se describen las componentes fsicas a travs de las
cuales ser instalado el sistema en la organizacin del cliente final.
APROXIMACIN RATIONAL
La aproximacin Rational hace referencia al proceso de desarrollo creado por The Three Amigos13
y organiza el proyecto de acuerdo a 4 vistas:
Vista de Casos de Uso: Esta vista pretende mostrar la descripcin funcional del proyecto
guiado a travs de los Casos de Uso del sistema. Su centro es el Diagrama de Casos de Uso.
Vista Lgica: Esta vista pretende mostrar la visin tanto de negocio como de
comportamiento del sistema desde el punto de vista lgico (no fsico). Su centro es el
Diagrama de Clases (conceptuales).
Vista de Componentes: Esta vista pretende mostrar la visin fsica del sistema incluyendo
componentes de software que deben ser implementados. Su centro es el Diagrama de
Componentes.
Vista de Despliegue: Esta vista pretende mostrar los artefactos de despliegue (instalacin)
del sistema de acuerdo a las necesidades modulares y funcionales del problema. Su centro
es el Diagrama de Despliegue.
APROXIMACIN DE COMPONENTES UML
La aproximacin de componentes UML est basada en la definicin original del lenguaje y organiza
el proyecto de acuerdo a 2 mbitos:
13
The Three Amigos: Booch, Jacobson y Rumbaugh, autores tambin del lenguaje de modelamiento UML.
165

mbito de Requerimientos: En este mbito se desarrollan los modelos relacionados con el

anlisis funcional del sistema. Incorpora por defecto los modelos de Conceptos del
Negocio y Casos de Uso.
mbito de Especificaciones: En este mbito se desarrollan los modelos relacionados con el

anlisis y diseo del sistema como tal. Incorpora por defecto los modelos de Tipos del
Negocio, Especificacin de Interfaz, Especificacin y Arquitectura de Componentes.
APROXIMACIN DE MODELO 4+1
La aproximacin de modelo-vista 4+114 est basada en arquitecturas de software de sistemas

intensivos y organiza el proyecto de acuerdo a 5 mbitos o vistas:
Escenarios: En este mbito se describen las secuencias de interaccin de objetos y

procesos de los casos de uso que definen la arquitectura 4+1 (Diagramas de Casos de Uso).
Vista Lgica: En este mbito se describen los diagramas que representan lgica del
negocio y del sistema (Diagramas de Comunicacin, Clases Conceptuales y Secuencia).
Vista de Desarrollo: En este mbito se describen los diagramas que representan la vista
del programador y de administracin del software (Diagramas de Componentes y
Paquetes).
Vista de Procesos: En este mbito se describen los diagramas que representan los
aspectos dinmicos del sistema, a nivel de procesos y comportamiento de ste (Diagramas
de Actividades).
Vista Fsica: En este mbito se describen los diagramas que representan la visin del
ingeniero en sistemas sobre las capas fsicas y la comunicacin entre las componentes
(Diagramas de Despliegue).
APROXIMACIN PERSONALIZADA
La aproximacin personalizada no define mbitos ni modelos, sino que un proyecto vaco dejando
el trabajo de organizacin del proyecto al arquitecto. Es muy til cuando el arquitecto no se siente
cmodo con ninguna de las otras aproximaciones disponibles.
ANATOMA DE LA HERRAMIENTA
StarUML posee diferentes regiones en donde se muestra informacin. Estas regiones son las
siguientes:
14
Men Principal: Men de acciones del programa (File, Edit, Format, Model, View, Tools y
Help).
Botonera Principal: Acciones disponibles desde la botonera superio.
Despliegue del Diagrama Actual: Espacio en donde se ve el diagrama seleccionado.
http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
166

Explorador del Modelo (Model Explorer): Espacio para ver la organizacin del proyecto a
partir de la aproximacin seleccionada.
Explorador de Diagramas (Diagram Explorer): Espacio para ver los diagramas del proyecto
ordenados por tipo de diagrama.
Propiedades (Properties): Espacio que muestra las propiedades del proyecto, modelo,
diagrama o elemento seleccionado, dependiendo de su tipo.
Documentacin (Documentation): Espacio estilo bloc de notas para hacer anotaciones del
objeto seleccionado.
Adjuntos (Attachments): Espacio que permite adjuntar archivos al objeto seleccionado.
Barra de Herramientas (Toolbox): Botonera dinmica que muestra los elementos de la

notacin del tipo de diagrama seleccionado.
Salidas (Output): Espacio que muestra la bitcora de cambios que se van realizando
durante la modificacin del proyecto.
La presentacin de la herramienta es la siguiente:
ILUSTRACIN 112. VENTANA PRINCIPAL DE STARUML
167

CREACIN DE DIAGRAMAS
Para crear un diagrama, ste debe ser incorporado a algn mbito del proyecto. Para ello se debe
seleccionar el mbito del proyecto, con el men Model o con el botn derecho, hacer clic en
Add Diagram y seleccionar el tipo de diagrama a realizar.
ILUSTRACIN 113. AGREGANDO UN DIAGRAMA EN STARUML
El resultado de esta operacin ser que se agregar bajo el mbito el nuevo diagrama del tipo
seleccionado y en el despliegue de la herramienta mostrar un lienzo en blanco para que se
comience a trabajar en l. Tambin existe un cambio en la barra de herramientas (Toolbox), la cual
cambia segn el tipo de diagrama seleccionado.
TIPOS DE DIAGRAMAS
Los diagramas bsicos que vienen con la versin 5.0 son los siguientes:
Diagrama de Clases
Diagrama de Casos de Uso
Diagramas de Secuencia y Colaboracin (con roles y sin roles)
Diagrama de Estados
Diagrama de Actividades
Diagrama de Componentes
Diagrama de Despliegue
Diagrama de Estructura Compuesta
Diagrama de Robustez
168

GENERACIN DE CDIGO FUENTE

Para poder generar cdigo fuente es importante incorporar al proyecto el lenguaje en el cual se
desea generar el cdigo. Esto se realiza a travs del men Model > Profiles.
ILUSTRACIN 114. VENTANA ADMINISTRADORA DE PERFILES DE STARUML
Al lado izquierdo se encuentran los perfiles disponibles (C++, C# y EJB) y al lado derecho los que ya
tiene incorporados el proyecto (Java y UML). Se debe incorporar cada perfil seleccionando su
cono a la izquierda y usando el botn Include > quedaran automticamente incorporados.
Cabe destacar que la generacin de cdigo se realiza a partir de las clases de diseo del sistema,
por lo que es importante que se utilicen tipos de datos acordes al lenguaje en su definicin.
Si ambos factores son cumplidos, se puede generar el cdigo en el lenguaje. Esto se realiza con el
men Tools luego el lenguaje deseado y Generate Code, lo que abrir una ventana como la
siguiente:
ILUSTRACIN 115. VENTANA DEL PASO 1 DE GENERACIN DE CDIGO DE STARUML
169

Es necesario seleccionar la vista, modelo o paquete del proyecto que contiene la definicin de las
clases de diseo, y luego presionar Next >.
Luego se requiere seleccionar las clases o paquetes de clases que van a ser utilizadas para generar
el cdigo. Como la definicin de las clases queda asociada al elemento, los atributos y operaciones
de las clases tambin se ven amarradas a dicha definicin.
Adems, se debe seleccionar la carpeta en donde se desea guardar el cdigo y presionar la accin
Next >.
170

Finalmente, es necesario fijar algunas opciones de generacin y estilo, finalizando el proceso con
la accin Next >, lo que comenzar a generar el cdigo. Una vez iniciado el proceso de
generacin, StarUML construir las clases .java de todos los elementos seleccionados en el paso 2.
RECOMENDACIONES Y BUENAS PRCTICAS
Para completar esa gua, se puede decir que:
Es importante acomodar la aproximacin al modelo ms cmodo que tiene el arquitecto

en cuestin. Lo ms probable sea que alguna de las aproximaciones sea suficiente, pero no
necesariamente exacto, as que se deber ajustar dicho modelo al que ms le acomode
siempre.
StarUML no apoya el proceso de generacin de los diagramas, sino que solo los permite
dibujar, lo que por supuesto es complejo para arquitectos poco experimentados. Por esta
razn es necesario que el arquitecto conozca su propia metodologa antes de dibujar los
diagramas.
Tal como se expresa en este apunte, los diagramas no lo son todo. StarUML permite
adjuntar archivos a los diferentes artefactos (por ejemplo, adjuntar los Casos de Uso en el
diagrama de CU lo que es recomendable hacer) para descripciones o artefactos de tipo
documento complementarios a los diagramas.
171

BIBLIOGRAFA
El material principal utilizado para estos apuntes es:
UML y Patrones
Craig Larman
Editorial Pearson Education
Adems, como material complementario, existen otros textos interesantes de consulta:
UML DeMistifyed: A Self Teaching Guide

Paul Kimmel
Editorial Mc Graw Hill
El Proceso Unificado de Desarrollo de Software

Ivar Jacobson, Grady Booch y James Rumbaugh
UML gota a gota

Martin Fowler
Editorial Addison Wesley
Ingeniera de Software Orientado a Objetos

Bertrand Meyer
Editorial Prentice Hall
Utilizacin de UML en Ingeniera del Software con Objetos y Componentes

Perdita Stevens, Rob Pooley
Ingeniera de Software Orientado a Objetos

Bernd Bruegge Allen Dutoit
The Unified Modeling Language Reference Manual

Grady Booch, James Rumbaugh, Ivar Jacobson
Gua del Usuario del Lenguaje Unificado de Modelado UML

Grady Booch, James Rumbaugh, Ivar Jacobson
Utilizacin de UML en Ingeniera de Software

Perdita Stevens
Learning UML 2.0

Kim Hamilton, Russell Miles
Editorial OReally
Manual de UML
Paul Kimmel
Editorial Mc Graw Hill
172

Object Oriented Analysis and Design

Mike ODocherty
Diseo Orientado a Objetos con UML

Ral Alarcn
Grupo Eidos
Orientacin al Objeto: Conceptos, Terminologa y Lenguajes

Miguel ngel Alarcn
http://www.javahispano.org
173

TABLA DE ILUSTRACIONES
Ilustracin 1. Notacin del Modelo de Objetos de OMT .................................................................. 19
Ilustracin 2. Notacin del Modelo Dinmico................................................................................... 20
Ilustracin 3. Notacin del Modelo Funcional .................................................................................. 22
Ilustracin 4. Iteraciones del Proceso Unificado de Desarrollo ........................................................ 23
Ilustracin 5. Fases del Proceso Unificado de Desarrollo ................................................................. 25
Ilustracin 6. Carga de Trabajo por Disciplina en el Proceso Unificado de Desarrollo ..................... 27
Ilustracin 7. Metamodelos Aplicados a la Metodologa .................................................................. 30
Ilustracin 8. Plantilla de Especificacin de Funciones ..................................................................... 40
Ilustracin 9. Continuacin de la Plantilla de Especificacin de Funciones ...................................... 41
Ilustracin 10. Plantilla de Especificacin de Funciones para el SPDV.............................................. 42
Ilustracin 11. Tabla de Identificacin de Actores y Objetivos ......................................................... 46
Ilustracin 12. Documento de Especificacin de Caso de Uso de Alto Nivel .................................... 46
Ilustracin 13. Documento de Especificacin de Caso de Uso Expandida ........................................ 47
Ilustracin 14. Notacin de los Diagramas de Casos de Uso ............................................................ 48
Ilustracin 15. Plantilla de Especificacin de Casos de Uso y Glosario ............................................. 49
Ilustracin 16. Diagrama de Casos de Uso del SPDV ......................................................................... 50
Ilustracin 17. Documento del Glosario............................................................................................ 50
Ilustracin 18. Glosario para el Problema del SPDV ......................................................................... 51
Ilustracin 19.Notacin de los Diagramas de Actividades ................................................................ 54
Ilustracin 20. Diagrama de Casos de Uso del SPDV ......................................................................... 54
Ilustracin 21. Diagrama de Actividades para el SPDV ..................................................................... 55
Ilustracin 22.Tabla de Identificacin de Clases conceptuales segn Categoras ............................ 57
Ilustracin 23.Anlisis de Clases conceptuales por Frases Nominales.............................................. 58
Ilustracin 24.Ejemplo de Asociacin de Clases conceptuales ......................................................... 59
Ilustracin 25.Tabla de Clasificacin de Multiplicidad ...................................................................... 60
174

Ilustracin 26.Notacin de los Diagramas de Clases Conceptuales .................................................. 62

Ilustracin 27.Diagrama de Actividades del SPDV ............................................................................ 63
Ilustracin 28.Diagrama de Clases conceptuales del SPDV............................................................... 63
Ilustracin 29. Notacin de los Diagramas de Secuencia .................................................................. 66
Ilustracin 30. Mensaje de Creacin de Objeto ................................................................................ 66
Ilustracin 31. Mensaje de Autodelegacin ...................................................................................... 67
Ilustracin 32. Diagrama de Secuencia para el proceso de venta (sin pago) del TPDV. ................... 67
Ilustracin 33. Notacin para los Contratos de las Operaciones ...................................................... 68
Ilustracin 34. Diagrama de Secuencia con las operaciones de la Venta ......................................... 69
Ilustracin 35. Contrato para la Operacin ingresarProducto del TPDV .......................................... 70
Ilustracin 36. Notacin de los Diagramas de Estado ....................................................................... 72
Ilustracin 37. Diagrama de Estados para el objeto venta del TPDV ................................................ 73
Ilustracin 38. Especificacin de Funciones del SEFP ....................................................................... 76
Ilustracin 39. Tabla de Actores y Objetivos del SEFP ...................................................................... 76
Ilustracin 40. Especificacin de Casos de Uso de Alto Nivel para el SEFP ....................................... 77
Ilustracin 41. Especificacin de CU Expandidos para el caso SEFP ................................................. 79
Ilustracin 42. Diagrama de Casos de Uso del SEFP.......................................................................... 80
Ilustracin 43. Glosario para el SEFP ................................................................................................. 80
Ilustracin 44. Diagrama de Actividades del SEFP ............................................................................ 82
Ilustracin 45. Identificacin de Clases conceptuales segn Categoras para el SEFP...................... 83
Ilustracin 46. Frases Nominales para Escenarios del SEFP .............................................................. 84
Ilustracin 47. Diagrama de Clases conceptuales del SEFP............................................................... 85
Ilustracin 48. Diagrama de Secuencia para el CU1. Registrar Paciente .......................................... 86
Ilustracin 49. Diagrama de Secuencia para el CU2. Consultar Historial .......................................... 86
Ilustracin 50. Diagrama de Secuencia para el CU3. Registrar Anamnesis ....................................... 87
Ilustracin 51. Diagrama de Secuencia para CU5. Registrar Resultado de Procedimiento .............. 88
Ilustracin 52. Diagrama de Secuencia para el CU7. Actualizar Agenda Mdica.............................. 88
175

Ilustracin 53. Contratos de las Operaciones del SEFP ..................................................................... 90

Ilustracin 54. Diagrama de Estados para FichaDePaciente del SEFP............................................... 90
Ilustracin 55. Tabla de Factores de la Arquitectura ........................................................................ 96
Ilustracin 56. Tabla de Factores de la Arquitectura del SPDV ......................................................... 96
Ilustracin 57. Tabla de Decisiones de la Arquitectura ..................................................................... 97
Ilustracin 58. Notacin de los Diagramas de Componentes ........................................................... 97
Ilustracin 59. Diagrama de Componentes del SPDV ....................................................................... 98
Ilustracin 60. Notacin de los Diagramas de Colaboracin .......................................................... 102
Ilustracin 61. Diagrama de Colaboracin de Ingresar Producto para TPDV ................................. 103
Ilustracin 62. Contrato de Operacin ingresar Producto del SPDV............................................... 105
Ilustracin 63. Delegacin de Responsabilidad de Experto de Informacin................................... 106
Ilustracin 64. Delegacin de Responsabilidad de Creador de Instancias ...................................... 107
Ilustracin 65. Identificacin del Controlador de las Operaciones del Sistema.............................. 109
Ilustracin 66. Notacin para los Diagramas de Clases de Diseo.................................................. 117
Ilustracin 67. Asociacin a nivel de Clases Conceptuales ............................................................. 117
Ilustracin 68. Asociacin a nivel de Clases de Diseo ................................................................... 117
Ilustracin 69. Identificacin de las Clases de Diseo ..................................................................... 118
Ilustracin 70. Identificacin de un Mtodo a partir de una Colaboracin .................................... 118
Ilustracin 71. Identificacin de Mtodos de las Clases ................................................................. 119
Ilustracin 72. Agregando Asociaciones con Navegabilidad ........................................................... 120
Ilustracin 73. Diagrama de Clases de Diseo Parcial para el SPDV ............................................... 121
Ilustracin 74. Diagrama de Clases de Diseo Refinado para el SPDV ........................................... 122
Ilustracin 75. Representacin en la Codificacin de la Clase ........................................................ 123
Ilustracin 76. Generalizacin de los Tipos de Pago en el SPDV ..................................................... 123
Ilustracin 77. Agregacin de Productos en el SPDV ...................................................................... 124
Ilustracin 78. Composicin de Lneas de Venta en el SPDV .......................................................... 125
Ilustracin 79. Asociaciones entre los Componentes Funcionales ................................................. 126
176

Ilustracin 80. Capa Funcional del SEFP .......................................................................................... 126

Ilustracin 81. Capas de Interfaz y Funcional del SEFP ................................................................... 127
Ilustracin 82. Capas de Compoentes del SEFP .............................................................................. 127
Ilustracin 83. Diagrama de Clases conceptuales del SEFP............................................................. 128
Ilustracin 84. Contrato de la Operacin validarRut....................................................................... 129
Ilustracin 85. Diagrama de Colaboracin para validarRut ............................................................ 130
Ilustracin 86. Contrato de la Operacin ingresarDetalle............................................................... 130
Ilustracin 87. Diagrama de Colaboracin para ingresaDetalle ...................................................... 131
Ilustracin 88. Contrato de la Operacin consultar ........................................................................ 131
Ilustracin 89. Diagrama de Colaboracin para validarRut modificado ......................................... 132
Ilustracin 90. Diagrama de Colaboracin para ingresarDetalle Modificado ................................. 132
Ilustracin 91. Diagrama de Colaboracin para consultar .............................................................. 132
Ilustracin 92. Contrato de la Operacin registrarInformacion ...................................................... 132
Ilustracin 93. Diagrama de Colaboracin de registrarAnamnesis ................................................. 133
Ilustracin 94. Diagrama de Colaboracin de registrarProcedimiento ........................................... 133
Ilustracin 95. Contrato de la Operacin cerrarAtencion ............................................................... 134
Ilustracin 96. Identificacin de Clases de Diseo y Atributos ....................................................... 134
Ilustracin 97. Detalle de Visibilidad y Tipos de Datos de Atributos .............................................. 135
Ilustracin 98. Descripcin de los Mtodos de las Clases ............................................................... 136
Ilustracin 99. Descripcin de Asociaciones entre las clases .......................................................... 137
Ilustracin 100. Diagrama de Clases de Diseo del SEFP ................................................................ 138
Ilustracin 101. Diagrama de Clases de Diseo del SPDV ............................................................... 142
Ilustracin 102. Diagrama de Clases de Normalizado al Lenguaje Java .......................................... 143
Ilustracin 103. Definicin de Cdigo para la Clase LineaDeVenta................................................. 144
Ilustracin 104. Identificacin del Atributo de Referencia de LineaDeVenta ................................. 144
Ilustracin 105. Especificando Atributos del Contenedor Venta .................................................... 145
Ilustracin 106. Colaboracin para agregarProducto en la Venta Actual ....................................... 146
177

Ilustracin 107. Especificacin del Cuerpo de la Operacin agregarProducto ............................... 146

Ilustracin 108. Diagrama de Clases de Implementacin para el SPDV ......................................... 147
Ilustracin 109. Diagrama de Clases de Diseo con Tipos de Datos Java del SEFP ......................... 150
Ilustracin 110. Diagrama de Clases de Implementacin Completo del SEFP ................................ 151
Ilustracin 111. Ventana de Inicio de StarUML ............................................................................... 164
Ilustracin 112. Ventana Principal de StarUML .............................................................................. 167
Ilustracin 113. Agregando un Diagrama en StarUML .................................................................... 168
Ilustracin 114. Ventana Administradora de Perfiles de StarUML ................................................. 169
Ilustracin 115. Ventana del Paso 1 de Generacin de Cdigo de StarUML .................................. 169
178

Análisis y Diseño Orientado Al Objeto

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Análisis y Diseño Orientado Al Objeto

Cargado por

Copyright:

Formatos disponibles

ANLISIS Y DISEO ORIENTADO AL

Prof. Andrs Muoz Ordenes

Anlisis y Diseo Orientado al Objeto

UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETO .............. 9

METODOLOGAS DE MODELAMIENTO ......................................................................................... 16

El Proceso Unificado (UP) de Desarrollo de Software .................................................. 22

EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML) .................................................................. 28

Anlisis y Diseo Orientado al Objeto

UNIDAD II. EL ANLISIS ORIENTADO AL OBJETO ........................................ 37

MODELO DE CASOS DE USO ..................................................................................................... 42

Artefactos del Modelo .................................................................................................. 44

Artefactos del Modelo .................................................................................................. 53

Anlisis y Diseo Orientado al Objeto

Artefactos del Modelo .................................................................................................. 65

CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ..................................... 73

Modelo de Comportamiento ........................................................................................ 85

UNIDAD III. EL DISEO ORIENTADO AL OBJETO ......................................... 91

Artefactos del Modelo .................................................................................................. 95

MODELO DE DISEO ............................................................................................................... 98

Artefactos del Modelo ................................................................................................ 101

Anlisis y Diseo Orientado al Objeto

Diagramas de Colaboracin ................................................................................................ 101

CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ................................... 125

Modelo de Diseo ....................................................................................................... 128

UNIDAD IV: INTRODUCCIN A LA IMPLEMENTACIN.............................. 139

Artefactos del Modelo ................................................................................................ 142

CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ................................... 149

ANEXOS ................................................................................................... 155

Modelo de Casos de Uso ............................................................................................. 156

Glosario ....................................................................................................................... 157

Anlisis y Diseo Orientado al Objeto

Diagrama de Clases Conceptuales....................................................................................... 157

Modelo de Comportamiento ...................................................................................... 157

Modelo Arquitectnico ............................................................................................... 158

Modelo de Diseo ....................................................................................................... 158

Modelo de Implementacin ........................................................................................ 159

GUA DE USO DE STARUML ................................................................................................... 160

UML Case-Tool: StarUML ............................................................................................ 163

BIBLIOGRAFA ...................................................................................................................... 172

Anlisis y Diseo Orientado al Objeto

Anlisis y Diseo Orientado al Objeto

En la Unidad I se abordan los conceptos bsicos del modelamiento orientado al objeto, su

En la Unidad II se desarrollan los modelos y artefactos en UML correspondientes a la

En la Unidad III se desarrollan los modelos y artefactos en UML correspondientes a la

En la Unidad IV se introduce una tcnica para la conversin del diseo a cdigo,

Anlisis y Diseo Orientado al Objeto

UNIDAD I. LA BASE DEL MODELAMIENTO

Anlisis y Diseo Orientado al Objeto

FUNDAMENTOS DE LA ORIENTACIN AL OBJETO

Anlisis y Diseo Orientado al Objeto

CARACTERSTICA CON LA CUAL SE PUEDE DIFERENCIA A LOS OBJETOS

Anlisis y Diseo Orientado al Objeto

UNA OPERACIN O MTODO ES UNA ACCIN QUE PUEDE REALIZAR

REPRESENTACIN INTERNA DE UNA CLASE (ATRIBUTOS) UTILIZANDO

Anlisis y Diseo Orientado al Objeto

LA HERENCIA ES EL MECANISMO A TRAVS DEL CUAL SE GENERAN

Sistema marcador que permite marcar un nmero telefnico

Auricular que permite hablar y escuchar a travs de l

Campanilla o timbre que me permite escuchar cuando alguien llama

Conectar a otro telfono

Recibir una llamada de otro telfono

Colgar el telfono para finalizar una llamada

Anlisis y Diseo Orientado al Objeto