Andres Munoz - Analisis y Diseno Orientado Al Objeto

AA NN ÁÁ LL II SS II SS YY DD II SS EE ÑÑ OO OO RR II EE NN TT AA DD OO AA LL

OO BB JJ EE TT OO

APU NTE S DE MO DELAMIE NTO DE S I STEM AS U SAN DO UML Y UP

Prof. Andrés Muñoz Ordenes

Carrera de Ingeniería en Computación e Informática

Instituto Profesional La Araucana

Análisis y Diseño Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniería en Computación e Informática Instituto Profesional La Araucana

2

TABLA DE CONTENIDO

INTRODUCCIÓN ........................................................................................... 7

RESUMEN EJECUTIVO ................................................................................................................ 8

AGREDECIMIENTOS ................................................................................................................... 8

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

FUNDAMENTOS DE LA ORIENTACIÓN AL OBJETO ........................................................................... 10

Objeto .................................................................................................................................... 10

Clase ...................................................................................................................................... 10

Instancias ............................................................................................................................... 11

Atributos y Operaciones ........................................................................................................ 11

Mensajes ............................................................................................................................... 12

Encapsulamiento ................................................................................................................... 12

Herencia ................................................................................................................................ 12

Abstracción ............................................................................................................................ 13

Modularidad .......................................................................................................................... 14

Reutilización .......................................................................................................................... 15

Polimorfismo ......................................................................................................................... 16

METODOLOGÍAS DE MODELAMIENTO ......................................................................................... 16

La Técnica de Modelado de Objetos (OMT).................................................................. 17

Fases de la Metodología ........................................................................................................ 17

Los Modelos, Diagramas y Su Notación ................................................................................ 18

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

UP y el Desarrollo Iterativo Incremental ............................................................................... 22

La Retroalimentación y la Adaptación: Filosofías de UP ....................................................... 24

La Arquitectura: El Centro de UP .......................................................................................... 24

Las Fases del UP .................................................................................................................... 25

Disciplinas del UP .................................................................................................................. 26

Otros Conceptos Orientados a la Planificación ..................................................................... 27

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

¿Qué es UML? ............................................................................................................... 28

Visión General de los Metamodelos UML Aplicados al A/DOO .................................... 29

Modelo de Dominio............................................................................................................... 30

Modelo de Casos de Uso ....................................................................................................... 31

Modelo de Análisis ................................................................................................................ 32

Modelo Arquitectónico ......................................................................................................... 33

Modelo de Diseño ................................................................................................................. 34

Modelo de Implementación .................................................................................................. 35


3

UNIDAD II. EL ANÁLISIS ORIENTADO AL OBJETO ........................................ 37

FUNDAMENTOS DEL ANÁLISIS DE SOFTWARE ............................................................................... 38

Características de los Requerimientos .......................................................................... 38

Clasificación de los Requerimientos ............................................................................. 38

ESPECIFICACIÓN DE REQUISITOS ................................................................................................ 39

Técnica de Especificación 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 Básicos ......................................................................................................... 43

Actor ...................................................................................................................................... 43

Escenario ............................................................................................................................... 43

Caso de Uso ........................................................................................................................... 43

Responsabilidad .................................................................................................................... 44

Formalidad ............................................................................................................................ 44

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

Proceso de Desarrollo del Modelo ................................................................................ 45

Identificación de Casos de Uso .............................................................................................. 45

Especificación de Casos de Uso ............................................................................................. 46

Diagrama de Casos de Uso .................................................................................................... 48

GLOSARIO ............................................................................................................................. 50

MODELO DE DOMINIO ............................................................................................................ 51


Dominio ................................................................................................................................. 51

Clases Conceptuales .............................................................................................................. 52

Proceso .................................................................................................................................. 52



Especificación del Proceso de Negocio ................................................................................. 53

Identificación de Clases Conceptuales .................................................................................. 55

Diagrama de Clases Conceptuales......................................................................................... 62

MODELO DE COMPORTAMIENTO ............................................................................................... 64


Evento.................................................................................................................................... 64

Contrato ................................................................................................................................ 64


4

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 ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP) ..................................... 73

Especificación de Funciones .......................................................................................... 74

Modelo de Casos de Uso ............................................................................................... 76

Especificación 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 DISEÑO ORIENTADO AL OBJETO ......................................... 91

FUNDAMENTOS DEL DISEÑO DE SOFTWARE ................................................................................. 92

La Arquitectura del Software ........................................................................................ 92

MODELO ARQUITECTÓNICO ..................................................................................................... 94


Refinamiento ......................................................................................................................... 94

Componente .......................................................................................................................... 95



Especificación de los Factores de la Arquitectura ................................................................. 95

Especificación de las Decisiones de la arquitectura .............................................................. 96

Diagrama de Componentes ................................................................................................... 97

MODELO DE DISEÑO ............................................................................................................... 98


Realización de Caso de Uso ................................................................................................... 99

Responsabilidad .................................................................................................................... 99

Patrones de Diseño ............................................................................................................. 100

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

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


5

Diagramas de Colaboración ................................................................................................ 101

Patrones de Diseño GRASP .................................................................................................. 103

Patrones de Diseño GoF ...................................................................................................... 112

Diagrama de Clases de Diseño ............................................................................................ 115

CASO DE ESTUDIO: SISTEMA ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP) ................................... 125

Modelo Arquitectónico ............................................................................................... 125

Diagrama de Componentes ................................................................................................. 125

Modelo de Diseño ....................................................................................................... 128



UNIDAD IV: INTRODUCCIÓN A LA IMPLEMENTACIÓN .............................. 139

FUNDAMENTOS DE LA IMPLEMENTACIÓN DEL SOFTWARE ............................................................. 140

Codificación de Calidad ............................................................................................... 140

Estándares de Codificación ......................................................................................... 140

Herramientas CASE ..................................................................................................... 141

MODELO DE IMPLEMENTACIÓN ............................................................................................... 141

Conceptos Básicos ....................................................................................................... 141

Código .................................................................................................................................. 141

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

Proceso de Desarrollo del Modelo .............................................................................. 142

Diagrama de Clases de Implementación ............................................................................. 142

Estructura del Código .......................................................................................................... 147

CASO DE ESTUDIO: SISTEMA ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP) ................................... 149

Modelo de Implementación ........................................................................................ 149


Estructura de Clases ............................................................................................................ 151

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

PLANTILLA DE DOCUMENTACIÓN DEL A/DOO ........................................................................... 156

Especificación de Requisitos ....................................................................................... 156

Identificación del Sistema ................................................................................................... 156

Especificación de Funciones ................................................................................................ 156

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

Especificación de Casos de Uso ........................................................................................... 156

Diagrama de Casos de Uso .................................................................................................. 157

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

Modelo de Dominio .................................................................................................... 157

Diagrama de Actividades ..................................................................................................... 157


6

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

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

Diagramas de Secuencia ...................................................................................................... 158

Contratos de las Operaciones ............................................................................................. 158

Diagramas de Estado ........................................................................................................... 158

Modelo Arquitectónico ............................................................................................... 158

Diagrama de Componentes ................................................................................................. 158

Modelo de Diseño ....................................................................................................... 158



Modelo de Implementación ........................................................................................ 159


Estructura de Clases ............................................................................................................ 159

GUÍA DE USO DE STARUML ................................................................................................... 160

Introducción a las Herramientas CASE ........................................................................ 160

Historia ................................................................................................................................ 160

Objetivos ............................................................................................................................. 160

Clasificación de las Herramientas ........................................................................................ 161

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

Ficha Técnica ....................................................................................................................... 163

Descripción .......................................................................................................................... 163

Funcionalidades ................................................................................................................... 164

Recomendaciones y Buenas Prácticas ................................................................................ 171

BIBLIOGRAFÍA ...................................................................................................................... 172

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


7

INTRODUCCIÓN


8

RESUMEN EJECUTIVO

Este documento contiene una compilación de clases y apuntes del curso de Diseño Orientado al

Objeto dictado por el profesor Andrés Muñoz O. durante 3 años seguidos a alumnos de quinto

semestre de la carrera de Ingeniería en Computación en Informática del Instituto Profesional La

Araucana.

Los contenidos principales se dividen en 4 unidades:

En la Unidad I se abordan los conceptos básicos del modelamiento orientado al objeto, su

historia y la descripción 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 análisis 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 diseño de sistema del proceso de desarrollo.

En la Unidad IV se introduce una técnica para la conversión del diseño a código,

preparando la construcción del software.

El contenido de este documento puede ser utilizado como apuntes de curso, material de apoyo

para otros profesores como también de alumnos de carreras a fines o similares, solo con la debida

citación del autor.

Cualquier colaboración para mejorar este apunte, por favor enviarla a [email protected].

AGREDECIMIENTOS

Agradezco profundamente a mis alumnos del instituto de los años 2007, 2008 y 2009, quienes

recibieron este apunte clase a clase, y por supuesto fueron informando todo tipo de errores e

inconsistencias que encontraban.

Además, agradecer el apoyo y confianza de los profesores Raúl Rojas y Nelson Carvallo, quienes me

dieron la oportunidad de lograr desarrollar este ramo. También al profesor Daniel Muñoz G., quien

también utilizó en su curso esta información, validando la aplicabilidad de este contenido

desarrollado.

Y por último, a mi esposa quién fue comprensiva cuando trabajaba dedicadamente en estos

apuntes en la comodidad de mi hogar.

A todos, muchas gracias.

Profesor Andrés Muñoz O.

mailto:[email protected]


9

UNIDAD I. LA BASE DEL MODELAMIENTO

ORIENTADO AL OBJETO

El objetivo de esta unidad es entender cómo los conceptos de la orientación al

objeto también son aplicables en el modelamiento de un software y además cómo

su uso puede ser beneficioso desde el punto de vista del producto de software que

espera el cliente obtener.


10

FUNDAMENTOS DE LA ORIENTACIÓN AL OBJETO

Para comenzar, veamos cuáles son los conceptos básicos que define la Orientación 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 lápiz 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 microbús del Transantiago que me trae al instituto, el semáforo que me hizo llegar

tarde, etc. Todos estos ejemplos representan distintas cosas que vemos, tocamos, usamos, oímos

y entendemos como objetos de nuestra realidad.

Pues, la definición de lo que es un objeto en OO no está alejada de esa realidad, porque un objeto

no es más que cualquier cosa con la cual se interactúa. Así, podemos decir que:

UN OBJETO ES CUALQUIER COSA “REAL O ABSTRACTA” QUE POSEA

ATRIBUTOS, SE PUEDA ALMACENAR INFORMACIÓN 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 diseñar la estructura

de la información incorporaremos objetos para representar cada entidad o elemento que

interactúa dentro del sistema.

Por ejemplo, una Factura es un objeto ya que posee un código de factura, información de a quien

se le está entregando esa factura, la información 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 información, 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

genérico de dicho tipo. Es así como definimos que:

UNA CLASE ES UNA CLASIFICACIÓN ABSTRACTA, BAJO LA CUAL

AGRUPAMOS UN CONJUNTO DE OBJETOS QUE POSEEN EL MISMO

TIPO DE CARACTERÍSTICAS Y LAS MISMAS OPERACIONES.

Cuando hablamos del mismo tipo de características, queremos decir que las clases definen todos

aquellos objetos que podemos definirlos con la misma plantilla.


11

Por ejemplo, la clase Perro es una clasificación que hacemos para definir los animales que tiene 4

patas, 2 orejas, que ladran, jadean y que son utilizados como compañía 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 características que lo hacen único entre sus pares: color

de pelo, largo de pelo, talla, peso, frecuencia de ladrido, etc.

INSTANCIAS

La distinción que hacemos entre una clase y un objeto generalmente no es fácil de digerir, pues en

muchos casos tienden a confundirse. Sin embargo, definiremos el concepto de instancia para

hacer más 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 relación 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 través de atributos y operaciones. De esta forma, definiremos que:

UN ATRIBUTO ES UN DATO QUE PERMITE DEFINIR UNA

CARACTERÍSTICA 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 través del

tiempo. De esta forma, dos objetos de la misma clase podrían tener diferente información en

ellos, o simplemente el objeto podría ir variando su atributo a medida que su ciclo de vida vaya

avanzando.

Por ejemplo, toda Persona posee características como Talla, Peso y Edad. Estos tres atributos van

variando a través del tiempo y también son distintos para diferentes instancias de Persona. Así,

María Eliana tiene 26 años, mide 1 metro 64 centímetros y pesa 58 kilógramos, en cambio, Pedro

tiene 47 años, mide 1 metro 82 centímetros y pesa 75 kilógramos. El próximo año ambos

cambiaran su edad, d forma que María Eliana tendrá 27 años y Pedro 48.

Por otro lado, decimos que:


12

UNA OPERACIÓN O MÉTODO ES UNA ACCIÓN 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 automáticamente adhieren esa acción 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 operación de Giro o Depósitos, el saldo de la cuenta varía.

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.

Aún cuando esta definición es muy básica (y casi abstracta), la lógica de mensajes en el A/DOO

tiene la misma simplicidad, es decir, los mensajes son solo el medio de interacción que los objetos

ocupan para comunicarse entre sí y con el medio ambiente.

ENCAPSULAMIENTO

Dentro del diseño OO es muy importante tener en cuenta que nuestros sistemas no interactúan

directamente con los atributos de los objetos. Por lo que definimos un nuevo concepto como:

ENCAPSULAMIENTO ES LA CAPACIDAD DE OCULTAR LA

REPRESENTACIÓN INTERNA DE UNA CLASE (ATRIBUTOS) UTILIZANDO

OPERACIONES RELACIONADAS CON LAS FUNCIONALIDADES DEL

MISMO.

Con esta herramienta, no necesitamos conocer la definición interna de un objeto, sino que es

importante saber cuáles son las operaciones con las cuales se puede interactuar.

HERENCIA

Otro concepto muy utilizado es la herencia. Aún cuando no tenga nada que ver con dinero de

algún familiar, la herencia es, por decirlo así, la capacidad de entregar atributos y operaciones

entre clases de cierto parentesco. De esta forma definiremos:


13

LA HERENCIA ES EL MECANISMO A TRAVÉS DEL CUAL SE GENERAN

CLASES QUE COMPARTEN ALGUNOS ATRIBUTOS Y OPERACIONES,

PERO QUE EN SU ESENCIA SON CONSIDERADOS COMO DISTINTOS.

Con esta definición encontraremos diferentes soluciones a problemas similares, ya que nos abre

una serie de posibilidades sin restricción.

Por ejemplo, si hablamos de la clase Teléfono. Esta clase posee atributos que son conocidos:

Sistema marcador que permite marcar un número telefónico

Auricular que permite hablar y escuchar a través 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 teléfono

Recibir una llamada de otro teléfono

Hablar con una persona que está al otro lado del teléfono

Colgar el teléfono para finalizar una llamada

Aún así, y tal como hemos visto anteriormente, estoy hablando de todos los teléfonos que existen. Sin embargo, podemos subdividir esta clase en dos grupos: Teléfonos Fijos y Teléfono Celulares. Ambos grupos comparten los atributos y operaciones anteriormente mencionadas porque son todos del tipo Teléfono, pero cada uno puede tener algunas otras características que lo hace diferente con respecto al otro.

ABSTRACCIÓN

Como parte del diseño OO, este concepto es una verdadera herramienta en el modelamiento. Así,

para entender más el término, definimos:

LA ABSTRACCIÓN ES LA REPRESENTACIÓN DE LAS CARACTERÍSTICAS Y

FUNCIONALIDADES ESENCIALES DE UN OBJETO, DESDE EL PUNTO DE

VISTA DEL OBSERVADOR, SIN DETALLAR NI ESPECIFICAR SU

IMPLEMENTACIÓN INTERNA.

Este concepto tiene por fin el “descomplejizar” el diseño, con respecto a la implementación futura.

En efecto, cuando estamos diseñando 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 implementación de cada uno hasta el momento en que los programadores

deban comenzar a implementarlos, utilizando herramientas e instrucciones predecibles según

nuestra experiencia.

Por ejemplo, si consideramos a la clase Complejo bajo nuestro prisma de abstracción podemos

mencionar algunas de sus funcionalidades:


14

Crear un objeto de tipo Complejo.

Sumarle otro Complejo.

Restarle otro Complejo.

Obtener su parte real o su parte imaginaria.

Amplificarlo por un número.

Etc.

Al leer esta definición de funcionalidades, podemos rápidamente percatarnos que no hemos hablado nunca en cómo están implementadas, sino que esas son las funcionalidades que podemos utilizar de la clase. Más aún, ni siquiera hablamos de la representación interna de la clase, porque para nosotros es transparente.

Es muy importante destacar que la abstracción nos permite fácilmente ver un conjunto de definiciones y operaciones de un objeto como algo “funcional”, sin reparar en sus detalles, porque es una característica humana. ¿Alguien se ha preocupado de que el ser humano sea un conjunto de células y seres microscópicos que realizan todas las labores que podemos ver? Además de los estudiosos de la materia, para nosotros un ser humano no es más 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 más “avanzados” pero que

tienen mucho que ver con el Diseño OO. Por ejemplo, decimos que:

LA MODULARIDAD ES LA CAPACIDAD DE PARCELAR CARACTERÍSTICAS

Y FUNCIONALIDADES DE UN SISTEMA, EN PAQUETES DE PROGRAMAS

INDEPENDIENTES CON EL RESTO.

Desde el punto de vista de programación, este concepto es fácil de entender, ya esas

características y funcionalidades son identificables dentro de la implementación de las clases el

sistema. Sin embargo, desde el punto de vista del diseño 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 implementación 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:

Administración de Empleados

Emisión de Sueldos

Emisión de Reportes

Etc.


15

Ya con esta sencilla división obtenemos “módulos” que son considerados independientes con respecto a los demás. Sin embargo, esos módulos pueden ser mucho más específicos, por ejemplo:

Ingreso de Nuevo Empleado

Modificación de Empleado

Eliminación de Empleado

Mandato de Pago de Sueldos

Emisión de Liquidaciones de Sueldo

Emisión de Reporte de Sueldos Pagados

Emisión de Reporte de Sueldos de Empleados

Emisión de Certificado de Rentas

Etc.

Como pueden ver, los “módulos” 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 módulos sean más 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 diseño tiene que ver con la capacidad de reunir funcionalidades o eventos del sistema que sean atómicos, de manera tal de independizar cada módulo para que integren un sistema como si fuera un verdadero lego.

REUTILIZACIÓN

Este concepto es uno de los más importantes temas que resuelve un buen diseño OO, y a su vez,

es una consecuencia de una buena modularidad. Entonces, diremos que:

LA REUTILIZACIÓN ES EL MECANISMO O PROCEDIMIENTO A TRAVÉS

DEL CUAL ES POSIBLE UTILIZAR DEFINICIONES DE CLASES Y/O

MÓDULOS YA EXISTENTES, EN UN PROBLEMA NUEVO, DE MANERA

ÍNTEGRA O CON ALGÚN NIVEL DE ADAPTACIÓN.

Por mucho tiempo, la ingeniería de software se ha dedicado a industrializar procesos de manera

de poder reutilizarlos en distintos problemas en forma “reiterativa”. Sin embargo, la lógica 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 reutilización dentro de

otros sistemas.

Es así como aparecen cada vez más herramientas que hacen más genéricas las soluciones. Por

ejemplo, en el despliegue de las páginas web, los diseñadores de los programas navegadores de

Internet se preocupan solo de aprender a interpretar el lenguaje de hipertexto (HTML) de manera

Administración de Empleados

Emisión de Sueldos

Emisión de Reportes


16

íntegra. Sin embargo, ese mismo módulo intérprete puede ser usado en cualquiera de los

navegadores en forma transparente.

POLIMORFISMO

Recordando lo que conocemos desde la programación, este concepto es más o menos similar. Así,

definiremos que:

EL POLIMORFISMO ES LA CAPACIDAD DE QUE UNA MISMA

OPERACIÓN PUEDA REALIZARSE DE FORMAS DISTINTAS EN CLASES

DISTINTAS.

Como podemos ver, el concepto es el mismo, desde el punto de vista del diseño, como de la

programación, porque trata de explicar cómo la implementación de las operaciones pueden variar

según la utilidad y momento en la cual deben ser utilizadas.

Por ejemplo, si hablamos de una clase Polígono, podemos definir sus operaciones:

perímetro: Obtiene el valor del perímetro del polígono.

área: Obtiene el valor del área del polígono.

altura: Obtiene la altura del polígono.

Utilizando la abstracción, no hemos definido cuál es la implementación de ninguna de estas operaciones, las cuales sabemos (por nuestros conocimientos de matemáticas) que dependiendo del polígono, las fórmulas varían.

Ahora bien definiremos 2 clases que heredan de Polígono: La clase Rectángulo y la clase Triángulo.

Tanto para Rectángulo como para Triángulo, la operación perímetro se calcula como la suma de los lados de la figura (los 4 lados cuando es cuadrado y 3 lados cuando es triángulo). Sin embargo, la “implementación” varía cuando hablamos de área y de altura, porque ambas figuras tienen diferentes fórmulas para calcularlas:

El área de un rectángulo es el producto del lado más corto por el lado más largo, en cambio, el área de un triángulo es la mitad del producto de la base por la altura.

La altura de un rectángulo es igual al tamaño del lado perpendicular a la base, en cambio, la altura de un triángulo es el tamaño del segmento de la recta que pasa por el vértice superior y que es perpendicular a la base.

Sin entrar en terreno “computacional” vemos que la misma operación definida desde el punto de vista abstracto en la clase Polígono se ve enfrentado a diferentes fórmulas, pero el comportamiento sigue siendo el mismo (el calcular el perímetro, área y altura).

METODOLOGÍAS DE MODELAMIENTO

Para comenzar, debes entender que:


17

UNA METODOLOGÍA 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 IMPLEMENTACIÓN DE UN SISTEMA.

En particular, las Metodologías de Modelamiento Orientado al Objeto son un enfoque de la

ingeniería de software que nos permite modelar un sistema como un grupo de objetos que

interactúan entre sí. Este enfoque representa un dominio en términos de conceptos compuestos

por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

En éste método de análisis y diseño se crea un conjunto de técnicas utilizando una notación

acordada. A continuación estudiaremos 2 metodologías modernas con las cuales se puede realizar

A/DOO.

LA TÉCNICA DE MODELADO DE OBJETOS (OMT) 1

La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael

Blaha en 1991, mientras James dirigía un equipo de investigación de los laboratorios General

Electric.

OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y

eficientes que existen. La gran virtud que aporta esta metodología es su carácter de abierta (no

propietaria), que le permite ser de dominio público y, en consecuencia, sobrevivir con enorme

vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la

ingeniería de software.

FASES DE LA METODOLOGÍA

Al igual que cualquier metodología, OMT se compone de cierta “receta” que debe cumplir. Las

fases que conforman la metodología son:

Análisis. El analista construye un modelo del dominio del problema, mostrando sus

propiedades más importantes. El modelo de análisis es una abstracción 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 aplicación y no conceptos

informáticos 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

informáticos.

Diseño del Sistema. El diseñador del sistema toma decisiones de alto nivel sobre la

arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas

basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se

selecciona una estrategia para afrontar el problema.

1 Ver OMT en http://www.monografias.com/trabajos13/metomt/metomt.shtml

http://www.monografias.com/trabajos13/metomt/metomt.shtml


18

Diseño de Objetos. El diseñador de objetos construye un modelo de diseño basándose en

el modelo de análisis, pero incorporando detalles de implementación. El diseño 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 diseño puede ser implementado en distintos

lenguajes (orientados y no orientados a objetos, bases de datos, etc.).

Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis de

objetos se traducen finalmente a una implementación concreta. Durante la fase de

implementación es importante tener en cuenta los principios de la ingeniería del software

de forma que la correspondencia con el diseño sea directa y el sistema implementado sea

flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que

potenciemos la reutilización de código y la correspondencia entre el dominio del problema

y el sistema informático, si luego perdemos todas estas ventajas con una implementación

de mala calidad.

LOS MODELOS, DIAGRAMAS Y SU NOTACIÓN

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 ESTÁTICA 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

dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que

sean importantes para la aplicación. Se representa mediante diagramas de objetos.

La definición clara de las entidades que intervienen en el sistema es un paso inicial necesario para

poder definir qué transformaciones ocurren en ellas y cuándo se producen estas

transformaciones. Esta forma de pensar es inherente al paradigma de OO donde las clases y su

jerarquía determinan el sistema.

Los diagramas de objetos permiten representar gráficamente 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 permitirán la creación 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 construcción del Modelo de Objetos, es importante seguir ciertos puntos esenciales de la

metodología:


19

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 según sea

necesario.

Agrupar las clases en módulos, basándose en "acoplamiento cercano" y función

relacionada.

La Notación del Modelo se puede describir en la siguiente cartilla:

ILUSTRACIÓN 1. NOTACIÓN DEL MODELO DE OBJETOS DE OMT

MODELO DINÁMICO

EL MODELO DINÁMICO DESCRIBE LOS ASPECTOS DE UN SISTEMA

QUE TRATAN DE LA TEMPORIZACIÓN Y SECUENCIA DE OPERACIONES

(SUCESOS QUE MARCAN LOS CAMBIOS, SECUENCIAS DE SUCESOS,

ESTADOS QUE DEFINEN EL CONTEXTO PARA LOS SUCESOS) Y LA

ORGANIZACIÓN DE SUCESOS Y ESTADOS.


20

Los conceptos más importantes del modelado dinámico son los sucesos, que representan

estímulos 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 estímulo 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 envío 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 dinámico consta de

múltiples diagramas de estados, con un diagrama de estados para cada clase que posea un

comportamiento dinámico importante, y muestra la trama de actividad para todo el sistema.

En resumen, los aspectos del sistema que están relacionados con el tiempo y con los cambios

constituyen el modelo dinámico.

La notación del Modelo Dinámico se puede observar en la siguiente cartilla:

ILUSTRACIÓN 2. NOTACIÓN DEL MODELO DINÁMICO

Para la construcción del modelo, es necesario definir y realizar algunas actividades:


21

Preparar escenarios para las secuencias de interacción típicas.

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

dinámico 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 cálculo a partir de

los valores introducidos, sin tener en cuenta el orden en el cual se calculan los valores. Consta de

múltiples diagramas de flujo de datos, que muestran el flujo de valores desde las entradas

externas, a través de las operaciones y almacenes internos de datos hasta las salidas externas.

También incluyen restricciones entre valores dentro del modelo de objetos. Los diagramas de flujo

de datos no muestran el control ni tampoco información acerca de la estructura de los objetos;

todo esto pertenece a los modelos dinámico y de objetos.

El modelo funcional consta de múltiples 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 información de control como puede ser el momento en que se ejecutan los procesos o

se toman decisiones entre vías de datos alternativas; esta información pertenece al modelo

dinámico. Un diagrama de flujo de datos no muestra la organización de los valores en objetos; esta

información 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 construcción 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.


22

Describir las funciones.

Identificar restricciones.

Especificar criterios de optimización.

La notación se puede resumir en la siguiente cartilla:

ILUSTRACIÓN 3. NOTACIÓN 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 metodología 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 metodología, con la diferencia que el segundo es una versión “comercial” de

la misma metodología y apoyada con un paquete de software específico (Rational Rose

actualmente de IBM).

UP Y EL DESARROLLO ITERATIVO INCREMENTAL

La primera distinción 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

subdivisión en mini-proyectos se les llama Iteraciones. De esta forma, tenemos que:


23

UNA ITERACIÓN ES UN INTERVALO DE TIEMPO DENTRO DEL

PROYECTO, EN DONDE SE RESUELVE PARTE DE LA PROBLEMÁTICA

ENTREGANDO UN MINI-SISTEMA QUE PUEDE SER PROBADO,

INTEGRADO Y EJECUTADO.

La duración de una iteración es variable, a pesar de que cada una siempre es un tiempo corto, este

tiempo puede ser desde días como algunas semanas. Entre más largas son las iteraciones más

complejos son los mini-proyectos, por lo que se complejiza más el desarrollo. Los expertos dicen

que una duración adecuada va entre 2 a 6 semanas. Sin embargo, la duración de cada iteración

depende directamente de los objetivos de la misma.

Requerimientos

Diseño

Implementación

Integración &

Pruebas

Requerimientos

Diseño

Implementación

Integración &

Pruebas

Iteración El Producto va creciendo a medida que se va

avanzando en el proyecto

Tiempo

ILUSTRACIÓN 4. ITERACIONES DEL PROCESO UNIFICADO DE DESARROLLO

Mientras se va avanzando en el proyecto, cada vez que hacemos una nueva iteración, el producto

final va incrementando su tamaño, lo que lo convierte en un proceso incremental. Los mini-

proyectos 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 término en donde el sistema

“cumpla” con todos los requerimientos recogidos del sistema.

Esta estrategia se asemeja mucho a la prototipación de algunos procesos de desarrollo, pero

difiere en que cada producto es parte del sistema final, y no un prototipo desechable. Aún 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 “volátil”, ya

que si no se cumple algún requerimiento en particular, el cliente puede solicitar un cambio en el

desarrollo realizado convirtiéndose en un tiempo “perdido”. Este tiempo “perdido”, como suelen

llamarlo algunos, no lo es tal, pues es la parte que nos ayuda tener más claro los requerimientos

reales y no los que nosotros creemos que el cliente quiere.

Las ventajas prácticas de que UP sea iterativo son:

Mitigación de riesgos altos de manera temprana (técnicos, funcionales, de usabilidad, etc)


24

Progreso visible desde las primeras fases

Retroalimentación, adaptación y compromiso por parte de los usuarios

Gestión de la complejidad a procesos largos de análisis

Reutilización de conocimientos aprendidos en iteraciones previas

LA RETROALIMENTACIÓN Y LA ADAPTACIÓN: FILOSOFÍAS DE UP

Dentro del desarrollo de Software hay siempre una “aprensión”: 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, llevándose consigo un montón de dudas que hacen que el

análisis y diseño 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 situación muchos comienzan a realizar

documentos de análisis o de diseño que deben ser “firmados” por el cliente, respaldando sus

errores, generando un nivel de frustración al cliente obligándolo a conformarse con el sistema

final entregado.

Esta problemática es abordada por el UP, ya que compromete la participación del cliente final en

el proceso de desarrollo desde el principio del proyecto, para realizar la retroalimentación. Con

esta relación 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 iteración, el cliente por su parte entenderá su

preocupación y podrá clarificar si esta especulación está correctamente abordada o realmente fue

un invento de los analistas. Esta retroalimentación 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.

Más adelante veremos que esta problemática se resuelve en parte utilizando UML como lenguaje

común.

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 DESCRIPCIÓN DE LOS ELEMENTOS MÁS

IMPORTANTES Y DA UNA PERSPECTIVA DEL SISTEMA COMPLETO.

La arquitectura sirve para:


25

Comprender el sistema

Organizar el desarrollo en mini-sistemas

Fomentar la reutilización

Flexibilizar la evolución del sistema

Esta distinción nos hace nacer otras dudas: ¿cómo se hace una arquitectura sólida? Durante las primeras iteraciones del UP se define esta arquitectura. Esta arquitectura se arma con todas las vistas del sistema, a través de metamodelos y con una comprensión “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 través 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

más al alcance del usuario, ya que requeriremos una alta retroalimentación 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 cuáles son las

fases que lo definen y comencemos a adentrarnos en el detalle de esas fases, indicando cuáles son

los modelos utilizados en el análisis y diseño orientado al objeto.

Veamos el ciclo de desarrollo desde un punto de vista “macro” para luego comenzar a desarrollar

cada etapa:

...

Inicio Elaboración Construcción Transición

Ciclo de Desarrollo

Fase Iteración

ILUSTRACIÓN 5. FASES DEL PROCESO UNIFICADO DE DESARROLLO

Como vemos en el diagrama, una fase puede estar constituida por una o más iteraciones, y el ciclo

de desarrollo completo se compone de 4 fases:


26

1. Fase de Inicio (“Inception”): Tiene por objetivo tener una visión aproximada del sistema, realizar el análisis del negocio, definir el alcance del sistema y realizar estimaciones imprecisas que serán refinadas en las siguientes fases.

2. Fase de Elaboración (“Elaboration”): Tiene por objetivo definir una visión refinada del problema, implementar iterativamente el núcleo central de la arquitectura, resolver los riesgos altos, identificar más requisitos y alcances del sistema y realizar estimaciones más realistas.

3. Fase de Construcción (“Construction”): Tiene por objetivo implementar en forma iterativa el resto de los requerimientos de menor riesgo y elementos más sencillos, además de preparar el despliegue del sistema en la siguiente fase.

4. Fase de Transición (“Transition”): Tiene por objetivo realizar las pruebas del tipo “beta” y además 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 diseña o en qué parte se programa, por el contrario, existe en cada iteración un número de

disciplinas con las cuales se “cruzan” estas fases y que si incluyen metodologías de análisis, diseño,

construcción y calidad. Estas disciplinas son:

a) Modelado del Negocio

b) Requisitos

c) Diseño

d) Implementación

e) Prueba

f) Despliegue

g) Gestión de Configuraciones y Cambios

h) Gestión 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:


27

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 iteración en cuestión. En particular, nosotros nos centraremos en las 3 primeras disciplinas, ya que son parte del Análisis y Diseño OO. El resto de las disciplinas son parte del proyecto en otras áreas del mismo.

OTROS CONCEPTOS ORIENTADOS A LA PLANIFICACIÓN

Para terminar la visión general del UP, debemos tener en cuenta que existen algunos conceptos

que van orientados a la planificación, más que al diseño, pero que son importantes clarificar desde

un punto de vista del proyecto de software.

Estos conceptos, se definen a continuación:

Proyecto es el conjunto de definiciones y la planificación necesaria para resolver una

problemática puntual.

Hito es un punto de terminación de una iteración o etapa del proyecto en donde es

necesaria tomar alguna decisión o evaluación importante.

Producto o Entregable es el resultado físico de una iteración en donde es entregado y

validado tanto los requisitos, como el diseño o la implementación del sistema.

Versión es un subconjunto estable y ejecutable del producto final.

Incremento es la diferencia (delta) entre las versiones de dos iteraciones seguidas.

Versión Final se define cuando el sistema se lanza para su puesta en producción y es el

último hito del proyecto.

ILUSTRACIÓN 6. CARGA DE TRABAJO POR DISCIPLINA EN EL PROCESO UNIFICADO DE DESARROLLO


28

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 métodos de Booch y OMT (citados anteriomente). Luego de eso, se

consolidó con la incorporación 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 Y

DOCUMENTAR LOS ARTEFACTOS DE LOS SISTEMAS SOFTWARE, ASÍ

COMO PARA EL MODELADO DEL NEGOCIO Y OTROS SISTEMAS NO

SOFTWARE.

Esta definición formal, entregada por el Object Management Group (OMG), quien adoptó a UML

como lenguaje estándar en 1997, define claramente qué es y para qué sirve. Es así como vemos

claros indicios de algo que ya habíamos visto:

“UML es un lenguaje”, compuesto por una sintaxis, pero solo comprende de la notación o

nomenclatura y no se hace cargo del proceso de desarrollo (para eso está el Proceso

Unificado que veremos más adelante).

“UML sirve para especificar, visualizar, construir y documentar” nuestros sistemas a través

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 también es factible

modelar procesos y el mismo negocio a través de los metamodelos que propone la

metodología de desarrollo.

Como se puede ver, UML no es solo notación aislada, sino que también tiene un potencial

mayúsculo cuando hablamos de acompañar al proceso de desarrollo de software. Sin embargo, las

disciplinas de análisis y diseño que nos interesa estudiar no están dadas por “un manual de UML”,

sino que, a través del uso de este lenguaje, podremos plasmar en documentos o diagramas los

modelos que sean necesarios de realizar.

A continuación, 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 través de dos elementos importantes: una Notación y un Metamodelo. Diremos

entonces que:


29

LA NOTACIÓN ES LA SINTAXIS DEL LENGUAJE DE MODELADO.

Para esta definición tenemos un mundo completo de preguntas. ¿Cuál sintaxis? ¿En qué lenguaje?

¿Qué quiere decir? En realidad la respuesta es más fácil de lo que parece, ya que la notación, tal

cual como versa su significado textual, es un conjunto de elementos utilizados en los artefactos.

UN ARTEFACTO ES UN ELEMENTO DEFINIDO A TRAVÉS DE LA NOTACIÓN

DEL LENGUAJE Y QUE MUESTRA UN PUNTO DE VISTA DE LO QUE SE

REQUIERE MODELAR.

De esta manera, los artefactos utilizan la notación de manera de poder dar una visión del

problema en cuestión. Así, podemos definir diferentes artefactos dependiendo también del punto

de vista que se desea plantear.

Existen 2 tipos de artefactos:

Diagramas: Son aquellos artefactos que utilizan una notación principalmente gráfica o

visualmente esquemática.

Documentos: Son aquellos artefactos que describen a través 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 información 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 más adecuado. En cambio si es orientado al

programador, puede serlo un lenguaje estructurado o incluso un pseudocódigo.

Ahora, si seguimos con definiciones, decimos que:

EL METAMODELO ES UN CONJUNTO DE ARTEFACTOS AGRUPADOS PARA UN

OBJETIVO ESPECÍFICO.

Según lo que aquí estamos planteando, entonces, para un metamodelo, requeriremos utilizar la

notación (UML) necesaria que se ajuste al objetivo planteado a través 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 notación en cada modelo que debe ser utilizada.

VISIÓN GENERAL DE LOS METAMODELOS UML APLICADOS AL A/DOO

Según lo expresado en la parte anterior, y llevándolos al ámbito del A/DOO, los metamodelos nos

ayudan a graficar, con un notación conocida (UML), nuestros modelos de análisis y propuestas de

diseño (de software) para un problema particular que queremos resolver.


30

Ahora bien, si esto lo “cruzamos” con la metodología 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 más

modelos. Es así como se plantea una visión de los modelos en UML de la siguiente forma:

ILUSTRACIÓN 7. METAMODELOS APLICADOS A LA METODOLOGÍA

Como se puede observar, no es fácil separar el modelado del negocio del análisis de

requerimientos, ya que con ambos podemos completar toda la información necesaria para realizar

un diseño de software. Además, al no ser un proceso lineal, es probable que dentro del tiempo del

análisis que se utiliza, el modelado del negocio pueda realizarse en forma “paralela”.

Veamos ahora qué son cada uno de los metamodelos planteados en esta gráfica y cuáles son sus

objetivos.

MODELO DE DOMINIO

Este primer modelo lo podemos definir de la siguiente forma:

ES UNA REPRESENTACIÓN VISUAL (DIAGRAMA) DE LAS CLASES

CONCEPTUALES U OBJETOS DEL MUNDO REAL EN UN DOMINIO DE

INTERÉS.


31

La idea central de estos modelos es representar las clases conceptuales y no los componentes de

software, utilizando un lenguaje más cercano al negocio o dominio en el cual está inmersa la

solución en vez de centrarse en explicar desde el punto de vista tecnológico el problema (para eso

está el Modelo de Diseño).

DIAGRAMAS DE CLASES CONCEPTUALES

La notación que utilizan es muy similar a la que se usan en los Diagramas de Clase del modelo de

diseño, sin embargo a diferencia de estos diagramas, la representación de las clases tiene más que

ver con conceptos que con el modelamiento de objetos a través de clases de software.

Es información relevante para el modelo de dominio todo lo que tiene que ver con los casos de

uso (Especificación 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 información modelada en este diagrama es

de gran utilidad para incorporar información para los Contratos de las Operaciones, Glosario y

para el Modelo de Diseño.

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 especificación del UML define un diagrama de

actividad como: “… una variación de una máquina estados, lo cual los estados representan el

rendimiento de las acciones o subactividades y las transiciones se provocan por la realización de

las acciones o subactividades.”

El propósito 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 más básico aún y que es el término Caso de

Uso:

ES UNA COLECCIÓN DE ESCENARIOS RELACIONADOS, QUE DESCRIBE

A LOS ACTORES Y LA INTERACCIÓN QUE ELLOS REALIZAN CON EL

SISTEMA PARA CONSEGUIR Y SATISFACER UN OBJETIVO ESPECÍFICO.

Este concepto es el centro del modelo, ya que intenta explicar que, en otras palabras, un caso de

uso no es más 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.

Después de esta definición, podemos decir que en realidad el modelo de casos de uso no es más

que un grupo de modelos que definen tanto las funcionalidades del sistema como de los detalles

útiles para el diseño de software.


32

Para entender mejor, expliquemos en forma separada los diferentes diagramas y artefactos que

son parte importante de este modelo.

ESPECIFICACIÓN DE CASOS DE USO

Una de las actividades principales que se deben realizar en la disciplina de análisis de requisitos es

especificar el detalle de los requerimientos funcionales en casos de uso. De esta forma, este

artefacto es la documentación detallada de dichos requerimientos, a través de una estructura

completa que incluye objetivos de los actores, escenarios de éxito, escenarios alternativos,

variantes tecnológicas, restricciones, etc.

Este artefacto básicamente es un documento y no es una gráfica, como pasa con los diagramas,

sino que más bien es un detalle (escrito en español) con cierta estructura fija que UML define.

La fuente de información necesaria para la especificación 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 gráficos utilizados en el proceso de desarrollo es el diagrama de

casos de uso. Este artefacto tiene por objetivo el de organizar, en forma visual, cuáles son los

casos de uso del sistema, su contexto, los límites y la relación que tienen con respecto a los

actores del mismo.

La notación que utilizan los diagramas de casos de uso por lo general es muy simple, con tipos de

relaciones básicas y sin un detalle que muestre implementación (como corresponde). Además, es

importante recordar que la parte importante de los casos de uso es su especificación y no el de

llenarse de diagramas que muestren su contexto.

GLOSARIO

Es un documento que pone en común toda la terminología y su utilización dentro del dominio de

análisis. Su propósito es poder comprender mejor el negocio en el cual se va a diseñar el sistema

para que todos los actores involucrados mantengan un nivel de entendimiento similar.

MODELO DE ANÁLISIS

El modelo de análisis 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 TRAVÉS

DE LOS ESCENARIOS PRESENTADOS EN EL MODELO DE CASOS DE

USO Y EN FUNCIÓN DE LAS CLASES CONCEPTUALES.

Es claro identificar que este modelo es el que da pie a identificar los primeros elementos de diseño

del sistema. Sin embargo, la mayoría de los análisis se hacen a través del concepto de “caja negra”

que nos permite abstraernos de la implementación.


33

Los artefactos asociados a este modelo son:

DIAGRAMAS DE SECUENCIA

Es un artefacto creado de manera rápida y fácil, 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 lógica

implementada dentro, sino que desde el punto de vista externo.

Desde el punto de vista del análisis, los actores que se relacionan con el sistema generan

diferentes eventos. Estos eventos, organizados como parte de un escenario específico de uso, son

los llamados diagramas de secuencia del sistema, y nos ilustran esta interacción tanto con los

actores (tal como dijimos anteriormente) como con otros sistemas externos.

La visión que se utiliza en estos diagramas debe ser para entender el comportamiento del sistema,

y no de definir su implementación, es por eso que la abstracción nos ayuda a elaborar mejor estos

diagramas. La información necesaria para estos diagramas se obtiene de los casos de uso

(especificación).

CONTRATOS DE LAS OPERACIONES

Los contratos de las operaciones del sistema describen el resultado de la ejecución de las

operaciones en función de los cambios de estado de los objetos del dominio. Cada una de las

operaciones es vista como una “caja negra” que recibe cierta información de entrada y que

produce cierta información de salida, sin la necesidad de saber cómo 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 información adicional para el

análisis desde el punto de vista funcional.

La información 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 (especificación

de casos de uso).

DIAGRAMA DE ESTADOS

Este diagrama nos muestra el comportamiento de objetos, clases, procesos y casos de uso a través

de sus cambios de estados. Es utilizado para describir el comportamiento a diferentes niveles de

detalle, dependiendo de lo que se quiere entender.

La aplicación de este artefacto será para describir dinámicamente el comportamiento del sistema

o partes de él a través de los casos de uso o elementos conceptuales del sistema, es por eso que

es muy relevante en este modelo.

MODELO ARQUITECTÓNICO

Este modelo podemos definirlo de la siguiente manera:


34

EL MODELO ARQUITECTÓNICO DEFINE LA ORGANIZACIÓN Y LAS

INTERFACES QUE DEBE TENER EL SISTEMA PARA HACERLO

REUTILIZABLE Y MODULAR.

Es fácil ver que en este modelo, también conocido como Arquitectura de Software, se definirá la

modularidad de nuestro sistema. A pesar de que en el proceso estricto, la arquitectura tiene más

información que los módulos del sistema, para efectos académicos solo veremos esa dimensión

del modelo2.

DIAGRAMA DE COMPONENTES

Un diagrama de componentes representa cómo un sistema de software es dividido en

componentes y muestra las dependencias entre estos componentes. Los componentes físicos

incluyen archivos, cabeceras, librerías compartidas, módulos, 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 más parecidos a los diagramas de casos de usos estos son utilizados para

modelar la vista estática de un sistema. Muestra la organización 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 DISEÑO

El modelo de diseño lo podemos definir como:

EL PROCESO A TRAVÉS DEL CUAL SE DEFINEN LAS CLASES DE

SOFTWARE, SE LES AÑADEN ATRIBUTOS, OPERACIONES Y EL PASO DE

MENSAJES PARA SATISFACER LOS REQUISITOS DEL PROBLEMA.

Con esta definición, podemos decir que el modelo de diseño define cómo lograr el objetivo del

sistema, incorporando las clases de diseño que se deben implementar y por supuesto entregando

detalles que van a apoyar el proceso de implementación.

REALIZACIÓN DE CASOS DE USO Y DIAGRAMAS DE COLABORACIÓN

Una definición formal de lo que es una realización dice que la realización describe el cómo se

realiza un caso de uso particular en el modelo de diseño, en función de los objetos que colaboran.

De esta forma, en el diseño, el concepto de realización de caso de uso en realidad no es más que

una forma de relacionar los casos de uso analizados con el diseño de objetos que satisface los

requisitos.

2 La definición formal de la arquitectura es un conjunto de decisiones significativas sobre la organización del

sistema, la selección de elementos estructurales y sus interfaces, el comportamiento dado por la

colaboración de sus elementos y las motivaciones o fundamentos sobre el diseño del mismo.


35

Por otro lado, la forma de realizar los casos de uso es utilizando diagramas de colaboración los

cuales grafican en forma visual cuáles son las operaciones e interacciones entre los diferentes

objetos del dominio.

La información 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 información también para la realización.

DIAGRAMA DE CLASES DE DISEÑO

Es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases,

atributos y las relaciones entre ellos.

A pesar que la notación es similar al usado en el modelo de dominio, el diagrama de clases de

diseño incorpora notación adicional y por supuesto un detalle mayor desde el punto de vista de la

implementación, ya que el objetivo es especificar con el máximo de detalle posible la estructura,

su composición y la relación de los objetos que componen el sistema.

La información usada en el DCD para la definición de las clases y sus operaciones sale en su

mayoría como parte de las realizaciones de casos de uso. En efecto, de los diagramas de

interacción, podemos obtener de manera sencilla las operaciones de cada clase, ya que es fácil

encontrarlas como interacciones entre sus instancias de objetos.

MODELO DE IMPLEMENTACIÓN

Este modelo se define como:

UN CONJUNTO DE ARTEFACTOS DE IMPLEMENTACIÓN COMO EL

CÓDIGO FUENTE, DEFINICIONES DE BASES DE DATOS, PÁGINAS,

PROGRAMAS, ETC.

Tal como queda definido, el modelo de implementación se preocupa de contener el código a

través de diferentes estrategias. Por ejemplo, una técnica es la transformación de diseños en

códigos desde las definiciones de las clases e interfaces y la definición de los métodos desde el

DCD.

Es claro ver que el principal alimentador de este modelo es el modelo de diseño, quien ha llevado

el detalle de cómo es el software hasta detallar las operaciones.

Una guía rápida de este modelo es la siguiente:

Crear definiciones de las clases a partir de los DCD’s. Con esto podemos definir

rápidamente la estructura de nuestras clases físicas o programas, sin lograr detallar el

funcionamiento del sistema todavía.

Crear los métodos a partir de los diagramas de interacción. Con esto podemos entender el

funcionamiento de cada una de las operaciones en su mecánica interna, lo que nos


36

permite encontrar fácilmente la secuencia lógica de las instrucciones dentro de los

métodos de los objetos.

Ordenar la implementación. Con esto es importante que tengamos un orden de

implementación definido desde la menos a la más 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 código

completo. De esta manera la mayor cantidad de errores típicos es resuelto en la

codificación.


37

UNIDAD II. EL ANÁLISIS ORIENTADO AL

OBJETO

Durante este capítulo veremos cómo recolectar los requerimientos y cómo ellos

van agregando información, a través de modelos desarrollados en UML, para

recabar y recolectar el máximo detalle necesario para construir nuestros diseños

de software.


38

FUNDAMENTOS DEL ANÁLISIS DE SOFTWARE

Según la definición de Wikipedia “… se entiende por necesidad una carencia o la exigencia de un

objeto…”. Si esto lo llevamos al plano informático, 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 diseñar. Definamos entonces el

concepto de Requerimiento o Requisito:

UN REQUERIMIENTO O 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.

CARACTERÍSTICAS DE LOS REQUERIMIENTOS

Los requerimientos poseen algunas características 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 ambigüedad: El texto debe ser claro, preciso y tener una única interpretación posible.

Conciso: Debe redactarse en un lenguaje comprensible para los usuarios en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes.

Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos también debe ser consistente.

Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más 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 verificación puede lograrse mediante inspección, análisis, demostración o testeo.

CLASIFICACIÓN DE LOS REQUERIMIENTOS

Existen 2 grandes grupos de requerimientos:


39

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 además pueden ser clasificados a través de un modelo denominado

FURPS+, el cual es un acrónimo de las categorías escritas en inglés, las que logran realizar una

clasificación de una manera amplia. Esta es la clasificación:

Funcional (Functional): relacionados con características, capacidades y seguridad del sistema.

Usabilidad (Usability): relacionado con factores humanos, ayuda y documentación.

Fiabilidad (Reliability): relacionado con la frecuencia de caídas, capacidad de recuperación y previsión de ellas.

Rendimiento (Performance): relacionado con los tiempos de respuesta, productividad, precisión, 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:

Implementación: relacionado con la limitación de los recursos, lenguajes, herramientas, hardware, etc.

Interoperabilidad: relacionado con las restricciones impuestas para la interacción con sistemas externos.

Operación: relacionado con la gestión del sistema en su puesta en marcha.

Empaquetamiento: relacionado con la capacidad de empaquetar el sistema.

Legales: relacionado con las licencias de uso, instalación de componentes, etc.

Es bastante útil trabajar con una categorización de los requerimientos. Esta es una base con la cual se puede comenzar, sin embargo, existen otras clasificaciones muchas veces más simples, pero que dejan fuera una buena distinción. Dependiendo del estilo de análisis que se utiliza, realizar una u otras es bastante indiferente, porque la real “distinción” que uno debe tener es de los requerimientos funcionales (características y comportamiento del sistema) con los requerimientos no funcionales (usabilidad, fiabilidad, rendimiento, soporte, etc).

¿Por qué está última distinción? Los requerimientos funcionales son los prácticamente definen las funciones del sistema.

ESPECIFICACIÓN DE REQUISITOS


40

A pesar de que no es parte del UML, la formalización 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 análisis3.

TÉCNICA DE ESPECIFICACIÓN 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 sería algo como: “D&S, distribuidor de alimentos a través de

distintos formatos y que agrupa los supermercados Express de Líder, Hiper Líder 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 información

(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 implementación.

Por ejemplo, “… la meta es una mayor automatización del pago en las cajas registradoras, dar

soporte a los servicios más rápido, más baratos y mejores y a los procesos de negocio a través 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 definición, ya que debe contener “lo que debe hacer” el Sistema

en análisis. Es importante no solo identificarlas, sino que también listarlas en grupos cohesivos y

lógicos. De esta forma, se propone ingresar las funciones del sistema en una tabla con el siguiente

formato:

# Ref:

Función:

Descripción:

Categoría:

ILUSTRACIÓN 8. PLANTILLA DE ESPECIFICACIÓN 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 número indica el

grupo y el segundo es un correlativo dentro de ese grupo.

3 Existen otros artefactos que pueden detallar estos requerimientos, pero no serán abordados en el curso


41

Función: Se debe dar un nombre autoexplicativo que haga referencia a lo que ésta realiza.

Descripción: Se debe describir en forma sintética y exacta la función que debe realizar el

sistema frente a las necesidades del usuario final.

Categoría: Es necesario indicar un cierto nivel de prioridad clasificada por su significado y

que pueden consumir tiempo cuando no son formalizadas. Estas categorías son:

o Evidente: Debe realizarse y el usuario debería 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 inclusión 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 Categoría

ILUSTRACIÓN 9. CONTINUACIÓN DE LA PLANTILLA DE ESPECIFICACIÓN DE FUNCIONES

Cada uno de los atributos tiende a tener un detalle que contiene valores discretos, confusos o

simbólicos. Además, podría 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

categoría 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, también conocido como “Punto

de Venta” (PDV). En una primera reunión se recogen algunos requerimientos:

La caja debe permitir el ingreso del código de los productos en forma manual o a través de

una pistola lectora de códigos de barra.

Si la caja se cae por algún motivo (pérdida de conectividad con el servidor, corte de

energía, error en el procesamiento del medio de pago o producto defectuoso, etc), el

sistema debe retomar el proceso inmediatamente después 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ó.

4 Se estila que la tabla de funciones y de atributos se unan en una sola.


42

De esta manera, se puede definir un documento con la información de especificación general del

sistema y sus funciones de la siguiente forma:

Nombre del Sistema: Sistema Punto de Venta (SPDV)

Panorama: D&S a través de distintos formatos y que agrupa supermercados como Express de

Líder, Hiper Líder y Ekono.

Clientes: Los cajeros, área de finanzas, sistema de inventario y SecurePay

Metas: Crear un sistema de terminal para el punto de venta que se utilizará en las ventas

del supermercado de manera de:

Entregar mayor automatización del pago en las cajas registradoras

Dar soporte a los servicios más rápido, más baratos y mejores y a los

procesos de negocio

# Ref: R1.1

Función: Identificación del Cajero

Descripción: El cajero debe identificarse siempre al principio de su jornada, de modo que

podamos llevar control de las ventas que realizó.

Categoría: Evidente


# Ref: R2.1

Función: Registrar los Productos de la Venta

Descripción: 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.



Ingreso de Códigos Debe ser manual o por pistola lectora de códigos de

barras.

Usabilidad

Implementación

Recuperación de la Venta Debe permitir recuperar una venta desde el punto

anterior a la caída.

Fiabilidad

# Ref: R2.2

Función: Registrar el Pago de la Venta

Descripción: La caja debe permitir que el cajero ingrese el pago de la venta con cualquier

medio de pago habilitado.



Medios de Pago Habilitados Solo se aceptan pagos con efectivo, cheque y tarjetas

bancarias.

Implementación

ILUSTRACIÓN 10. PLANTILLA DE ESPECIFICACIÓN DE FUNCIONES PARA EL SPDV


Para diferenciar y entregar más elementos que nos hagan entender el modelo de casos de uso,

veamos la definición que ya planteamos en la unidad de conceptos y metodologías vista

anteriormente:


43

EL MODELO DE CASOS DE USO ES, BÁSICAMENTE, 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 cómo 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 visión externa, es decir la del

usuario que utiliza el sistema (usuario final).

CONCEPTOS BÁSICOS

Pero para entender cómo 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

ORGANIZACIÓN QUE INTERACTÚA 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 cómo los representamos en UML, por ahora nos

quedamos solo con la definición.

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 “ejecución” de nuestra aplicación que estamos diseñando. A

esto también se le conoce como Instancia de Caso de Uso.

CASO DE USO

Finalmente, y al parecer el concepto más esperado, con el que decimos que:


44

UN CASO DE USO ES UNA COLECCIÓN DE ESCENARIOS

RELACIONADOS, QUE DESCRIBE A LOS ACTORES UTILIZANDO EL

SISTEMA PARA UN OBJETIVO ESPECÍFICO.

Al ver esta definición podemos decir que el Caso de Uso define las relaciones y acciones de los

actores hacia el sistema, bajo el prisma de un objetivo específico. 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 también, pero ya es poco común. Lo general es que

sean funcionales.

RESPONSABILIDAD

Lo primero es saber qué es una responsabilidad:

RESPONSABILIDAD ES UNA METÁFORA CON LA CUAL SE ESPECIFICA

LOS REQUISITOS FUNCIONALES.

Estas metáforas se refieren a indicar el “qué” debe hacer el sistema (análisis) y no el “cómo” lo

debe hacer (diseño). A veces ocurre que los analistas tratan de especificar los pasos a seguir en el

caso de uso como si fuese un pseudocódigo o programa, pero eso se debe dejar al diseño.

FORMALIDAD

Los casos de uso definen sus responsabilidades con distintos tipos de formalidad. Estos tipos son:

Breve: Es un resumen conciso de un solo párrafo, normalmente indicando cuál es el escenario principal con éxito.

Informal: Es un formato de múltiples párrafos 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 garantías de éxito de los escenarios presentados.

Aquí podemos ver que las formas de especificar los casos de uso generalmente varían, y también dependen de la situación 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 través de

2 artefactos del lenguaje:

Especificación de Casos de Uso: Documento que permite describir en detalle y lenguaje

natural las particularidades de cada caso de uso identificado.


45

Diagramas de Casos de Uso: Diagrama que muestra el contexto de todos los casos de uso

del sistema en relación 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

través del uso de técnicas o recetas. Veamos la técnica de identificación y especificación de los

casos de uso:

IDENTIFICACIÓN DE CASOS DE USO

Además de saber cómo se identifican los casos de uso, es importante entender que debemos

mirar el entorno para ver la relación 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

definición de los casos de uso:

PASO 1: ELEGIR EL LÍMITE DEL SISTEMA

Al comenzar a definir los casos de uso, es importante saber hasta dónde llega el sistema, cuál es el

alcance de éste. El problema es que no siempre es fácil determinar el límite, porque se confunden

responsabilidades del sistema con las funcionalidades desde el punto de vista del usuario.

Es por eso que siempre es más fácil determinar primero lo que está fuera (actores externos y de

apoyo). Una vez que estos agentes externos al sistema están claramente identificados, descubrir

los límites de éste se torna un poco más sencillo.

Por ejemplo, ¿existe alguna responsabilidad del sistema de caja de supermercado de autorizar y

gestionar los pagos con tarjetas de crédito?, la respuesta es no, porque ese servicio lo da

Transbank, lo que dejaría tanto ese objetivo como el actor fuera de nuestro sistema en análisis.

PASO 2: IDENTIFICAR LOS ACTORES PRINCIPALES Y DE APOYO

Luego de tener claro el límite 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 específicos. Por ejemplo: El Cajero es un actor que desea procesar una venta.

Actores de Apoyo: Son actores de “segunda categoría” 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 están interesados en el comportamiento del caso de uso, pero que no interactúa con él. Por ejemplo: SII es un actor pasivo.

En la mayoría de los casos, los actores principales son los que nos importarían, ya que ellos

interactúan con el sistema a través de los casos de uso para satisfacer sus objetivos.

PASO 3: IDENTIFICAR LOS OBJETIVOS DE LOS ACTORES


46

Con los actores, es fácil saber cuál es su objetivo para utilizar el sistema, ya que ellos se

desprenden de la formalización 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

... ...

ILUSTRACIÓN 11. TABLA DE IDENTIFICACIÓN DE ACTORES Y OBJETIVOS

Los objetivos pueden ser más de uno, ya que los actores tienen más de una esperanza del sistema.

De esta forma iremos desarrollando el modelo.

Otra forma de encontrar los objetivos es a través 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

Después de este proceso, lo que se requiere es identificar cuáles son los casos de uso del

problema. Este paso puede durar desde minutos (solo descubrir cuáles son) hasta días (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. Fíjate

que el nombre comienza por un verbo en infinitivo, lo que indica que es una acción 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 serán 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

información 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 notación propuesta para este tipo de especificación es:

Caso de Uso: <Nombre de Caso de Uso>

Actores: <Lista de agentes externos indicando quién inicia el CU>

Tipo: <Primario, Secundario u Opcional>

Descripción: <Descripción general del proceso que está resolviendo el CU>

ILUSTRACIÓN 12. DOCUMENTO DE ESPECIFICACIÓN DE CASO DE USO DE ALTO NIVEL

En el caso de los tipos de CU, estos son:


47

Primario: Representan los procesos comunes más 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, cómo 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 notación propuesta para este tipo de especificación es:

Caso de Uso: <Nombre del Caso de Uso>

Actores: <Lista de agentes externos indicando quién inicia el CU>

Propósito: <Intención del CU>

Resumen: <Descripción general del CU, que es la misma que se usa en Alto Nivel>

Tipo: <Primario, Secundario u Opcional> y <Esencial o Real>

Ref. Cruzadas: <CU y funciones relacionadas>

Curso Normal

<Detalle de la conversación interactiva entre los actores y el sistema>

Cursos Alternos

<Detalle de la conversación interactiva entre los actores y el sistema>

ILUSTRACIÓN 13. DOCUMENTO DE ESPECIFICACIÓN DE CASO DE USO EXPANDIDA

En el caso de los tipos de CU, además de los ya vistos en el CU de Alto Nivel, son:

Real: Concretos y que utilizan la tecnología real con la cual se desarrolla el CU.

Esencial: Teóricos y que no poseen detalles de la tecnología e implementación.

Además, la forma de describir los cursos, tanto normal como alternos, debe realizarse en un

formato específico de modo de que se explique cómo 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:

Acción del Actor Respuesta del Sistema

1. Acción del actor

2. Acción del actor 3. Respuesta del Sistema

4. Acción del actor

… …

Por otro lado, los cursos alternos deben hacer referencia al paso del curso normal de eventos en

donde ocurre el evento y la descripción de éste.

Paso 3.

1. Acción alterna 2. Acción alterna 3. …


48


Para complementar el modelo se utiliza una sola la visión general del sistema, actores y la relación

o interacción 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 visión general de las especificaciones, quedan en

una sola mirada para el lector.

La notación del diagrama es la siguiente:

ILUSTRACIÓN 14. NOTACIÓN DE LOS DIAGRAMAS DE CASOS DE USO

Algunas consideraciones respecto a la notación:

La Asociación puede utilizar multiplicidad en su definición (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 específicas entre CU, podemos encontrar las siguientes (segunda

columna):

o Inclusión: Define un subcaso, es decir, cuando el CU referenciado está “dentro” de

el caso general.

o Extensión: Define un caso que, además de realizar todas las especificaciones del

caso original, define algunos pasos adicionales. Es equivalente a utilizar

especialización.


49

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

continúe 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 diseñar y definir

un modelo de casos de uso claro con los artefactos mencionados. Vamos paso a paso tal como nos

enseña esta clase:

Nombre del Sistema: Sistema Punto de Venta (SPDV)

Límites: Estados financieros de las ventas.

Administración de recursos humanos.

Devoluciones y cambios de productos.

Administración de los medios de pago.

Administración de inventario.

Actores y Objetivos

Actor Objetivo

Cliente Realizar una compra de los productos seleccionados. Pagar el monto de la compra.

Cajero 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.

SecurePay Recibir solicitudes de validación de cheques. Recibir transacciones con tarjetas de crédito y débito.

Sistema de Inventario Recibir notificaciones de los productos egresados de la tienda.

Sistema de Finanzas Recibir la información de cada venta realizada en un terminal de la tienda.

Especificación de Casos de Uso

Caso de Uso: CU1: Autenticar en el Sistema

Actores: Cajero (I), Cliente

Tipo: Primario

Descripción: Le permite al cajero ingresar su identificación (usuario y contraseña) de manera de tener control de quién está realizando una venta.

Caso de Uso: CU2: Registrar Productos de una Venta

Actores: Cajero (I), Cliente, Sistema de Inventario

Tipo: Primario

Descripción: Le permite al cajero ingresar cada producto a través de los códigos de barra a la venta actual.

Caso de Uso: CU3: Validar Medio de Pago

Actores: Cajero (I), Cliente, SecurePay

Tipo: Primario

Descripción: Le permte al cajero validar en línea aquellos medios de pago válidos (cheque, tarjeta de crédito y débito).

ILUSTRACIÓN 15. PLANTILLA DE ESPECIFICACIÓN DE CASOS DE USO Y GLOSARIO


50

En esta plantilla está el problema del SPDV parcialmente especificado (falta trabajo). De todas

maneras da una idea de cómo se vería la especificación del problema después del proceso de

análisis.

Ahora bien, revisemos cómo se vería esto en un Diagrama de Casos de Uso:

System

CU1: Autenticar en el Sistema

CU2: Registrar Productos de una Venta

CU3: Validar Medio de Pago

Cajero

Sistema de Inventario

SecurePay

ILUSTRACIÓN 16. DIAGRAMA DE CASOS DE USO DEL SPDV

GLOSARIO

El glosario tiene por objetivo poner en común entre los diferentes lectores del A/DOO la

terminología a utilizar, tanto del negocio como de la parte técnica. Este artefacto tiene la

importancia que, gracias a su información, podemos comenzar a definir un diccionario de datos

antes de diseñar componentes.

No existe una técnica para encontrar el glosario, pero es recomendable de comenzar a

especificarlo después de descritas las funciones del sistema o incluso cuando se estén

especificando los casos de uso, ya que van a ir saliendo en forma natural los términos no

reconocidos por el equipo.

Una estructura básica (plantilla) se sugiere a continuación para el glosario:

Término Definición

… …

… …

… …

… …

… …

ILUSTRACIÓN 17. DOCUMENTO DEL GLOSARIO


51

Por ejemplo, aquí está parte del glosario al problema que hemos visto durante las secciones

anteriores.

Glosario


Punto de Venta Lugar del supermercado donde se deben registrar las ventas del local.

Caja Dispositivo físico que le permite al cajero ingresar datos de la venta.

Medio de Pago Forma equivalente a dinero que sirve para realizar pagos sin tener efectivo.

... ...

ILUSTRACIÓN 18. GLOSARIO PARA EL PROBLEMA DEL SPDV

MODELO DE DOMINIO

Un paso importante en el análisis y diseño OO es el modelo de dominio, el cual se utiliza como

inspiración para el diseño 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 ANÁLISIS A TRAVÉS DEL PROCEO Y DE LAS CLASES

CONCEPTUALES, DESCRIBIENDO SUS ASOCIACIONES Y ATRIBUTOS.

Aún cuando los modelos de dominio son propios de la disciplina de modelado del negocio y no del

análisis como tal, son requisito del diseño y de otros artefactos del mismo análisis, es por esa

razón que es importante estudiarlos. Además, salta a la vista que las disciplinas de UP se van

entrelazando entre sí dependiendo de lo que se va haciendo en el análisis y diseño, 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 BÁSICOS

A continuación 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 definición 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 más ni menos, de manera de que todo lo que definamos tendrá que ver con

ese contexto.


52

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 ANÁLISIS Y QUE DEFINEN PARTE DE ÉL A TRAVÉS DE SU

SÍMBOLO, INTENSIÓN Y EXTENSIÓN.

Como podemos ver, en esta definición estamos definiendo parte de la notación UML de las clases

conceptuales a través de los elementos que la componen. Estos elementos son:

Símbolo: palabras o imágenes que representan una clase conceptual.

Intensión: la definición de la clase conceptual.

Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual.

Por ejemplo, si consideramos el evento de transacción de compra de producto como una clase

conceptual, desde el punto de vista del sistema podríamos bautizarlo como Venta. Desde el punto

de vista práctico en la construcción del modelo del dominio, solo el símbolo y la intensión 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 diseño, ya que pueden confundirnos, además de que los modelos de

dominio no sirven en la implementación.

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

estén modelando componentes de software.

Responsabilidades o métodos de las clases conceptuales, ya que no deben representar las

“funcionalidades” que tienen.

Una diferencia importante cuando realizamos el análisis 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 análisis del dominio a través 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.


53

A pesar de que esta definición es más específica 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 dinámica del dominio que estamos analizando, y que

será necesario modelar, de manera de tener la visión 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 cómo es el proceso de negocio que se

está interviniendo con el sistema que está en análisis.

Diagrama de Clases Conceptuales: Diagrama que muestra la relación de los conceptos

importantes del domino tienen en forma estática dentro del proceso intervenido por el

sistema en análisis.

Veamos ahora cómo se desarrollan estos artefactos.



través del uso de técnicas o recetas. Veamos la técnica de identificación y descripción del proceso

y de las clases conceptuales:

ESPECIFICACIÓN DEL PROCESO DE NEGOCIO

La sintaxis de los diagramas de actividad es muy sencilla ya que se asemeja a lo que en otras

metodologías o notaciones se conocen como diagramas de flujo, pero con la salvedad que la

orientación de estos últimos se refiere al “flujo de datos” y los de actividad su centro es el “flujo

funcional o de actividades” del proceso.


54

Sintaxis Diagrama de Actividad

Calle

Acción Acción

Nodo Inicial

Nodo Final de Flujo

Flujo de Control

A Nodo Conector

ObjetoObjeto

Acción PinesInfo

<<precondicion>>

(condicion) Precondición

<<postcondicion>>

(condicion) Postcondición

Decisión / Merge

Fork

Join

<sin acción enviar> Envío de Señal

<sin acción recibir> Receptor de Señal

Excepción

Calle (Swimlane)

Nodo Final de Actividad

Señal de Tiempo

ILUSTRACIÓN 19.NOTACIÓN DE LOS DIAGRAMAS DE ACTIVIDADES

Su utilización será un poco más específica 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 inclusión, dependencia o generalización, 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

CU2: Registrar Productos de una Venta

CU3: Validar Medio de Pago

Cajero

Sistema de Inventario

SecurePay

ILUSTRACIÓN 20. DIAGRAMA DE CASOS DE USO DEL SPDV


55

Podemos ver que CU2: Registrar Productos en la Venta no tiene conexión 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 validación 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 específica:

Iniciar Venta

Ingresar Producto

Obtener Información

Registrar Producto

Rechazar Código

Calcular Total

Registrar Pago

Imprimir Comprobante

[cod valido]

[cod no valido]

[no hay mas productos]

[cliente paga]

[hay mas productos]

ILUSTRACIÓN 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 información al problema.

IDENTIFICACIÓN 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 iteración se va definiendo cuál o cuáles son los escenarios a estudiar y referente a ellos se

comienza a definir el modelo de dominio.

Venta

Pago


56

PASO 1. IDENTIFICAR LAS CLASES CONCEPTUALES

No existe la forma correcta de obtener las clases conceptuales, sino más bien existen un grupo de

recomendaciones al respecto que nos permiten utilizar las herramientas entregadas por el negocio

para éste proceso práctico.

La literatura menciona dos formas de obtener las clases conceptuales: por clasificación en

categorías de clases y por identificación de frases nominales en las especificaciones de casos de

uso. Veamos cada una de estas formas complementándolas con algunos ejemplos:

MÉTODO 1: IDENTIFICACIÓN POR CLASIFICACIÓN DE CLASES CONCEPTUALES

La primera técnica postula la utilización de una lista de categorías de clases conceptuales. Esta lista

comprende un conjunto de clases candidatas a ser conceptuales, acompañadas de ejemplos

típicos para esas clases, dentro de dominios similares al que estamos analizando.

Estas categorías son:

Objetos tangibles o físicos: Todos los objetos o elementos físicos que participan

directamente en el dominio.

Especificaciones, diseños o descripciones de las cosas: Características o descripciones que

sean de vital importancia para el dominio.

Lugares: Espacios físicos en donde el dominio toma sentido.

Líneas de la transacción: Entradas necesarias para la “ejecución” del dominio.

Roles de las personas: Roles que puede tomar la gente que participa en el dominio.

Contenedores de otras cosas: Elementos físicos que sean “agrupadores” de otros

elementos.

Cosas en un contenedor: Objetos que pueden ser contenidos en un contenedor.

Otros sistemas externos: Sistemas que estén fuera del dominio pero que se requieren

para él.

Conceptos abstractos: Conceptualizaciones u objetos no físicos 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 análisis.

Reglas y políticas: Restricciones o intereses que puedan ser relevantes en algún proceso.

Catálogos: Contenedores lógicos de información.


57

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, artículos de referencia, libros: Documentación relacionada con el

dominio.

Por ejemplo, si utilizamos el listado de categorías habituales para el dominio de la venta de un

supermercado, podemos encontrar algunos candidatos para cada categoría, los cuales los

ubicaremos en la siguiente tabla:

Categoría de Clase Conceptual Ejemplos

Objetos tangibles o físicos Registro Caja Producto Boleta

Especificaciones, diseños o descripciones de las cosas NombreDelProducto

Lugares Tienda Departamento

Líneas de la transacción LíneaDeVenta

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 ImpresiónDeBoleta EliminaciónDeProducto

Reglas y políticas ComisionesPorVenta

Catálogos N/A

Registro de finanzas, trabajo, contratos, asuntos legales Boleta Factura ContratoDeEmpleo SolicitudDeReposición

Instrumentos y servicios financieros Stock

Manuales, documentos, artículos de referencia, libros ListaDePrecios CatastroDeCajeros

ILUSTRACIÓN 22.TABLA DE IDENTIFICACIÓN DE CLASES CONCEPTUALES SEGÚN CATEGORÍAS

Como podemos ver en el ejemplo, tenemos muchos candidatos a ser clases del dominio, sin

embargo, tal como dice su definición, ellos son solo “posibles” clases conceptuales que debemos

determinar su validez dentro del dominio de análisis.


58

MÉTODO 2. IDENTIFICACIÓN POR FRASES NOMINALES EN LAS ESPECIFICACIONES

Otra técnica es identificar candidatas a clases conceptuales desde el escenario, utilizando las

frases nominales de ella. Esto se realiza haciendo un análisis lingüístico de las especificaciones de

los casos de uso del sistema en análisis.

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 línea 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 información 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.

ILUSTRACIÓN 23.ANÁLISIS 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 también las extensiones del caso de uso, ya que pueden ser fuente de nuevas

clases conceptuales y que servirán en el diseño.

Nótese que hemos subrayado conceptos que después 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 recomendación que realizan algunos autores al respecto es que se mezcle esta

técnica con la anterior de lista de categorías.

OTRAS RECOMENDACIONES PARA REFINAR EL MODELO

Un grupo de recomendaciones para la identificación de las clases conceptuales se puede enumerar

de la siguiente forma:

Utilice siempre los nombres existentes en el dominio en cuestión. Trate de no usar

conceptos que no sean parte del dominio de análisis, ya que estos pueden traer consigo

confusión desde el punto de vista conceptual.


59

Excluya siempre las características y clases conceptuales que sean consideradas

irrelevantes para el negocio de análisis.

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

información entregada por las otras clases conceptuales. En muchos casos, el reporte o

informe (como el recibo) en realidad son un medio de información obtenida desde otras

clases conceptuales, lo que llevaría a dejarlo fuera del modelo.

Cuando descubra una candidata a clase conceptual en donde posea una característica que

sea un número 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 especificación de objetos para mantener la información 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 sistémica del negocio, reduciendo así

la información duplicada.

Estas recomendaciones no son nada más que una guía para ayudar al proceso de identificación de

las clases conceptuales.

PASO 2. IDENTIFICAR ASOCIACIONES ENTRE CLASES CONCEPTUALES

Las asociaciones, según UML, son la relación semántica entre dos o más clasificadores que implica

conexiones entre sus instancias.

Tal como se detalló en la sintaxis de los modelos de dominio, la asociación debe ir acompañada de

un nombre que define qué tipo de asociación es. Este nombre indica cuál es la relación entre las

instancias asociadas de alguna forma. Estos nombres son escritos separados por un guión y no por

espacios, por ejemplo, para indicar la asociación entre la caja y la venta, podemos decir que “la

caja registra la actual venta”, lo que se traduciría en la asociación registra-la-actual.

Además del nombre, en algunos casos se puede especificar con una cabeza de flecha la

navegabilidad de la asociación, es decir, en qué sentido se lee dicha asociación. Por ejemplo:

Venta

contiene

1..*1

LineaDeVenta

ILUSTRACIÓN 24.EJEMPLO DE ASOCIACIÓN DE CLASES CONCEPTUALES

Este último detalle generalmente se excluye, porque basta mirar el modelo para darse cuenta de

la navegabilidad del mismo.


60

Por último, en los extremos de las asociaciones van lo que se conoce como Roles. Estos elementos

definen cuál es la relación que se tiene con dicho objeto, por ejemplo, número de elementos

(multiplicidad) como veremos más adelante.

MULTIPLICIDAD DE ASOCIACIONES

Cuando especificamos la multiplicidad debemos indicar en cada lado de la asociación la cantidad

de objetos con las cuales se relaciona. Estas multiplicidades pueden ser:

1 objeto de A se relaciona con 1 y solo 1 objeto de B. Ambos objetos

deben existir (obligatorio)

1 objeto de A se relaciona con 1 o más objetos de B. En este caso el

mínimo de objetos de B debe ser 1 (obligatorio).

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 mínimo ni un límite de objetos de B (optativo).

ILUSTRACIÓN 25.TABLA DE CLASIFICACIÓN DE MULTIPLICIDAD

Algunos diagramas requieren multiplicidades más específicas. En ese caso, el indicador de

multiplicidad es el número exacto de objetos relacionados (o en su defecto, los números exactos,

si pueden ser más de uno). Por ejemplo, A almacena 3 objetos de B en forma obligatoria, por lo

que en la asociación pondremos un 3 al lado de B.

CRITERIO PARA DEFINIR LAS ASOCIACIONES

La definición de las asociaciones corresponde a una labor muy delicada, ya que en un análisis

podría aparecer que todo es relevante para todo, o que todas las clases poseen alguna relación

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 relación por algún 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 análisis.

No es recomendable poner muchas asociaciones o sobrecargar el modelo con asociaciones

redundantes, porque el beneficio es realmente marginal. Por otro lado, es más importante definir

las clases conceptuales que las asociaciones (además, nos daremos cuenta que saltan a la vista las

asociaciones a partir de las clases conceptuales).

El listado de las asociaciones más comunes es:

A es una parte de B

A está contenido en B

A B 1 1

A B 1 1..*

A B 1 0..1

A B 1 *


61

A es una descripción de B

A es una línea de una transacción 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 transacción B

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

A está al lado de B

A es propiedad de B

A es un evento relacionado con B

PASO 3. AÑADIR ATRIBUTOS

Los atributos, en general, son valores de datos lógicos de los objetos. En el modelo de dominio, los

atributos se presentan solo con el nombre, y en algunos casos particulares, podrían presentarse

también con sus tipos (pero eso es opcional y es poco usado en la práctica), indicándolo después

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 están definiendo los atributos, no ponga

todos los valores que se le vengan a la cabeza, sino que los más 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 dirección: El recibo requiere la dirección de la sucursal.

Producto código: El producto debe tener un código 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.

LíneaDeVenta 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.

Nótese que muchas clases conceptuales no las especificamos aquí, aún cuando si las usaremos en

el ejemplo final. Solo hemos descrito aquellas a las que le agregaremos los atributos. Las demás,

no requieren algún 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 análisis.


62

DIAGRAMA DE CLASES CONCEPTUALES

A diferencia de lo visto en el modelo de casos de uso, en este caso la técnica o proceso se mezcla

con el diagrama, ya que finalmente no hay artefactos intermedios (excepto la tabla de

identificación de clases conceptuales por categorías) 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 notación del diagrama es la siguiente:

Notación Diagramas de Clases Conceptuales

Metaclase

-atrib : byte

Nombre

Objeto

«interface»

Interfaz

«metaclass»

Nombre

Clase

Objeto/Instancia

Interfaz

1..1

-a

0..*

1..1

-a

0..*

1

-a

0..*

Interfaz

Herencia/Generalización

Implementación de Interfaz

Composición

Agregación

Asociación

ILUSTRACIÓN 26.NOTACIÓN DE LOS DIAGRAMAS DE CLASES CONCEPTUALES

La notación 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 razón, 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 interés.

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 quedaría de la siguiente forma:


63

Iniciar Venta

Ingresar Producto

Obtener Información

Registrar Producto

Rechazar Código

Calcular Total

Registrar Pago

Imprimir Comprobante

[cod valido]

[cod no valido]

[no hay mas productos]

[cliente paga]

[hay mas productos]

ILUSTRACIÓN 27.DIAGRAMA DE ACTIVIDADES DEL SPDV

Así mismo, el diagrama de clases conceptuales del problema es el siguiente:

Caja

Venta

registra

0..*

1

Cliente

Pago

LineaDeVenta

Producto

Catalogo

SistemaDeInventario

Cajero

Tienda

inicia

11

genera1

1

utiliza1

1

alberga

1..*

1

contiene

1..*1

registra1

1

contiene1..*

1

genera

1

1

informa

1

0..*

SecurePay

se-valida-en

1

0..1

ILUSTRACIÓN 28.DIAGRAMA DE CLASES CONCEPTUALES DEL SPDV


64

MODELO DE COMPORTAMIENTO

Según 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 TRAVÉS

DE LOS ESCENARIOS PRESENTADOS EN EL MODELO DE CASOS DE

USO Y EN FUNCIÓN 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 más cajas

negras.

CONCEPTOS BÁSICOS


EVENTO

Diremos que:

UN EVENTO ES UNA INTERACCIÓN QUE EXISTE ENTRE UN ACTOR

EXTERNO Y EL SISTEMA.

Esta definición 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 interacción entre objetos sino que entre un actor

y el sistema.

CONTRATO

Una definición enciclopédica nos indica que:

UN CONTRATO ES UN ACUERDO DE VOLUNTADES QUE GENERAN

DERECHOS Y OBLIGACIONES.

Básicamente esta definición 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:


65

UN ESTADO ES UNA CONFIGURACIÓN ÚNICA DE INFORMACIÓN EN

UN PROGRAMA O MÁQUINA.

Como podemos ver el concepto es bastante amplio, ya que hace referencia a un estado en su

forma genera. Sin embargo, también podemos encontrar una definición más ad-hoc que dice que

es un conjunto particular de instrucciones las cuales serán ejecutadas en respuesta a la entrada de

la máquina.



artefactos son:

Diagrama de Secuencia: Diagrama que muestra cuáles son los eventos del sistema a partir

de los escenarios descritos en los casos de uso.

Contratos de las Operaciones: Documentos que describen cada operación del sistema

(eventos entre el actor principal y el sistema) como si fuera una máquina de estados de

tipo caja negra.

Diagrama de Estados: Diagrama que muestra una visión de máquina de estados para

objetos o procesos del dominio.




través del uso de técnicas o recetas. Veamos cada una de ellas en detalle.

DIAGRAMAS DE SECUENCIA DE LOS EVENTOS DE CASOS DE USO

Los Casos de Uso describen cómo interactúan los actores externos con el sistema de software que

estamos estudiando. Estas interacciones generalmente gatillan eventos sobre el sistema a través

de operaciones y alguna respuesta que éste le da.

Con esta motivación, UML define que:

EL DIAGRAMA DE SECUENCIA DEFINE GRÁFICAMENTE PARA UN

ESCENARIO ESPECÍFICO 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 cuál es su

implementación o cómo funcionan, sino que interactuamos directamente con ellos.


66

Pero ¿cómo y cuándo hacer un diagrama de secuencia del sistema? La teoría 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 anatomía de ellos. Es por eso que

definimos la notación UML de los diagramas a continuación:

:Objeto

Notación Diagramas de Secuencia

Objeto (Actor/Sistema)

Línea de Vida

Activación

Mensaje

Mensaje o Interacción

Retorno

Mensaje de Retorno

MensajeAutodelegación

Mensaje

Mensaje AsíncronoNota / Restricción

CicloFlujos Alternos

Loop

Loop [cond1]

[cond2]

[cond]

ILUSTRACIÓN 29. NOTACIÓN DE LOS DIAGRAMAS DE SECUENCIA

Como es de esperar, existen también mensajes en los cuales se puedan crear nuevos objetos.

Estos mensajes se les dice de Creación 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()

ILUSTRACIÓN 30. MENSAJE DE CREACIÓN DE OBJETO

Otra particularidad son los llamados Autodelegación, las cuales corresponde a una autollamada de

alguna actividad o mensaje que se realiza en el mismo objeto.


67

: Pago

5 : registrarPago()

ILUSTRACIÓN 31. MENSAJE DE AUTODELEGACIÓN

A partir de toda esta notación podemos generar los diagramas de secuencia a cualquier nivel del

proyecto, pensando en un análisis inicial (como en el ejemplo), como así en un análisis un poco

más avanzado, con objetos y mensajes entre ellos.

Por ejemplo, el mismo ejemplo que ya habíamos visto, lo podemos separar un poco con algunos

objetos conceptuales bien claros:

[p]Loop

: Cajero : Caja

: Venta

: Catalogo

1 : iniciarVenta()2 : nuevo()

34

5 : ingresarProducto()6 : p := obtenerProducto()

78 : agregar()

9

10

11 : finalizarVenta()12 : t := obtenerTotal()

13 : calcularTotal()

14

15

ILUSTRACIÓN 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 habíamos

planteado como solución, con la diferencia en que incluimos un elemento llamado Venta y otro


68

Caja, en lo que representamos los principales elementos de la venta. En este caso, la caja

representa el aparato físico con el cuál interactúa 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 análisis se ha basado en una metodología 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 EJECUCIÓN DE LAS OPERACIONES DEL SISTEMA EN

FUNCIÓN DE LOS CAMBIOS DE ESTADO DE LOS OBJETOS DEL

DOMINIO.

Con esta definición “de libro” podemos comenzar por preguntarnos cuáles son las operaciones del

sistema. Ahora bien, veamos primero la sintaxis del contrato antes de pasar al ejemplo de cómo se

describe uno.

Al igual que las especificaciones de los casos de uso, los contratos se escriben como textos bajo

cierta estructura o anatomía. Esta estructura se compone de las siguientes secciones:

Operación: <Operación del sistema>

Responsabilidad: <Objetivo de la operación>

Tipo o Clase: <Sistema, Concepto, Interfaz, Clase>

Ref.Cruzadas: <CU donde aparece>

Notas: <Notas de diseño, algoritmos e información>

Excepciones: <Casos excepcionales>

Salida: <Salidashacia fuera del sistema>

Precondiciones: <Suposiciones acerca del estado antes>

Postcondiciones: <Estado después de la aplicación de la operación>

ILUSTRACIÓN 33. NOTACIÓN PARA LOS CONTRATOS DE LAS OPERACIONES

Veamos como ejemplo el CU1. Realizar Venta. El diagrama se secuencias de ese caso de uso sería

el siguente:


69

[p]Loop

: Cajero : Caja

: Venta

: Catalogo

1 : iniciarVenta()2 : nuevo()

34

5 : ingresarProducto()6 : p := obtenerProducto()

78 : agregar()

9

10

11 : finalizarVenta()12 : t := obtenerTotal()

13 : calcularTotal()

14

15

ILUSTRACIÓN 34. DIAGRAMA DE SECUENCIA CON LAS OPERACIONES DE LA VENTA

Como podemos ver hemos destacado los 3 posible contratos a través de las operaciones del

sistema (las que vienen del mundo exterior). Utilicemos la operación ingresarProducto de nuestro

diagrama de secuencia antes mostrado.

Operación: 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:

CO1

CO2

CO3


70


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 catálogo c que tenga como valor del atributo código igual al valor cod entregado.- Se haya creado una nueva instancia ldv de LíneaDeVenta.- Se haya asociado p a ldv.- Se haya cambiado el valor cantidad de ldv por n entregado.- Se haya asociado ldv a v.

ILUSTRACIÓN 35. CONTRATO PARA LA OPERACIÓN INGRESARPRODUCTO DEL TPDV

Como podemos ver en el ejemplo, el contrato describe el “funcionamiento” desde el punto de

vista lógico de la operación 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, además de las asociaciones que aparecen,

representan lo especificado en este modelo.

TIPOS DE POSTCONDICIONES

Las postcondiciones son solo de 3 tipos:

De creación de instancias, que indican cuando se genera una nueva instancia de una clase.

De formación o rotura de asociaciones, que indican cuando se asocian o desasocian instancias.

De cambio en atributo, que indican asignaciones de información dentro de las instancias.

En nuestro ejemplo,

[Creación de Instancia] Se crea una instancia de LíneaDeVenta ldv.

[Formación de Asociación] ldv se asocia a la Venta actual.

[Cambio de Atributo] La cantidad de la ldv pasa a ser igual a cant.

[Formación de Asociación] Se asocia un DetalleDelProducto a ldv que corresponde al detalle del

producto identificado por cod.

RECOMENDACIONES

Cuando se estén describiendo los contratos, se tienen que tener en cuenta algunas

recomendaciones básicas que nos ayudarán a obtener un buen análisis 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.


71

Los parámetros expréselos 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 información en el diseño y mejor aún, 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 expréselas siempre como tiempo pasado, es decir, destaque que la postcondición es un resultado de una operación que se realiza antes de que acabe la ejecución de la misma.

Para identificar las postcondiciones, realice el siguiente ejercicio mental: tome una fotografía del escenario antes de la operación, luego ejecute la operación a ojos cerrados como en una caja negra y saque otra nueva fotografía del escenario al finalizar. Compare ambas fotografía y obtendrá las postcondiciones expresadas como un cambio de estado del escenario.

Por último, no utilice los contratos como requisito de sus análisis. 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 cuándo utilizarlos y cuando no.

LOS CONTRATOS Y LOS CAMBIOS AL MODELO CONCEPTUAL

Es normal, y tengan la certeza que se toparán con esta situación, 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 operación de finalizarIngreso() del diagrama que hemos estado estudiando

tenemos que hemos incorporado un “flag” de validación que avisa cuando la venta es completa.

Este atributo debe estar indicado en el modelo conceptual, ya que desde el punto de vista del

análisis es un detalle importante, por lo que en la clase Venta del modelo deberemos incorporarlo

como atributo de la clase con alguna notación 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 REACCIÓN A UN EVENTO.

Con esta definición, 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 notación que utilizan los diagramas de estado es:


72

Notación Diagramas de Estado

Estado Estado

Estado Inicial / Cruce

Estado Final

Decisión

Actividad Regular

H

H*

Historial Superficial

Historial Recursivo

Actividad de Estado

Estado

entry/accion

do/accion

exit/accion

evento [cond] / actividad

Estado de TérminoX

Compuesto No Ortogonal Compuesto Ortogonal

Estado

ILUSTRACIÓN 36. NOTACIÓN 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 condición entre corchetes) y también automáticas, las cuales se

representan sin ninguna acción sobre la flecha.

Entonces, ¿cuál es la utilidad de estos diagramas?.

La respuesta a esta pregunta no es fácil. 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 más 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 público 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 través de los

contratos la Venta (o sea las instancias de Venta) son las que más 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 operación) y en el CO3 se cambia el estado y se deja como

“cerrada”.

Veamos el diagrama que define estos estados para un mayor entendimiento:


73

Creada

entry/fijarFecha

crearVenta En Construcción

do/asociarLineaDeVenta

agregar

Calculada

exit/fijarTotal

calcularTotal

Pagada

exit/asociarPagoexit/cambiarEstado registrarPago

ILUSTRACIÓN 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

transición automática (una vez que es Creada, pasa automáticamente a En Construcción).

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 ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP)

El Centro Médico de Especialidades y Laboratorios Clínicos, conocido como CEMELAB, es un

servicio que de atención médica (consultas) de diferentes especialidades y laboratorio para

diferentes exámenes médicos a lo largo de todo el país. CEMELAB posee convenio con casi todas

las ISAPRES lo que la hace una excelente alternativa.

El gerente general ha decidido implantar un sistema electrónico de fichas médicas 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

electrónica está reemplazando al sistema actual de fichas de atención que tiene cada centro.

Para el diseño del SEFP se ha contratado a su consultora, la cual ha realizado una primera

entrevista obteniendo una descripción aproximada del proceso y ciclo de vida de la ficha en

cuestión. Esta información incluye la siguiente:

1) Cuando un paciente nuevo llega a cualquier centro, se le crea una nueva ficha médica, la

cual debe ser completada con la información básica del individuo (nombre completo, rut,

dirección, teléfono de contacto y correo electrónico si tuviera). Estos datos deben ser


74

ingresados en la recepción correspondiente (ya sea en el laboratorio como en la recepción

de atención médica).

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 través del terminal

ubicado en cada box de atención.

3) Una vez que ha terminado la atención del especialista, éste debe llenar con la anamnesis

realizada en la entrevista y posterior análisis realizado. Esta información debe incluir fecha

de la atención, datos de la inspección (peso, talla, IMC, temperatura y presión arterial),

observaciones del examen físico obtenido, diagnóstico e indicaciones (alimentaria y

conductual, medicamentos y/o procedimientos clínicos, derivaciones u hospitalización).

4) Además, en cada atención, el SEFP debe conectarse con un servicio web de la Agenda

Médica para informar cuando se realizan las atenciones de los especialistas, de manera de

llevar el control y poder cancelar los honorarios médicos respectivos.

5) Algo similar pasa cuando un paciente va a laboratorio por un procedimiento. En este caso

el tecnólogo médico o enfermera podrá ver la información referente a la última entrevista

con especialista o aquella que le derivó a dicho procedimiento. Así mismo, deberá ingresar

cualquier observación y los resultados obtenidos en el procedimiento (ya sea in situ o

posterior análisis de los resultados).

6) En caso de ser derivado a un centro asistencial para hospitalización, el especialista que lo

deriva podrá imprimir un informe médico que deberá presentar en el hospital o clínica que

asista para que lleve toda la información de manera más expedita.

7) El SEFP no debe realizar cobros por bonos o servicios prestados, ni tampoco el control de

remuneraciones y honorarios médicos del personal.

Lo primero que se debe realizar es un análisis 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 cómo vamos obteniendo la

información a través de los artefactos solicitados.

ESPECIFICACIÓN DE FUNCIONES

Vamos a realizar una clasificación 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

(según FURPS+).

En un análisis simple, podemos obtener que los requerimientos 1 al 6 son del tipo funcional y el

número 7 es una restricción del sistema. Por otro lado, el requerimientos 4 tiene una componente

de interoperatividad con el sistema de agendamiento médico.

Ahora, especifiquemos los 6 requerimientos funcionales con la técnica de especificación de

funciones.


75

Nombre del Sistema: Sistema Electrónico de Fichas de Paciente (SEFP)

Panorama: CEMELAB, a través de sus centros médicos y laboratorios a lo largo del país

Clientes: Recepcionistas, Médicos y Laboratoristas

Metas: Crear un sistema de registro electrónico de fichas únicas de pacientes del centro

para:

Centralizar la información médica de cada paciente registrado en el centro

Mantener la información en línea de manera de que cualquier especialista

pueda consultarla en forma oportuna

Entregar la información requerida al paciente en caso de hospitalización y/o

traslado a otro centro de atención.

# Ref: R1.1

Función: Registro de un Paciente

Descripción: El sistema debe permitir el registro de un paciente con los datos básicos de éste

(nombre completo, rut, dirección, teléfono de contacto y correo electrónico).



# Ref: R1.2

Función: Registro de Anamnesis

Descripción: El sistema debe permitir que el médico tratante ingrese el detalle de la atención

en box incluyendo los procedimientos y medicamentos indicados.



# Ref: R1.3

Función: Registro de Observaciones en un Procedimiento

Descripción: El sistema debe permitir que la enfermera o médico a cargo ingrese las

observaciones durante el procedimiento médico de un paciente.



# Ref: R1.4

Función: Registro de Resultados de un Procedimiento

Descripción: El sistema debe permitir que el tecnólogo médico ingrese los resultados y las

inferencias según sea el caso de los procedimientos realizados por el paciente.



# Ref: R2.1

Función: Consulta de Historial del Paciente

Descripción: El sistema debe permitir al profesional consultar sobre la historia reciente del

paciente registrada en su ficha.



Información Segmentada La información debe ser segmentada según el nivel de

acceso del profesional consultante.

Política

# Ref: R2.2

Función: Actualización de Agenda Médica


76

Descripción: El sistema debe actualizar el sistema de agendamiento cuando el especialista

cierra la ficha luego de terminada la consulta de un paciente.

Categoría: Oculto


Servicio Web La actualización debe realizarse a través de un servicio

web prestado por el sistema de agenda médica.

Interoperatividad

ILUSTRACIÓN 38. ESPECIFICACIÓN DE FUNCIONES DEL SEFP

Con esto ya tenemos gran parte del trabajo hecho, ya que hicimos la primera clasificación de lo

obtenido de parte del cliente.


A continuación 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 parecerán mucho a lo que

encontramos como funciones. Veamos la técnica de a poco para que vayamos descubriendo el por

qué de esta afirmación tan adelantada.

LÍMITES DEL SISTEMA

Si observamos las metas de la especificación funcional, podemos decir que el límite del sistema

está la creación y registro del historial médico de un paciente que ingresa y se atiende en algún

centro de CEMELAB. Sin embargo, también podemos decir que excluye:

La administración 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 Objetivo

Recepcionista Registrar un paciente nuevo para atención Imprimir detalle de ficha médica en caso de derivación 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

Tecnólogo Ingresar resultados y diagnóstico de un procedimiento

Paciente Ser atendido

Agenda Médica Actualizar las horas médicas cuando se cierre una atención

ILUSTRACIÓN 39. TABLA DE ACTORES Y OBJETIVOS DEL SEFP

ESPECIFICACIÓN DE CASOS DE USO DE ALTO NIVEL

Por último, con los objetivos e intersectados con la especificación de funciones, describiremos los

casos de uso del sistema:


77

Caso de Uso: CU1: Registrar Paciente

Actores: Recepcionista (I), Paciente

Tipo: Primario

Descripción: Cuando llega un paciente nuevo, éste debe ser registrado en el sistema y su ficha

será creada. La información necesaria para este registro es nombre completo, rut,

dirección, teléfono y correo electrónico.

Caso de Uso: CU2: Consultar Historial

Actores: Especialista/ Enfermera (I)

Tipo: Primario

Descripción: Antes de la atención, el encargado deberá revisar la ficha del paciente.

Caso de Uso: CU3: Registrar Anamnesis

Actores: Especialista (I), Paciente

Tipo: Primario

Descripción: Al terminar la atención médica, el médico tratante ingrese el detalle de la atención


Caso de Uso: CU4: Registrar Observaciones por Procedimiento

Actores: Enfermera (I)

Tipo: Secundario

Descripción: Durante un procedimiento, la enfermera puede ingresar observaciones que le

parezcan relevantes para el análisis del mismo.

Caso de Uso: CU5: Registrar Resultado de Procedimiento

Actores: Tecnólogo (I)

Tipo: Primario

Descripción: Al analizar una muestra, el tecnólogo debe ingresar los resultados clínicos en la

ficha, así como también el diagnóstico preliminar si procede.

Caso de Uso: CU6: Generar Traslado

Actores: Recepcionista (I), Especialista, Paciente

Tipo: Opcional

Descripción: En caso de un traslado (derivación u hospitalización), se debe emitir un informe

indicando el último diagnóstico y procedimientos asociados a éste.

Caso de Uso: CU7: Actualizar Agenda Médica

Actores: Especialista (I)

Tipo: Primario

Descripción: Cada vez que el especialista cierra una atención médica, ésta debe ser actualizada en

la agenda médica.

ILUSTRACIÓN 40. ESPECIFICACIÓN DE CASOS DE USO DE ALTO NIVEL PARA EL SEFP

Con estos 7 CU vamos a trabajar, pero solo 5 usaremos su forma expandida.

ESPECIFICACIÓN DE CASOS DE USO EXPANDIDOS

A continuación, especificaremos los casos de uso expandidos para aquellos que sean de tipo

primario.


Actores: Recepcionista (I), Paciente

Propósito: Realizar el registro de un paciente nuevo en el SEFP.

Resumen: Cuando llega un paciente nuevo, éste debe ser registrado en el sistema y su ficha


78

será creada. La información necesaria para este registro es nombre completo, rut,

dirección, teléfono y correo electrónico.

Tipo: Primario y Esencial

Ref. Cruzadas: R1.1

Curso Normal

Acciones de los Actores Respuestas del Sistema

1. Paciente llega al mesón de atención y entrega

su RUT.

2. Recepcionista ingresa RUT en el sistema para

confirmar que es nuevo.

3. Sistema confirma que el paciente es nuevo y

solicita información básica.

4. Recepcionista solicita al paciente información.

5. Paciente entrega a Recepcionista información

solicitada.

6. Recepcionista ingresa la información en el

sistema.

7. Sistema registra la información y crea la ficha

electrónica informando acción.

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 información, alerta al Recepcionista y solicita confirmación para

actualizar información.


Actores: Especialista/Enfermera (I)

Propósito: Consultar aspectos relevantes de la ficha previos a la atención.

Resumen: Antes de la atención, 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

paciente en el sistema.

2. Sistema obtiene ficha del paciente y muestra

información.

Cursos Alternos

(2a) Si el paciente no existe, lo informa y termina el CU.


Actores: Especialista (I), Paciente

Propósito: Registrar la información resultante de la consulta médica.

Resumen: Al terminar la atención médica, el médico tratante ingrese el detalle de la atención



Ref. Cruzadas: R1.2, CU7

Curso Normal


1. Especialista ingresa el RUT del paciente. 2. Sistema encuentra la ficha médica, abre la

atención médica y solicita información sobre los

datos de la inspección y observaciones al

examen físico.

3. Especialista ingresa datos de peso, talla, presión

arterial, temperatura, etc. y las observaciones si

las hubiera.

4. Sistema registra información de la inspección y

solicita información sobre diagnóstico del

paciente.

5. Especialista ingresa el diagnóstico. 6. Sistema registra el diagnóstico y solicita

información sobre procedimientos,


79

medicamentos e indicaciones.

7. Especialista ingresa los procedimientos,

medicamentos e indicaciones entregadas al

paciente.

8. Sistema registra información y cierra la atención

médica (CU7).

Cursos Alternos

(2a) Si la ficha no existe, informa al Especialista y termina el CU.


Actores: Tecnólogo (I)

Propósito: Registrar la información de análisis y diagnóstico del procedimiento realizado.

Resumen: Al analizar una muestra, el tecnólogo debe ingresar los resultados clínicos en la ficha,

así como también el diagnóstico preliminar si procede.


Ref. Cruzadas: R1.4

Curso Normal


1. Tecnólogo ingresa el RUT del paciente. 2. Sistema encuentra la ficha médica, solicita

información sobre la fecha de la muestra, los

resultados del examen y diagnóstico en caso de

ser necesario.

3. Tecnólogo ingresa datos obtenidos de la

muestra y en caso de que aplique se ingresa el

diagnóstico.

4. Sistema registra información y cierra la ficha.

Cursos Alternos

(2a) Si la ficha no existe, informa al Tecnólogo y termina el CU.


Actores: Especialista

Propósito: Enviar un mensaje al Sistema de Agenda Médica (SAM) de cierre de atención.

Resumen: Al cerrar una ficha por atención médica, el sistema debe generar un mensaje al SAM

para informar que el especialista ha dado término a la atención.


Ref. Cruzadas: R2.2, CU3

Curso Normal


1. Especialista cierra la atención médica (CU3). 2. Sistema registra el cierre de la ficha y envía un

mensaje al SAM indicando el cierre de la

atención.

3. Sistema recibe confirmación de parte del SAM

de que se ha realizado la transacción 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, quién debe cursar manualmente el proceso.

ILUSTRACIÓN 41. ESPECIFICACIÓN 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 comunicación 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 iteración y utilizar dicha información

para el análisis del sistema.


80


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 especificación expandida). Veamos el resultado:

System

Recepcionista

Especialista

Tecnólogo

Enfermera

Agenda Médica

CU1: Registrar Paciente

CU3: Registrar Anamnesis

CU7: Actualizar SAM

CU6: Generar Traslado

CU5: Registrar Resultados

CU4: Registrar Observaciones

CU2: Consultar Ficha

<<include>>

ILUSTRACIÓN 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 continuación, veamos un glosario para el problema:


Ficha Médica Registro electrónico (en este caso) en donde queda almacenada toda la historia

médica de un paciente.

Registro Proceso a través del cual se guarda la información ingresada por un usuario.

Box Espacio físico donde se realiza la anamnesis.

Anamnesis Proceso de revisión que realiza un especialista en un box de atención a un

paciente.

Datos de la Inspección Información que resulta de un examen físico realizado por un especialista en un

box de atención (peso, talla, temperatura y presión arterial).

Diagnóstico Inferencia que realiza el especialista como resultado del examen físico.

Procedimiento Cualquier tipo de examen físico o psicológico que puede solicitar el especialista.

Agenda Médica (SAM) Sistema externo necesario para registrar cuando un especialista cierra una

atención médica.

ILUSTRACIÓN 43. GLOSARIO PARA EL SEFP


81

Este glosario resumido (ya que podríamos encontrar muchos más términos para este problema)

solo muestra un ejemplo de cómo van describiéndose 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 cuestión.

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 generación 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 médica) el

cual registra la información básica de la ficha (crear).

A continuación hemos indicado un conector de decisión para diferenciar si el siguiente flujo (por

consulta médica 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 decisión para el siguiente flujo.

Finalmente, notaremos que no tiene una actividad de término, 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.


82

Recepcionista Especialista LaboratoristaSistema de Agenda Médica

Crear Ficha de Paciente

[paciente ingresa al centro]

Ver Ficha de Paciente

[paciente entra a consulta]

Ver Ficha de Paciente

[paciente entra a toma de muestra]

Realizar la Consulta

Registrar la Anámnesis

Registrar Término de Atención

Imprimir Informe Médico

[derivación a centro asistencial]

[no hay derivación]

Realizar el Procedimiento

Registrar Observaciones

Realizar Análisis

Registrar Resultados

[hay observaciones]

[no hay observaciones]

ILUSTRACIÓN 44. DIAGRAMA DE ACTIVIDADES DEL SEFP


Tal como vimos en clases, lo que vamos a realizar es utilizar ambos métodos de identificación de

clases conceptuales para luego ir dibujando el diagrama general. Veamos primero entonces la lista

de categorías:


Objetos tangibles o físicos InformeDeDerivacion

Especificaciones, diseños o descripciones de las cosas DetalleDeInforme ResultadoProcedimiento DetalleAnamnesis

Lugares CentroMedico Recepción ConsultaMedica BoxDeProcedimiento

Líneas de la transacción Anamnesis Procedimiento

Roles de la gente Recepcionista Especialista Laboratorista


83


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 políticas -

Catálogos RegistroDeFichas

Registro de finanzas, trabajo, contratos, asuntos legales -

Instrumentos y servicios financieros -

Manuales, documentos, artículos de referencia, libros InformeDeDerivacion

ILUSTRACIÓN 45. IDENTIFICACIÓN DE CLASES CONCEPTUALES SEGÚN CATEGORÍAS PARA EL SEFP

Note que aparecen las mismas clases en varias categorías. Veamos ahora las frases nominales de

los escenarios de casos de uso:


Curso Normal


9. Paciente llega al mesón de atención y entrega

su RUT.

10. Recepcionista ingresa RUT en el sistema para

confirmar que es nuevo.

11. Sistema confirma que el paciente es nuevo y

solicita información básica.

12. Recepcionista solicita al paciente información.

13. Paciente entrega a Recepcionista información

solicitada.

14. Recepcionista ingresa la información en el

sistema.

15. Sistema registra la información y crea la ficha

electrónica informando acción.

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 información, alerta al Recepcionista y solicita confirmación para

actualizar información.


Curso Normal


3. Especialista/Enfermera ingresa el RUT del

paciente en el sistema.

4. Sistema obtiene ficha del paciente y muestra

información.

Cursos Alternos

(2a) Si el paciente no existe, lo informa y termina el CU.


Curso Normal


9. Especialista ingresa el RUT del paciente. 10. Sistema encuentra la ficha médica, abre la

atención médica y solicita información sobre los

datos de la inspección y observaciones al


84

examen físico.

11. Especialista ingresa datos de peso, talla, presión

arterial, temperatura, etc. y las observaciones si

las hubiera.

12. Sistema registra información de la inspección y

solicita información sobre diagnóstico del

paciente.

13. Especialista ingresa el diagnóstico. 14. Sistema registra el diagnóstico y solicita

información sobre procedimientos,

medicamentos e indicaciones.

15. Especialista ingresa los procedimientos,

medicamentos e indicaciones entregadas al

paciente.

16. Sistema registra información y cierra la atención

médica (CU7).

Cursos Alternos

(2a) Si la ficha no existe, informa al Especialista y termina el CU.


Curso Normal


5. Tecnólogo ingresa el RUT del paciente. 6. Sistema encuentra la ficha médica, solicita

información sobre la fecha de la muestra, los

resultados del examen y diagnóstico en caso de

ser necesario.

7. Tecnólogo ingresa datos obtenidos de la

muestra y en caso de que aplique se ingresa el

diagnóstico.

8. Sistema registra información y cierra la ficha.

Cursos Alternos

(2a) Si la ficha no existe, informa al Tecnólogo y termina el CU.


Curso Normal


4. Especialista cierra la atención médica (CU3). 5. Sistema registra el cierre de la ficha y envía un

mensaje al SAM indicando el cierre de la

atención.

6. Sistema recibe confirmación de parte del SAM

de que se ha realizado la transacción 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, quién debe cursar manualmente el proceso.

ILUSTRACIÓN 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 también 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 técnica el diagrama de clases conceptuales y

veamos el resultado final:


85

Paciente

EspecialistaLaboratorista

Recepcionista

FichaDePaciente

Procedimiento Anamnesis

DetalleProcedimiento

+observaciones+resultados+diagnostico

DetalleAnamnesis

+datos_inspeccion+observaciones+indicaciones+otros

posee1

1

contiene

0..*

1

+cotiene

0..*

1

es-descrita-por

1

1

es-descrita-por

1

1

crea

0..1

1

ingresa

0..1

1

ingresa

0..1

1

DetalleDeFicha

+rut+nombre+direccion+telefono+email

es-descrita-por

1 1

ILUSTRACIÓN 47. DIAGRAMA DE CLASES CONCEPTUALES DEL SEFP

Este diagrama puede ser la primera aproximación para el futuro diseño de clases y por supuesto

un insumo importante para los siguientes artefactos y modelos de análisis y diseño.


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 través de los escenarios

encontrados en los casos de uso. Según lo expuesto en este problema, los escenarios alternos son

sencillos, así que, donde corresponda, se utilizarán los cursos alternos como parte del mismo

diagrama. Veamos el escenario del primer caso de uso:


86

: Recepcionista Sistema CatalogoDePacientes

: DetalleDeFicha

1 : validarRut()2 : pacienteExiste()

3 : ack

4

5 : ingresarDetalle()6 : nuevo()

78 : asociarDetalle()

910

ILUSTRACIÓN 48. DIAGRAMA DE SECUENCIA PARA EL CU1. REGISTRAR PACIENTE

Es posible observar en este diagrama que gran parte de la carga se la estaría llevando el objeto

DetalleDeFicha (adelantándonos para cuando lleguemos a los diagramas de estado). Sigamos con

los demás CU y sus respectivos diagramas:

Funcionario Sistema CatalogoDePacientes

1 : consultar()2 : buscar()

3

4

ILUSTRACIÓN 49. DIAGRAMA DE SECUENCIA PARA EL CU2. CONSULTAR HISTORIAL

Al igual que en el caso anterior, este diagrama no es más que una traducción del escenario

realizado para el CU. Veamos el siguiente:


87

: Especialista Sistema CatalogoDePacientes d : DetalleDeFicha

: DetalleAnamnesis

1 : consultar()

2 : buscar()

3 : d4

5 : registrarInformación()6 : crear()

7 : det

8 : registrarAnamnesis()

910

ILUSTRACIÓN 50. DIAGRAMA DE SECUENCIA PARA EL CU3. REGISTRAR ANAMNESIS

En este caso podemos ver que se complejiza un poco la lógica, sin embargo debemos destacar un

par de puntos.

1. Resumimos los 3 ingresos que existen en el escenario en 1 sola operación (con la lógica de

que la filla se llena sin registrar la información hasta el final).

2. La creación del objeto DetalleAnamnesis es porque según el modelo de dominio,

DetalleDeFicha solo sabe registrar DetalleAnamnesis a través de una Anamnesis (la cual

puede ser generad dentro de DetalleFicha como una línea de transacción).

3. Las operaciónes de consultar, en realidad es la misma utilizada en el CU2.

Sigamos con el siguiente CU:


88

: Laboratorista Sistema CatalogoDePacientes d : DetalleDeFicha

: DetalleProcedimiento

1 : consultar()2 : buscar()

3 : d

4

5 : registrarInformacion()6 : crear()

7 : det

8 : registrarProcedimiento()

910

ILUSTRACIÓN 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 podríamos

“generalizarlo” de manera de que sea más reutilizable. Sin embargo, para efectos prácticos,

sigamos con el análisis tal cual.

: Especialista Sistema AgendaMedica

1 : cerrarAtención()

2 : cierreFicha()

3 : ack4

ILUSTRACIÓN 52. DIAGRAMA DE SECUENCIA PARA EL CU7. ACTUALIZAR AGENDA MÉDICA

En el último CU analizado solo tenemos el hecho del cierre de la atención médica y en este caso

son operaciones hacia fuera del sistema, así que es poca la interacción.

Con estos diagramas completamos el análisis del comportamiento a través de las secuencias, y

pasaremos a ver los contratos.


89


Una vez que ya se han realizado todos los diagramas de secuencia, se debe comenzar identificado

cuáles son las operaciones principales para luego ir describiéndolas a través de la estructura

planteada para los contratos. Veamos entonces los contratos del problema.

Operación: CO1. validarRut(rut)

Responsabilidad: Validar que el RUT exista dentro del catalogo de pacientes


Ref. Cruzadas: CU1

Notas: -

Excepciones: Si el RUT existe, se aborta el resto del CU

Salidas: -

Precondiciones - Exista una instancia r de tipo CatalogoDePacientes

Postcondiciones: - 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

parámetro rut.

Operación: CO2. ingresarDetalle(rut, nombre, direccion, fono, email)

Responsabilidad: Crear y agregar la información básica del paciente a la ficha


Ref. Cruzadas: CU1

Notas: -

Excepciones: -

Salidas: -

Precondiciones -

Postcondiciones: - Se haya creado una instancia d de tipo DetalleDeFicha

- Se hayan fijado los atributos rut, nombre, dirección,

teléfono e email con los valores entregados por parámetro.

- Se haya creado una instancia f de tipo FichaDePaciente

- Se haya asociado d a f

Operación: CO3. consultar(rut)

Responsabilidad: Obtiene la información 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 parámetros rut.

Operación: CO4. registrarInformacion(objeto)

Responsabilidad: Registra en la ficha del paciente la información entregada en

forma de objeto.


Ref. Cruzadas: CU3, CU5

Notas: Objeto puede tomar valores de DetalleAnamnesis y


Excepciones: -


90

Salidas: -

Precondiciones - Exiasta una instancia d de DetalleDePaciente

Postcondiciones: - Se haya asociado objeto a d.

Operación: CO5. cerrarAtencion(especialista)

Responsabilidad: Envía una notificación al sistema de agenda médica

indicando el térmido de la atención del especialista.


Ref. Cruzadas: CU7

Notas: Utiliza XML para construir la llamada al SAM.

Excepciones: -

Salidas: Un mensaje intersistemas para el SAM

Precondiciones -

Postcondiciones: -

ILUSTRACIÓN 53. CONTRATOS DE LAS OPERACIONES DEL SEFP

Como podemos ver en los contratos expuestos, se hicieron varias optimizaciones en las

operaciones, generalizando las que habíamos originalmente encontrado en los diagramas. Esto

permitirá un menor riesgo desde el punto de vista del diseño e implementación futura.

DIAGRAMAS DE ESTADOS

Como última parte del análisis 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 cómo queda el diagrama de estados en este caso

(considerando todos los contratos del modelo).

Disponible

entry/fijarDetalleDePaciente

nuevo

En Llenado

do/asociarDetalle

[es atendido]

ILUSTRACIÓN 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 visión del análisis 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.


91

UNIDAD III. EL DISEÑO ORIENTADO AL

OBJETO

Durante este capítulo veremos cómo realizar el diseño de software y componentes

a partir del dominio analizado en la unidad anterior.


92

FUNDAMENTOS DEL DISEÑO DE SOFTWARE

El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica

independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y

especifican los requisitos del software, el diseño del software es la primera de las tres actividades

técnicas -diseño, generación de código y pruebas- que se requieren para construir y verificar el

software.

La visión 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 también el cómo va a funcionar el sistema.

Sin embargo, el resultado del A/DOO (Análisis y Diseño Orientado al Objeto) debe ser un modelo

cuya orientación sea, tal como dice su nombre, “orientado a objetos”, lo que permitiría luego a los

programadores realizar una construcción en lenguajes que utilizan ese paradigma (Java, C++, C#,

Eiffel, etc).

De esta manera, el Diseño Orientado al Objeto no es más que una disciplina que permite

aproximar a los programadores el sistema de análisis en un entorno orientado al objeto. Así, los

artefactos principales de ésta tiene como finalidad describir las componentes y objetos del sistema

para su construcción (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 más simple, la

arquitectura es la estructura jerárquica de los componentes del programa (módulos), la manera en

que los componentes interactúan y la estructura de datos que van a utilizar los componentes. Sin

embargo, en un sentido más amplio, los «componentes» se pueden generalizar para representar

los elementos principales del sistema y sus interacciones.

Un objetivo del diseño del software es derivar el análisis en una representación arquitectónica de

un sistema. Esta representación sirve como marco de trabajo desde donde se llevan a cabo

actividades de diseño más detalladas como la especificación de las clases del sistema. Un conjunto

de patrones arquitectónicos permiten que el ingeniero del software reutilice los conceptos del

dominio a nivel de diseño y obtener información de más bajo nivel en forma natural.

En textos sobre “ingeniería de software” se describe un conjunto de propiedades que deberán

especificarse como parte de un diseño arquitectónico:

Propiedades estructurales: Este aspecto de la representación del diseño arquitectónico

define los componentes de un sistema y la manera en que esos componentes se

empaquetan e interactúan unos con otros.

Propiedades extra-funcionales: La descripción del diseño arquitectónico deberá ocuparse

de cómo la arquitectura de diseño consigue los requisitos para el rendimiento, capacidad,

fiabilidad, seguridad, capacidad de adaptación y otras no funcionales.


93

Familias de sistemas relacionados: El diseño arquitectónico deberá dibujarse sobre

patrones repetibles que se basen comúnmente en el diseño de familias de sistemas

similares.

Además, la arquitectura se basa en diferentes vistas de la arquitectura del sistema desde una

perspectiva dada. Cada vista es una ventana a través de la cual se observa a la arquitectura para

identificar información relevante o ideas claves, ignorando todo lo que no sea parte del punto de

vista elegido. Se sugieren 6 tipos básicos de vistas de la arquitectura:

Vista Lógica: Muestra la organización conceptual del software en función de las capas,

subsistemas, paquetes, frameworks, clases e interfaces más importantes. Resume la

funcionalidad de los elementos del software importantes, como cada subsistema. Muestra

los escenarios de realización de casos de uso destacados que ilustran aspectos claves del

sistema. Esta vista utiliza diagramas de paquetes, diagramas de clases y diagramas de

interacción en UML.

Vista de Proceso: Muestra los procesos e hilos de ejecución, sus responsabilidades,

colaboraciones y la asignación a ellos de los elementos lógicos (capas, subsistemas, clases,

etc). Esta vista utiliza diagramas de clases y diagramas de interacción en UML.

Vista de Despliegue: Muestra el despliegue físico de los procesos y componentes sobre los

nodos de proceso y la configuración de la red física 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 más significativos para los

requisitos no funcionales, es decir, aquellos casos de uso que, mediante la

implementación, 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 Implementación: Muestra el modelo de implementación del sistema en función

de una descripción resumida de los entregables y cosas que crean entregables (como el

código 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 lógica,

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 opción de agregar las vistas

necesarias para definir la arquitectura del problema en estudio.

Es fácil ver que gran parte de la arquitectura de software es abarcado con el análisis y diseño que

hacemos en este curso, pero depende mucho donde y cuándo iremos describiendo eso. En


94

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 Implementación, ya que es la única que nos

permitirá mostrar la información relevante para el diseño de software.


El diseño arquitectónico pretende orientar al arquitecto en algunas líneas 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 módulos definidos.

A continuación veremos algunos aspectos básicos con los cuales debe trabajar el arquitecto antes

de llegar a obtener un diseño completo5.

CONCEPTOS BÁSICOS


REFINAMIENTO

Podemos definir que:

EL REFINAMIENTO ES UN PROCESO DE ELABORACIÓN, EN DONDE SE

COMIENZA CON UN ALTO NIVEL DE ABSTRACCIÓN PARA LUEGO DAR

LA CAPACIDAD DE IR DETALLANDO MÁS Y MÁS CADA FUNCIÓN DEL

SISTEMA.

El refinamiento paso a paso es una estrategia de diseño descendente propuesta originalmente por

Niklaus Wirth.

En cada paso (del refinamiento), se descompone una o varias instrucciones del programa dado en

instrucciones más detalladas. Esta descomposición sucesiva o refinamiento de especificaciones

termina cuando todas las instrucciones se expresan en función de cualquier computadora

subyacente o de cualquier lenguaje de programación. De la misma manera que se refinan las

tareas, los datos también se tienen que refinar, descomponer o estructurar, y es natural refinar el

programa y las especificaciones de los datos en paralelo.

5 En muchos casos, dentro del modelo arquitectónico también se incluye el modelamiento de datos, sin

embargo para la ingeniería de software son modelos diferentes.


95

Todos los pasos del refinamiento implican decisiones de diseño. Es importante que el

programador conozca los criterios subyacentes (para decisiones de diseño) y la existencia de

soluciones alternativas.

COMPONENTE

Diremos que:

UN COMPONENTE ES UNA PORCIÓN DEL SISTEMA CUYO

FUNCIONAMIENTO NO DEPENDE DE LOS SERVICIOS OFRECIDOS POR

OTROS COMPONENTES Y DEFINE INTERFACES PARA COMUNICARSE

CON ELLOS.

Este concepto básico, cuya descripción también se le conoce como subsistema, es la unidad a

través de las cuales vamos a ir refinando nuestro diseño.



artefactos son:

Factores de la Arquitectura: Documento que describe cuáles son las influencias que tienen

los factores críticos en las variaciones en el sistema.

Decisiones de la Arquitectura: Documento que describe las soluciones a los factores de la

arquitectura y cómo afectan al diseño de software.

Diagrama de Componentes: Diagrama que muestra una visión técnica de la organización

de los componetes según la arquitectura realizada.



El análisis de la arquitectura se realiza a través de 2 artefactos básicos mencionados.

A continuación veremos cómo se construyen cada uno de manera de mostrar la ruta con la cual

llegaremos al diseño detallado (de clases).

ESPECIFICACIÓN DE LOS FACTORES DE LA ARQUITECTURA

Los Factores de la Arquitectura se definen a través de una tabla en donde se especifican cuáles son

las influencias que tienen los factores críticos en las variaciones en el sistema. Esta información

viene directamente del análisis de requisitos, ya que se basa en la clasificación FURPS+ de

requerimientos para identificar los factores críticos que pueden afectar el diseño del software (por


96

lo general, todo lo que tiene que ver con la usabilidad, rendimiento, fiabilidad, soporte y el resto

de las categorías 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

ILUSTRACIÓN 55. TABLA DE FACTORES DE LA ARQUITECTURA

Según la especificación de la tabla de factores, cada campo corresponde a:

Factor: Indica cuál es el factor que se está especificando.

Medidas y Escenarios de Calidad: Indica cuales son las medidas en los cuales ese factor es

crítico para el sistema, indicando restricciones necesarias para eso.

Variabilidad: Indica la flexibilidad actual y la evolución que puede tener el factor a través

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 cuál 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.

Además, los factores van agrupado por la categoría 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 definición de uno de los principales factores de

la arquitectura quedaría de la siguiente forma.

Factor Medidas y Escenarios de

Calidad

Variabilidad Impacto Prioridad

para el Exito

Dificultad o

Riesgo

Factores de Implementación

Lector de

Códigos de

Barras

Cuando un producto pasa

por la caja, el lector de

códigos debe leer

directamente el código de

barras de la etiqueta

Debe tener ingreso

alternativo vía teclado

Bajo Alta Media

ILUSTRACIÓN 56. TABLA DE FACTORES DE LA ARQUITECTURA DEL SPDV

Veamos ahora el complemento a este documento.

ESPECIFICACIÓN DE LAS DECISIONES DE LA ARQUITECTURA

Luego de obtenida la tabla de factores, se deben indicar las soluciones que se plantearán por cada

categoría de factores y así detectar aquellas que afectan directamente al diseño.


97

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

Categoría: <Nombre de la categoría de factores>

Resumen: <Resumen del factor y de la solución propuesta>

Factores: <Enumeración de los factores relacionados>

Solución: <Detalle de la solución propuesta>

Motivación: <Justificación del problema y la solución>

Temas Abiertos: <Factores que no quedan resueltos y que se relacionan con el tema>

Alternativas: <Alternativas a la solución propuesta>

ILUSTRACIÓN 57. TABLA DE DECISIONES DE LA ARQUITECTURA

Es fácil ver que es importante dejar en un solo documento ambos artefactos, ya que son

complementarios. Desde el punto de vista académico los seguiremos viendo en forma separada.


El tercer artefacto, un poco independiente a los anteriores, define la visión más cercana al diseño

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

usarán para construír el sistema, ya sean desde el punto de vista de organización de elementos del

diseño (clases) como también la identificación de componentes reusables que no sea necesario

“re-hacer”.

De esta manera, este artefacto tiene dos objetivos básicos:

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:

ILUSTRACIÓN 58. NOTACIÓN 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 diseño como tal. De esta

manera es importante determinar cómo vamos a identificar la componentes.

Para ello diremos que son componentes o paquete de clases:


98

El conjunto de clases que permiten acceder a los datos del sistema (clases que

representan ítemes y catálogos, 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 sería la

tercera de la lista, ya que podría cumplir con las otras anteriores fácilmente.

Además, distinguimos entre paquete o componente solo conociendo el estilo de programación

que usaremos. Por ejemplo, si usamos Java, podemos hacer nuestro diagrama considerando

paquetes de clases (con la notación de paquete) y en el caso de usar ActiveX o librerías

compiladas, podemos hablar de componentes.

Con estas sencillas reglas, generalizando el problema del supermercado podríamos determinar el

siguiente diagrama de componentes:

ILUSTRACIÓN 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 operación de la tienda dentro del paquete Tienda, lo que tiene que ver

con la operación de la bodega dentro del paquete Bodega, y lo que tiene que ver con las

operaciones financieras en el paquete Finanzas. Además, se definieron unas interfaces que

casualmente representan los conceptos del dominio que nos enlazan con dichos paquetes

(CatálogoDeProductos y RegistroDeVentas), lo que por supuesto nos define el tipo de interacción

que tendrá Tienda con los paquetes vinculados (Bodega y Finanzas).

MODELO DE DISEÑO

El Modelo de Diseño es, por esencia, el principal modelo en la fase de diseño del UP, sin embargo

contiene varios artefactos y técnicas necesarias para completar el diseño. Principalmente, y lo que

veremos en este curso, el Modelo de Diseño se centrará en 2 artefactos: Diagramas de

Colaboración y Diagrama de Clases.


99

CONCEPTOS BÁSICOS

Veamos algunos conceptos básicos con los que nos toparemos al desarrollar este modelo.

REALIZACIÓN DE CASO DE USO

Podemos decir que:

LA REALIZACIÓN DE UN CASO DE USO DESCRIBE CÓMO SE REALIZA EL

CASO DE USO PARTICULAR EN EL MODELO DE DISEÑO, EN FUNCIÓN

DE LOS OBJETOS DEL SISTEMA QUE COLABORAN ENTRE SÍ.

Si analizamos un poco más esta definición, lo que queremos decir es que en la realización, el

arquitecto se preocupa de describir el diseño de uno o más 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

explícitamente en los diagramas de secuencia de eventos (en el análisis). Luego de eso, estos

eventos pueden ser descritos en contratos de las operaciones del sistema (también del análisis).

Así, los eventos del sistema representan los mensajes que inician los diagramas de interacción, los

cuales representan el modo en el que los objetos interactúan para llevar a cabo las tareas

requeridas (realización). Por último, la estas interacciones ocurren entre objetos que se inspiran

en las clases conceptuales del modelo de dominio, además de otras clases de objetos.

RESPONSABILIDAD

Podemos definir inmediatamente que:

LA RESPONSABILIDAD ES UN CONTRATO U OBLIGACIÓN DE UN

OBJETO EN CUANTO A SU COMPORTAMIENTO.

En efecto, las responsabilidades nos definen ciertos parámetros de las obligaciones que poseen los

objetos dentro del modelo de diseño. 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 Líneas 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 cálculo, iniciar una acción en otros objetos y controlar y

coordinar actividades en otros objetos (ej: La Venta es responsable de crear Líneas 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 fácil detectarlas con los atributos de las clases conceptuales.


100

Sin embargo, las responsabilidades no son lo mismo que los métodos, aún cuando tienen una

estrecha relación: los métodos se implementan para llevar a cabo responsabilidades. En efecto,

para que se cumplan las responsabilidades identificadas, es necesario implementarlas a través de

uno o más métodos que actúan 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 método

getVenta, el cual utiliza los métodos getSubtotal de la clase Línea de Venta quien le entrega el

valor total de cada línea de venta (precio x cantidad) para calcular el total de la venta.

PATRONES DE DISEÑO

En el contexto de la tecnología de objetos, podemos definir que:

UN PATRÓN ES UN PAR PROBLEMA - SOLUCIÓN CON NOMBRE QUE

SE PUEDE APLICAR EN NUEVOS CONTEXTOS, CON CONSEJOS ACERCA

DE CÓMO APLICARLO EN NUEVAS SITUACIONES Y DISCUSIONES

SOBRE SUS COMPROMISOS.

Algo elevado, ¿no?. Pues si analizamos un poco esta definición, podemos inferir lo que los autores

nos intentan decir. Los patrones son una “especificación” analítica reutilizable, con una estructura

que responde a la siguiente:

Nombre

Solución

Problema [que resuelve]

Más que especificar ideas nuevas, los patrones pretender codificar conocimiento, estilos y

principios existentes y que se han probado que son realmente válidos. Esto quiere decir, que entre

más trillados y extendidos, mejor.

Todos los patrones poseen nombres sugerentes, ya que definen en un solo concepto lo que están

resolviendo. Es por eso que los autores han procurado en definir estos nombres de una forma

“estándar” para que los diseñadores los utilicen como lenguaje común. De esta forma,

encontraremos nombres tan esotéricos y descriptivos como “Experto en Información”, “Creador”,

“Factoría”, “Variaciones Protegidas”, etc.

Los patrones de diseño nos ayudan a determinar las clases conceptuales que son más aptas o que

realmente compondrán 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 básica:

Si hay clases relevantes en el Modelo de Diseño previo, considerar esa como posible clase

de diseño real.


101

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

Dominio e intente utilizar (o ampliar) sus representaciones para inspirar la creación de las

correspondientes clases de diseño.

He aquí nuestro primer indicio de donde podemos encontrar las clases de diseño. Por otro lado,

para comenzar el diseño 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 explícitamente en los

Diagramas de Secuencia del sistema.

Opcionalmente, podrían describirse los detalles de los efectos de los eventos del sistema

en términos 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

Interacción, los cuales representan el modo en el que los objetos interactúan para llevar a

cabo las tareas requeridas (Realización de Casos de Uso).

Los Diagramas de Colaboración comprenden la interacción de mensajes entre objetos de

software cuyos nombres se inspiran algunas veces en los nombres de las clases del

Modelo del Dominio, además de otras clases de objetos.

Más adelante, cuando analicemos los patrones de diseño GRASP y GoF veremos cómo esta

definición se concreta en una lista de “reglas” que podemos usar al realizar nuestros casos de uso.



artefactos son:

Diagrama de Colaboración: Diagrama que muestra cuáles son las operaciones y cómo

interactúan entre sí los objetos de diseño del sistema.

Diagrama de Clases de Diseño: Diagrama que muestra una visión estática de las clases del

sistema, representando los tipos de objetos que se requieren para realizar la interacción

modelada en los diagramas de colaboración.




través del uso de técnicas o recetas. Veamos cada una de ellas en detalle.

DIAGRAMAS DE COLABORACIÓN

UML nos dice que:


102

EL DIAGRAMA DE COLABORACIÓN DEFINE GRÁFICAMENTE PARA UN

ESCENARIO ESPECÍFICO DE UN CASO DE USO LAS

RESPONSABILIDADES GENERADAS ENTRE LOS OBJETOS DE DISEÑO

DEL SISTEMA A PARTIR DE LAS OPERACIONES DEL SISTEMA.

Como podemos ver en la definición 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 interacción). Sin embargo, el hincapié de estos diagramas o su motivación tiene que

ver en diseñar las responsabilidades delegadas a partir de la operación de sistema (que ya

conocemos) en los objetos internos del sistema. A este proceso de inferencia de responsabilidades

se le conoce como aplicación de responsabilidades.

Para hacer estos diagramas, se necesita entender algo de la anatomía de ellos. Es por eso que

definimos la notación UML de los diagramas a continuación:

Notación Diagramas de Colaboración/Comunicación

Objeto:Objeto

:Objeto Objeto Múltiple

n: Expresion Mensaje

{

...

}

Código

n: [cond] ExpresionMensaje Condicionado

n*: [cond] Expresion Mensaje Cíclico

n: var := mensaje(param: Tipo, ...) : TipoRetorno Sintaxis de los mensajes

ILUSTRACIÓN 60. NOTACIÓN DE LOS DIAGRAMAS DE COLABORACIÓN

Debemos destacar que los diagramas de colaboración los utilizaremos para describir las

operaciones del sistema identificadas en los diagramas de secuencia con el detalle de operación y

diseño 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 operación de agregarProducto(cod, cant) en donde se agrega a la venta en curso una cantidad

determinada de cierto código de producto podemos obtener el siguiente diagrama:


103

ILUSTRACIÓN 61. DIAGRAMA DE COLABORACIÓN DE INGRESAR PRODUCTO PARA TPDV6

Este diagrama es el reflejo de la lista de postcondiciones que se definen en el contrato de la

operación 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 parámetro 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 parámetro cant

(responsabilidad 6).

Que se haya asociado ldv a v (responsabilidad 4, solo por entregar el control de la creación

a Venta).

La intensión de mostrar el diagrama no es dar la fórmula de cómo se realizan sino más bien ilustrar

la forma cómo se utiliza la notación anteriormente mostrada, ya que debemos seguir un proceso

con el cual obtendremos este diagrama a partir del uso de patrones de diseño.

PATRONES DE DISEÑO GRASP

Los Patrones Generales de Software para la Asignación de Responsabilidades (GRASP) no son

más que un conjunto patrones de diseño que nos ayudarán a definir nuestras responsabilidades,

6 El programa StarUML no permite poner mensajes sin secuencia, por lo que el diagrama quedó con la

operación del sistema indicada por la responsabilidad número 1. Sin embargo, según lo visto en clases, no es

relevante.


104

es decir, describen los principios fundamentales del diseño de objetos y la asignación de

responsabilidades, expresados en forma de patrones.

La asignación habilidosa de responsabilidades es extremadamente importante en el diseño de

objeto, ya que a menudo tiene lugar durante la creación de los diagramas de interacción, tal como

dijimos antes, pero además con mayor seguridad se realizará durante la programación. A través de

patrones, este trabajo se hace mucho más fácil, ya que no requieren de una validación antes de

ser “implementados” porque se está tan seguro de su validez gracias a su vasta utilización en

diferentes problemas.

En un principio, analizaremos algunos patrones básicos y que se refieren a aspectos

fundamentales del diseño. Sin embargo, existen otros que podrían aparecer durante el estudio

posterior.

Para la definición de cada patrón utilizaremos la pseudo-notación sugerida anteriormente

(Nombre, Solución, Problema [que resuelve]).

PATRÓN DE EXPERTO DE INFORMACIÓN

NOMBRE: EXPERTO DE INFORMACIÓN (O EXPERTO)

Solución: Asignar una responsabilidad al experto en información – la clase que tiene la

información necesaria para realizar la responsabilidad.

Problema: ¿Quién debería ser el responsable de conocer una información particular?

La información es una parte importante de los objetos, ya que definen sus características y su

naturaleza. Es por ello que identificar el objeto que realmente debe contener una información

particular se convierte en una preocupación que durante la realización de los casos de uso debe

ser resuelta. De esta manera, al identificar estos objetos, estaremos definiendo información

relevante para el diagrama de clases de diseño.

Por ejemplo, veamos el contrato de la operación ingresarProducto:


105


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:


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 catálogo c que tenga como valor del atributo código igual al valor cod entregado.- Se haya creado una nueva instancia ldv de LíneaDeVenta.- Se haya asociado p a ldv.- Se haya cambiado el valor cantidad de ldv por n entregado.- Se haya asociado ldv a v.

ILUSTRACIÓN 62. CONTRATO DE OPERACIÓN INGRESAR PRODUCTO DEL SPDV

Para poder encontrar un producto dentro del catálogo, es importante saber quién tiene los

códigos de cada producto de manera de compararlo con el código entregado por el cajero a través

de la caja (lector de códigos o teclado).

De esta manera, preguntamos entonces ¿quién debe ser el responsable de conocer el código de

un producto?. Parece una pregunta sencilla de responder, porque el modelo conceptual de este

problema lo plantea de forma explícita, 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 cuál es su propio código, ya que

es parte de su definición desde los requisitos. Sin embargo, como la operación llega a la caja,

debemos delegar la responsabilidad de realizar la búsqueda del producto que tenga el código

indicado en el contrato a la clase que trabaja más estrechamente con el producto: la clase

Catálogo.

De esta manera, el diagrama se comienza a dibujar de la siguiente forma:


106

ILUSTRACIÓN 63. DELEGACIÓN DE RESPONSABILIDAD DE EXPERTO DE INFORMACIÓN

A pesar de que a través del patrón es muy claro en asignar las responsabilidades de “experto”,

existen algunos casos en los cuales la solución propuesta por éste vaya en contra de otros

patrones de asignación de responsabilidad. Es por eso que es importante tener una visión general

de todos los patrones antes de comenzar a dar responsabilidades indiscriminadamente (si lo

vemos recursivamente, es una gran responsabilidad entregar responsabilidades). Los buenos

diseñadores no son aquellos que se ciñen al pie de la letra a recetas, sino más bien, aquellos que

poseen la visión de considerar todos los factores del problema para diseñar la mejor de las

soluciones, o al menos la que mejor se ajusta a él.

PATRÓN DE CREADOR

NOMBRE: CREADOR DE INSTANCIAS (O CREADOR)

Solución: Asignar la responsabilidad a la clase B de crear instancias de la clase A si cumple uno o

más de los siguientes casos:

B agrega objetos de A

B contiene objetos de A

B registra instancias de objetos de A

B utiliza más estrechamente objetos de A

B tiene los datos de inicialización que se pasará a un objeto de A cuando sea creado

B es un creador de los objetos A

Si se puede aplicar más de una opción, inclínese por una clase B que agregue o contenga la clase

A.

Problema: ¿Quién debería ser el responsable de la creación de una nueva instancia de alguna

clase?

La creación de instancias es una actividad muy común en sistema orientados a objetos, por lo que

esta responsabilidad parecería algo “trivial”. Sin embargo, una asignación adecuada de ella puede


107

hacer que nuestros diseños puedan soportar bajo acoplamiento, mayor claridad y alta

reutilización.

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 postcondición, la creación

de la línea de venta quedaría en manos de Caja. Si aplicamos las condiciones del patrón

tendríamos que:

Caja tiene los datos de inicialización de LineaDeVenta (producto y cantidad)

Sin embargo esto no es suficiente ya que debemos cumplir con al menos 2 características listadas.

Si seguimos bajando en el diagrama de clases conceptuales, podemos consultar por Venta, ya que

por naturaleza es contenedor de LineaDeVenta. Listemos las características 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 inicialización de LineaDeVenta, pero puede tenerlo (por

delegación de la caja)

De esta forma, podemos rápidamente hacer que Venta tenga 3 características convirtiéndola 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 sería el siguiente:

ILUSTRACIÓN 64. DELEGACIÓN DE RESPONSABILIDAD DE CREADOR DE INSTANCIAS


108

Al igual que todos los patrones que estamos viendo, ellos definen una guía más que una receta,

por lo que el arquitecto es quien definirá si lo que se presume a través del patrón es en realidad un

buen candidato. Esto puede pasar cuando analizamos el patrón de “Creador” en casos en donde

requerimos utilizar instancias recicladas.

PATRÓN DE CONTROLADOR

NOMBRE: CONTROLADOR

Solución: 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 sesión o de caso de uso).

A menudo este es nombrado como <Nombre>Controlador, <Nombre>Manejador o

<Nombre>Coordinador.

Problema: ¿Quién debe ser responsable de gestionar un evento de entrada al sistema?

Antes que todo, un evento de entrada al sistema no es más 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 métodos.

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 método para la operación del

sistema.

Siguiendo con el ejemplo de ingresarProducto, tenemos que la operación 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 sería

CajaControlador)

b) Venta es la clase que representa el CU Registrar Venta (y en este caso quedaría como

VentaControlador)

La elección es del arquitecto, por lo que la mejor opción depende de la complejidad. Si el sistema

es grande, a lo mejor separar el controlador lo hace más especializado para cada uno de los

subproblemas, pero si no, si el problema no es muy grande, un controlador único es más sencillo

de implementar.

En este caso quedaría el diagrama:


109

ILUSTRACIÓN 65. IDENTIFICACIÓN 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, aún cuando es más recomendable el análisis antes de

cualquier otro patrón. Además, 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 cohesión, 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 diseño ya no tiene una que,

en forma innata, puede tomar ese rol.

No entregue funciones del controlador a la interfaz del usuario.

PATRÓN DE ALTA COHESIÓN

NOMBRE: ALTA COHESIÓN

Solución: Asignar una responsabilidad de manera que la cohesión permanezca alta.

Problema: ¿Cómo mantener la complejidad manejable?

Antes de poder responder a esta pregunta, nos preguntamos qué es la cohesión. Este concepto

tiene relación a la fuerza con la que se relacionan y el grado de focalización de las

responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas y

que no hace gran cantidad de trabajo tiene una alta cohesión.

Para nosotros, es mucho más importante que nuestros objetos posean una alta cohesión, ya que

los objetos una baja cohesión nos complica más el problema. Los objetos de baja cohesión son

difíciles de entender, reutilizar, mantener y delicados, es decir, constantemente afectados por los

cambios.


110

Por ejemplo, en el caso de la operación 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 concepción de la clase respectiva (el controlador solo controla, la Venta

solo crea LineaDeVenta, el Catálogo solo consulta Productos, etc).

Existen en la literatura muchas recomendaciones con respecto a la cohesión en el diseño

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 través de estas páginas, el nivel de cohesión

debe ser considerado siempre con la compañía de otros patrones como el de acoplamiento y

experto. De hecho, el ejemplo utilizado, además de ser de “Alta Cohesión”, cumple con la

condición de “Bajo Acoplamiento” según lo que vamos a ver a continuación.

PATRÓN DE BAJO ACOMPLAMIENTO

NOMBRE: BAJO ACOPLAMIENTO

Solución: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo.

Problema: ¿Cómo soportar bajas dependencias, bajo impacto al cambio e incremento de la

reutilización?

Grandes preguntas que todos nos hacemos cuando diseñamos 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 confía en otros elementos. En otras palabras, un bajo (o débil) acoplamiento

de un elemento es cuando éste no dependen “mucho” de otros elementos.

De esta forma, si tuviéramos elementos con alto acoplamiento, se presentan problemas de que los

cambios en las clases relacionadas fuerzan a cambios locales, son difíciles 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 patrón anterior, la asignación de responsabilidades de

ingresarProducto, además de ser de alta cohesión, 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 colección de productos (Catálogo 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 patrón en relación a los demás, ya

que, como vimos en el ejemplo, están 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 método que referencia a una instancia de B, o al propio B de alguna forma

(parámetro o tipo de retorno).


111

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 fuésemos extremadamente

rigurosos, la orientación al objeto no podría ser realizada, ya que no usaríamos interfaces,

asignaciones de objetos, etc. Es por eso que el diseñador debe tener en cuenta estos detalles para

mantener un “Bajo Acoplamiento” pero nunca intentar eliminarlo (usar lo mínimo necesario para

el sistema en desarrollo).

Un tema particular en donde el acoplamiento no es “malo” es cuando se utilizan librerías estables

y extendidas, es decir, aquellas librerías en donde estamos seguros que si cambia algo funcional

dentro, nuestros desarrollos no se verán afectados mayormente.

OTROS PATRONES GRASP

Los 5 patrones antes vistos corresponden a los básicos que se utilizan en el GRASP para

determinar responsabilidades en las realizaciones. A continuación enumeraremos otros patrones

que son importantes ya que entregan información o definen técnicas para la implementación y

que complementan nuestro análisis de operaciones.

NOMBRE: POLIMORFISMO

Solución: Cuando una responsabilidad posee varias alternativas para comportamientos similares,

se asignarán a los tipos en que el comportamiento presenta las variantes.

Problema: ¿Cómo manejar las alternativas basadas en el tipo?

NOMBRE: FABRICACIÓN PURA

Solución: 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 función más que mantener nuestro sistema altamente cohesivo, de bajo

acoplamiento y potenciando la reutilización de componentes.

Problema: ¿Quién es el responsable de mantener la alta cohesión y el bajo acoplamiento cuando

ya no tenemos más 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 cohesión y acoplamiento, es necesario buscar una

solución aún cuando esta no se encuentre en el alcance conceptual.

NOMBRE: INDIRECCIÓN

Solución: 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 indirección entre el resto de los componentes o servicios.

Problema: ¿De qué manera podemos desacoplar los objetos para así mantener una potencial

reutilización y un bajo acoplamiento? ¿Quién debe tener la responsabilidad de mediar para

mantener la indirección entre las componentes?


112

NOMBRE DEL PATRÓN: NO HABLES CON EXTRAÑOS

Solución: 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 patrón

establece que en un método, los mensajes solo deberían enviarse a los siguientes objetos:

El objeto “this”.

Un parámetro del método.

Un atributo de “this”.

Un elemento de una colección que sea atributo de “this”.

Un objeto creado al interior del método.

De esta manera, los objetos directos con “conocidos” del cliente, en cambio los indirectos son

“extraños”, y un cliente solo debería tener conocidos, pero no extraños. Por lo tanto, con este

patrón estamos no acoplando el conocimiento de los objetos indirectos ni las representaciones

internas de los objetos directos al cliente.

Problema: ¿Quién 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 representación interna de otros, ¿cómo podrá entonces

hacerlo sin acoplarse al conocimiento de la estructura de su objeto servidor o de los

indirectos?

PATRONES DE DISEÑO GOF

Los Patrones de Diseño GoF (Gang of the Four7) son un grupo de patrones que los autores

actualmente utilizan en su mayoría como la base para el diseño. Si bien es cierto, GRASP daba

algunos indicios de cómo hacer el diseño OO, con GoF se incluyen conceptos mucho más

específicos como constructores, adaptadores, puentes, entre otros y que son muy útiles al

momento de diseñar un sistema orientado al objeto.

A diferencia de GRASP, los patrones GoF se describen en base a una estructura un poco más

compleja, pero la base es la misma, y es la siguiente:

Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la

comunidad (normalmente se expresa en inglés).

Clasificación del patrón: creacional, estructural, de comportamiento o de sistema.

Intención: ¿Qué problema pretende resolver el patrón?

7 Gang of The Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides


113

También conocido como: Otros nombres de uso común para el patrón.

Motivación: Escenario de ejemplo para la aplicación del patrón.

Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.

Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el

patrón.

Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que

participan en el patrón.

Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.

Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación

del patrón.

Im<plementación: Técnicas o comentarios oportunos de cara a la implementación del

patrón.

Código de ejemplo: Código fuente ejemplo de implementación del patrón.

Usos conocidos: Ejemplos de sistemas reales que usan el patrón.

Patrones relacionados: Referencias cruzadas con otros patrones.

Para que no entremos en tanto detalle veamos ahora una pequeña descripción de los patrones

GoF según su clasificación:

PATRONES CREACIONALES

Los patrones de diseño creacionales son todos aquellos que se aplican en la creación de instancias

de objetos en general. Estos patrones son:

Abstract Factory (Fábrica 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 creación de un objeto complejo,

centralizando dicho proceso en un único punto.

Factory Method (Método de fabricación): Centraliza en una clase constructora la creación

de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para

elegir el subtipo que crear.

Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.

Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la

creación de un mecanismo de acceso global a dicha instancia.


114

PATRONES ESTRUCTURALES

Los patrones de diseño 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 podría utilizarla.

Bridge (Puente): Desacopla una abstracción de su implementación.

Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple

se tratase.

Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.

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

idéntica información.

Proxy: Mantiene un representante de un objeto.

PATRONES DE COMPORTAMIENTO

Los patrones de diseño de comportamiento definen algunos tipos de comportamientos de los

objetos y entregan información de cómo realizar dichos comportamientos. Estos patrones son:

Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben

llevar los mensajes para que los objetos realicen la tarea indicada.

Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha

operación sin necesidad de conocer el contenido de la misma.

Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así

como las herramientas necesarias para interpretarlo.

Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos

independientemente de la implementación de estos.

Mediator (Mediador): Define un objeto que coordine la comunicación 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 automáticamente todos

los objetos que dependen de él.

State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie

su estado interno.


115

Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y

elegir cuál utilizar en tiempo de ejecución.

Template Method (Método plantilla): Define en una operación 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 jerarquía de clases sin

modificar las clases sobre las que opera.

PATRONES DE SISTEMA

Los patrones de diseño de sistema definen algunas características 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

lógicas: modelo, vista y controlador, facilitando la modificación o personalización de cada

parte.

Session (Sesión): 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

comunicación 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 operación ha

finalizado.

Succesive Update (Actualización Sucesiva): Ofrece a los clientes una forma de recibir

actualizaciones continuas.

Router (Encaminador): Desacopla múltiples fuentes de información de los objetos de esa

información.

Transaction (Transacción): Agrupa una colección de métodos de forma que todos ellos

finalicen correctamente o fallen de forma colectiva.


El resultado del diseño (y que por supuesto es de todo nuestro trabajo en este curso) por

excelencia es el Diagrama de Clases de Diseño (DCD). Por eso, comenzaremos diciendo que:

LOS DIAGRAMAS DE CLASES DE DISEÑO SON FIGURAS QUE

MUESTRAN LA ESPECIFICACIÓN DE LAS CLASES E INTERFACES DE

SOFTWARE QUE PARTICIPAN EN LA SOLUCIÓN.


116

A partir de esta definición podemos entender, por lo tanto, que el DCD contiene realmente el

software como debe ser programado. En ellos encontramos toda la especificación necesaria para

la implementación, ya que en ellos se describen los atributos, tipos relevantes y métodos 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

Métodos

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 compondrán el sistema a implementar, y también gran parte de la lógica

interna de cada uno de los métodos. De esta manera, la construcción del sistema está muy

completa, dejando poco trabajo para la fase de implementación real.

La notación 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 serán implementadas y no solo conceptos que

representan elementos del negocio. Esta notación UML es la siguiente:


117

Notación Diagramas de Clases

Metaclase

+oper() : char

-atrib : byte

Nombre

Objeto

«datatype»

TipoDeDatos

«interface»

Interfaz

Clase

Param

«metaclass»

Nombre

Clase

Objeto/Instancia

Tipo de Dato

Interfaz

Tipo Parametrizado

1..1

-a

0..*

1..1

-a

0..*

1

-a

0..*

Interfaz

Paquete {}Paquete

Nota

Restricción

Dependencia

Herencia/Generalización

Implementación de Interfaz

Composición

Agregación

Asociación

ILUSTRACIÓN 66. NOTACIÓN PARA LOS DIAGRAMAS DE CLASES DE DISEÑO

Veamos un ejemplo en el cual se nota la diferencia entre el modelo conceptual y las clases de

diseño. Tomemos la asociación que hay entre Caja y Venta en el problema del supermercado. Para

el diagrama de clases conceptuales, tenemos lo siguiente:

ILUSTRACIÓN 67. ASOCIACIÓN A NIVEL DE CLASES CONCEPTUALES

Después de las realizaciones, este diagrama se convierte en algo más parecido a:

ILUSTRACIÓN 68. ASOCIACIÓN A NIVEL DE CLASES DE DISEÑO


118

Más adelante descubriremos notación adicional para otro tipo de situaciones específicas y que se

relacionan con nuevos patrones de asignación de responsabilidades. Sólo es importante recordar:

Considerar cuál es la audiencia del DCD nos dará el nivel de detalle.

El DCD es un apoyo y una base para la implementación, por lo es necesario evitar el detalle

exhaustivo cuando éste pueda provocar confusión.

TÉCNICA DE CONSTRUCCIÓN DE LOS DCD

En el proceso normal de generación del DCD, todo comienza por identificar las clases de diseño a

partir de los diagramas de interacción. Aún cuando esto ya lo hemos hecho de manera parcial, es

bueno que reunamos toda la información en un solo diagrama.

PASO 1: IDENTIFICACIÓN DE LAS CLASES DE DISEÑO Y SUS ATRIBUTOS

Lo primero que hacemos es dibujar las clases que se encuentran en los diagramas de interacción y

les ponemos los atributos identificados en el Modelo de Dominio:

ILUSTRACIÓN 69. IDENTIFICACIÓN DE LAS CLASES DE DISEÑO

IDENTIFICANDO LOS NOMBRES DE LOS MÉTODOS DE LAS CLASES DE DISEÑO

Una vez que eso se encuentra dibujado, comenzamos añadiendo los nombres de los métodos de

manera análoga a las responsabilidades identificadas en las realizaciones. De esta forma, los

mensajes que encontramos en los diagramas de interacción se convierten en métodos físicos de la

clase:

ILUSTRACIÓN 70. IDENTIFICACIÓN DE UN MÉTODO A PARTIR DE UNA COLABORACIÓN


119

De esta forma, nuestro DCD va creciendo y se convierte en:

ILUSTRACIÓN 71. IDENTIFICACIÓN DE MÉTODOS DE LAS CLASES

Algo muy importante al bautizar los métodos es tener en cuenta algunas cuestiones que definen

un buen diseño:

La instanciación o inicialización de objetos no es una cuestión estándar 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 obtención de valores de un objeto (método de obtención o

de acceso) o al cambio de valores de un objeto (método de mutación o de cambio) se

utiliza generalmente el nombre como “get”/”set” más el atributo que acceden. Por

ejemplo, existe el método getCodigo en la clase Producto que entrega el total de la venta.

Sin embargo, no se requiere especificar en el DCD todos los métodos accesadores o

mutadores, ya que implicaría tener una lista muy grande de métodos que son irrelevantes

para el diseño, es por eso que solo aparecen aquellos que son “relevantes” o que generan

algún valor para el diseño.

La sintaxis que se utilice en los DCD debería corresponder a la sintaxis básica de UML y no

a alguna en particular del lenguaje de implementación. Idealmente la traducción se debe

realizar cuando se implemente el código que representa el diseño deseado. Sin embargo,

en ninguna parte UML niega el uso de otra sintaxis en sus diagramas, por lo que queda a

criterio del diseñador finalmente.

AGREGANDO INFORMACIÓN DE LOS TIPOS DE DATOS

La información de tipos de datos en los DCD es relevante, ya que agrega información de bajo nivel

para los desarrolladores o para las herramientas que generan el código en forma automática. Sin

embargo, la decisión de agregar los tipos de datos y los parámetros a los métodos pasa por una

definición del diseñador considerando que:

Si se está utilizando una herramienta CASE que genera código en forma automática, el

detalle de los tipos debe ser exhaustivo y concordante con el lenguaje que se utilizará en

la implementación.


120

Si el DCD es solo para que lo vean los desarrolladores, agregar muchos detalles de tipos y

parámetro podría complicar el modelo más que aclararlo porque se convierte en mucho

ruido para ellos. En este caso la recomendación es utilizar tipos de datos lógicos que

representen la información a guardar (por ejemplo, Texto, Número, CódigoDeBarras, etc).

Sin embargo, tomar la decisión 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

parámetros 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

asociación, es necesario preguntarse “¿qué asociaciones se requieren para satisfacer la visibilidad

y las necesidades de memoria actuales que se indican en los diagramas de interacción?”. Esta

visibilidad requerida es necesaria en los siguientes casos comunes:

Cuando A envía un mensaje a B.

Cuando A crea una instancia de B.

Cuando A necesita mantener una conexión a B.

Una vez que se ha encontrado la asociación, es necesario además darle el concepto de

navegabilidad. Con esto, se le da un nivel de dependencia a la asociación, lo que se traduce en

visibilidad de atributo:

ILUSTRACIÓN 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 ¿dónde 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 implementación.

En nuestro ejemplo de la caja del supermercado, el DCD se convierte en:


121

ILUSTRACIÓN 73. DIAGRAMA DE CLASES DE DISEÑO PARCIAL PARA EL SPDV8

Como ven en el ejemplo, el DCD es bastante simple de ver, sin embargo se ha construido a partir

de los diagramas de interacción de las realizaciones. No se incluyeron los tipos de datos ni

parámetros de métodos, porque la audiencia es académica y no nos entrega un valor agregado

más que confundirnos en el modelo de diseño.

Nótese además que el DCD que es mucho menos extenso que el modelo conceptual, porque se

basa netamente en el diseño 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 parámetro, local o global. Esto se hace con flechas punteadas que

indican cuáles son las clases que requieren esa relación. De esta forma, nuestro diagrama ejemplo

pasa a conformarse de la siguiente forma:

8 Se han omitido los tipos de datos en el diagrama de manera totalmente intencional, para la visión

completa de éste en el documento.


122

ILUSTRACIÓN 74. DIAGRAMA DE CLASES DE DISEÑO REFINADO PARA EL SPDV

En el ejemplo, aparece una visibilidad de parámetro entre Venta y Producto, ya que el método

crearLineaDeVenta requiere una instancia de Producto para ser asociada en LineaDeVenta (en

donde si está la visibilidad de atributo explícita en el DCD).

VISIBILIDAD DE ATRIBUTOS Y MÉTODOS

Hasta ahora todos los diagramas que hemos visto muestran unos pequeños signos en su

definición. Estos signos no son adornos ni tampoco es casualidad que ahí estén, sino que

representan la visibilidad que tienen los atributos y la visibilidad que tienen los métodos 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 métodos. ¿Por qué es esto?

El modificador “-” indica que el atributo o método 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 método es público, 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 métodos son públicos.

CUERPO DE LOS MÉTODOS

Por último, y opcionalmente, es posible utilizar cuerpos de código en los métodos que

especifiquen cómo se implementan con pseudocódigo o algún lenguaje en particular. Sin

embargo, debemos recordar que todo el detalle que pongamos en el DCD es para apoyar la etapa

de implementación y no debe significar mayor complejidad para los desarrolladores.

Desde el punto de vista de notación, el cuerpo de los métodos va sin la firma del método

(encabezado) y solo se describe el contenido, de la siguiente forma:


123

ILUSTRACIÓN 75. REPRESENTACIÓN EN LA CODIFICACIÓN DE LA CLASE

TEMAS COMPLEMENTARIOS

GENERALIZACIÓN

La generalización se refiere a la definición de subtipos a raíz de una definición similar respecto a

diferentes objetos. Esta definición se puede utilizar a partir del modelo conceptual, sin embargo

tampoco es tarde utilizarlo en el diseño.

Para la notación se agrega la utilización de un nuevo tipo de asociación.

La clase B es un subtipo de la clase A cuando ésta última posee

características comunes, pero la primera posee características y/u

operaciones que le permiten realizar acciones particulares para dicha

clase. En ese sentido, la definición de la clase B contiene el 100% de las

características y operaciones de A, pero no al revés.

Por ejemplo, si definimos los tipos de pago en el punto de venta, podríamos decir que existe una

“jerarquía de tipos” respecto a las clases de pagos que se pueden utilizar (PagoEnEfectivo,

PagoConTarjeta, PagoConCheque). De esta forma el modelo quedaría definido como:

ILUSTRACIÓN 76. GENERALIZACIÓN DE LOS TIPOS DE PAGO EN EL SPDV

Existe una regla simple para definir si existe una razón para definir un subtipo.


124

El subtipo tiene algún atributo particular de interés.

El subtipo tiene alguna operación particular de interés.

El subtipo se opera con un concepto diferente para el subtipo, en relación a lo relevante

de éste.

El subtipo representa alguna entidad física que se comporta en manera diferente al

supertipo.

AGREGACIÓN

La agregación 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 notación se utiliza un rombo pintado indicando la clase generadora:

La clase A agrega uno o más objetos de B.

Es importante definir la agregación cuando ésta corresponda. Por ejemplo en el caso del Punto de

Venta podemos encontrar agregación 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 relación queda así:

ILUSTRACIÓN 77. AGREGACIÓN DE PRODUCTOS EN EL SPDV

COMPOSICIÓN

La composición se utiliza cuando no existe una dependencia directa entre dos clases, pero si se

requiere tener una referencia de la otra.

Para la notación se utiliza un rombo en blanco indicando la clase que necesita tener relación:

La clase A compone uno o más objetos de B.

Al igual como lo hicimos con la agregación, la definición se debe realizar correctamente solo

cuando una de ellas requiere tener una referencia de la otra en su definición (atributos). Por

ejemplo en el caso del Punto de Venta podemos encontrar composición en el DCD entre Catalogo

y Producto, ya que los productos de la tienda siempre deben existir por si solos, pero el catálogo

es solamente el medio para que puedan acceder a l. Es por eso que la relación queda así:


125

ILUSTRACIÓN 78. COMPOSICIÓN DE LÍNEAS DE VENTA EN EL SPDV


Ahora continuaremos la realización del ejemplo del sistema electrónico de ficha de pacientes que

comenzamos a desarrollar la unidad anterior, complementando lo que se refiere a los modelos de

diseño 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 gráfica de las

funcionales (negocio) y operativa, es decir, utilizaremos un modelo de 3 capas de diseño

arquitectónico.

CAPA FUNCIONAL

La capa funcional estará compuesta de 3 componentes básicos y que son separados por su

naturaleza:

Gestión de la Ficha (creación y consulta de la ficha de un paciente)

Gestión de la Consulta Médica (ingreso de anamnesis)

Gestión de los Procedimientos (ingreso de observaciones y resultados)

Ahora bien, tanto la capa Consulta Médica como la capa Procedimiento requieren trabajar con la

ficha, por lo que también existirán algunas dependencias entre ellas:


126

ILUSTRACIÓN 79. ASOCIACIONES ENTRE LOS COMPONENTES FUNCIONALES

Como podemos ver, las interfaces que exponemos para la comunicación entre los paquetes nos

definen algunas operaciones que se realizarán en los diagramas de colaboración. 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 Médica: Todas las clases que operen con la anamnesis.

Componente Procedimiento: Todas las clases que operen con los procedimientos.

Es fácil 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 habíamos 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 diseño realizado y seguiremos manteniéndolo por separado.

Lo que nos queda ahora es exponer los servicios que van hacia la interfaz gráfica y completar el

diagrama con la capa completa:

ILUSTRACIÓN 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, podríamos (y optimizando el diagrama anterior) organizar el sistema de

la siguiente manera:


127

ILUSTRACIÓN 81. CAPAS DE INTERFAZ Y FUNCIONAL DEL SEFP

Lo que finalmente describimos es una componente gráfica por lugar donde funcionará el sistema y

relacionamos con qué servicio expuesto se comunican dichas componentes directamente. Así

podemos discriminar cómo organizar también los programas de la interfaz gráfica fácilmente.

CAPA DE DATOS

Por último, debemos también 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 sería entonces el diagrama final de componentes del sistema:

ILUSTRACIÓN 82. CAPAS DE COMPOENTES DEL SEFP


128

Como podemos notar, el Registro de Fichas es una componente que representa la interacción con

la base de datos directamente. De esta manera, cuando se desea, por ejemplo, realizar una

búsqueda de una ficha por el rut, es necesario que se obtenga la ficha desde la base (a través de

un select de la tabla respectiva).

En particular, solo se exponen 2 servicios básicos 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 DISEÑO

Para poder realizar el diseño es necesario que recordemos un artefacto que no da el primer indicio

del diseño del sistema: el diagrama de clases conceptuales:

Paciente

EspecialistaLaboratorista

Recepcionista

FichaDePaciente

Procedimiento Anamnesis


+observaciones+resultados+diagnostico

DetalleAnamnesis

+datos_inspeccion+observaciones+indicaciones+otros

posee1

1

contiene

0..*

1

+cotiene

0..*

1

es-descrita-por

1

1

es-descrita-por

1

1

crea

0..1

1

ingresa

0..1

1

ingresa

0..1

1

DetalleDeFicha

+rut+nombre+direccion+telefono+email

es-descrita-por

1 1

ILUSTRACIÓN 83. DIAGRAMA DE CLASES CONCEPTUALES DEL SEFP

En la construcción del modelo de diseño, comenzaremos con los Diagramas de Colaboración que

representan las realizaciones de las operaciones del sistema a partir de los objetos de diseño que

participan.

Para esto utilizaremos los Patrones de Diseño (GRASP y GoF) de manera de normalizar la

asignación de responsabilidades a un “buen diseño”.

Finalmente transformaremos esta información en un Diagrama de Clases de Diseño completo en

donde se describe el detalle del sistema antes de su implementación.


129


Los diagramas de colaboración 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 diseño de

responsabilidades lo realizaremos en función de cada contrato descrito en el modelo de

comportamiento.


Responsabilidad: Validar que el RUT exista dentro del catalogo de pacientes


Ref. Cruzadas: CU1

Notas: -

Excepciones: Si el RUT existe, se aborta el resto del CU

Salidas: -

Precondiciones - Exista una instancia r de tipo CatalogoDePacientes

Postcondiciones: - 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

parámetro rut.

ILUSTRACIÓN 84. CONTRATO DE LA OPERACIÓN VALIDARRUT

Lo primero que debemos buscar en este caso es qué objeto debe ser el controlador de la

operación. Es fácil ver que como no tuvimos nunca una clase que represente nada físico del

sistema, siempre utilizamos “Sistema” como tal. Así que, como estamos hablando de aplicar el

patrón 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

opción. Además, que el ejemplo es bastante “bueno” para que podamos separar las funciones en

cada ámbito de la atención médica.

Si seguimos aplicando otros patrones, por ejemplo, para validar el rut debemos identificar de

quién es la responsabilidad de conocer o mantener conocimiento de las fichas de los pacientes.

Con el patrón de experto podemos determinar que ese es el CatálogoDePacientes, que ya

teníamos identificado anteriormente. Por último, sabiendo que el experto de información de

conocer el rut de un paciente es DetalleDeFicha, y aplicando el patrón de cadena de

responsabilidad (de GoF), podemos llevar la responsabilidad desde el controlador hasta el mismo

objeto para entregar el valor del rut pidiéndole a CatalogoDePacientes, luego a FichaDePaciente y

que realice la validación si existe una ficha (esperamos respuesta negativa por supuesto).

De esta manera, el primer diagrama de colaboración quedaría como sigue:


130

ILUSTRACIÓN 85. DIAGRAMA DE COLABORACIÓN PARA VALIDARRUT

De una forma análoga, podemos revisar el segundo contrato:

Operación: CO2. ingresarDetalle(rut, nombre, direccion, fono, email)

Responsabilidad: Crear y agregar la información básica del paciente a la ficha


Ref. Cruzadas: CU1

Notas: -

Excepciones: -

Salidas: -

Precondiciones -

Postcondiciones: - Se haya creado una instancia d de tipo DetalleDeFicha

- Se hayan fijado los atributos rut, nombre, dirección,

teléfono e email con los valores entregados por parámetro.

- Se haya creado una instancia f de tipo FichaDePaciente

- Se haya asociado d a f

ILUSTRACIÓN 86. CONTRATO DE LA OPERACIÓN INGRESARDETALLE

Es fácil 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 módulo (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 más estrechamente estos objetos es FichaDePaciente,

sin embargo también es parte del contrato crear un objeto de ese tipo, así que podemos realizar

esa creación 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 información del detalle del paciente y

es DetalleDeFicha, lo que nos permite mejorar la creación de ese tipo de objetos delegándole toda

esa información a su creador (FichaDePaciente) y permitiendo que la creación se lleve a cabo en

una sola responsabilidad encapsulada.

El diagrama de colaboración quedaría así:


131

ILUSTRACIÓN 87. DIAGRAMA DE COLABORACIÓN PARA INGRESADETALLE

Notemos que en este caso particular, la existencia de la relación con el catálogo no estaba definida

en el contrato, pero la aplicación de los patrones de diseño nos permitió descubrir esta relación.

Por otro lado tampoco aparece en forma explícita el cumplimiento de la postcondición de asociar

d a f, pero por la delegación de la creación quedan asociadas esas instancias.

El siguiente contrato es:

Operación: CO3. consultar(rut)

Responsabilidad: Obtiene la información 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 parámetros rut.

ILUSTRACIÓN 88. CONTRATO DE LA OPERACIÓN 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 algún CU

particular, ya que esta operación es transversal a los CU2, CU3 y CU5.

A pesar de ello, como la naturaleza de la operación tiene que ver con obtener la información de la

ficha del paciente, podremos crear un nuevo controlador modular llamado FichaControlador, que

permite realizar las operaciones básicas de consulta o manipulación 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

realización para mejorar y aplicar este contrato en forma equivalente.

Así, las colaboraciones corregidas para aplicar esta operación también serían:

9 Note que las operaciones anteriormente analizadas también tienen que ver con la ficha, por lo que una

mejora sería juntarlas todas en este mismo controlador, quedando 3 operaciones (CO1, CO2 y CO3).


132

ILUSTRACIÓN 89. DIAGRAMA DE COLABORACIÓN PARA VALIDARRUT MODIFICADO

ILUSTRACIÓN 90. DIAGRAMA DE COLABORACIÓN PARA INGRESARDETALLE MODIFICADO

Por último, la colaboración del CO3 sería:

ILUSTRACIÓN 91. DIAGRAMA DE COLABORACIÓN PARA CONSULTAR

Como podemos ver, la naturaleza de la operación es la misma, pero la respuesta que se espera es

diferente del controlador. El siguiente contrato es:

Operación: CO4. registrarInformacion(objeto)

Responsabilidad: Registra en la ficha del paciente la información entregada en

forma de objeto.


Ref. Cruzadas: CU3, CU5

Notas: Objeto puede tomar valores de DetalleAnamnesis y


Excepciones: -

Salidas: -

Precondiciones - Exiasta una instancia d de DetalleDePaciente

Postcondiciones: - Se haya asociado objeto a d.

ILUSTRACIÓN 92. CONTRATO DE LA OPERACIÓN REGISTRARINFORMACION


133

Primero, esto tiene diferentes matices, ya que está siendo generalizada una operación que no

tendrían el mismo controlador, así que serían 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 médica. La otra será gestionada por

ProcedimientoControlador, que tiene que ver más con las operaciones realizadas durante un

procedimiento médico.

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

colaboración:

ILUSTRACIÓN 93. DIAGRAMA DE COLABORACIÓN DE REGISTRARANAMNESIS

De una manera análoga podemos realizar la operación respecto al registro del procedimiento

quedando el diagrama de la siguiente forma:

ILUSTRACIÓN 94. DIAGRAMA DE COLABORACIÓN DE REGISTRARPROCEDIMIENTO

Lo relevante de este análisis, 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 convertirán en los métodos de cada una de las clases (y las clases destino son las mismas).


134

Por último, veamos el último contrato del dominio:

Operación: CO5. cerrarAtencion(especialista)

Responsabilidad: Envía una notificación al sistema de agenda médica

indicando el término de la atención del especialista.


Ref. Cruzadas: CU7

Notas: Utiliza XML para construir la llamada al SAM.

Excepciones: -

Salidas: Un mensaje intersistemas para el SAM

Precondiciones -

Postcondiciones: -

ILUSTRACIÓN 95. CONTRATO DE LA OPERACIÓN CERRARATENCION

Como podemos ver, esta operación tiene que ver con la consulta médica (y de hecho es una

operación de secundaria, ya que es una notificación). Sin embargo, este contrato no aporta

información 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 diseño. Veamos cómo va quedando:

Con un simple paso por los diagramas de colaboración, podemos identificar las siguientes clases:

ILUSTRACIÓN 96. IDENTIFICACIÓN DE CLASES DE DISEÑO Y ATRIBUTOS

En el diagrama, además pusimos desde ya los atributos que vienen desde el diagrama de clases

conceptuales, ya que a priori sabemos que esos valores se mantendrán para el diseño.


135

El siguiente paso es completar con la información de los tipos de datos de los atributos y sus

visibilidades correctas:

ILUSTRACIÓN 97. DETALLE DE VISIBILIDAD Y TIPOS DE DATOS DE ATRIBUTOS

Es fácil detectar que la información almacenada es mayormente de texto, ya que todos los datos

generados por los especialistas médicos son de ese tipo.

Siguiendo con las definiciones aprendidas en la técnica de creación del diagrama de clases de

diseño, podemos obtener ahora los métodos de cada una de las clases a partir de los diagramas de

colaboración dibujados en la sección anterior. Así, podemos asociar los siguientes métodos

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


136

Procedimiento: crear

DetalleDeProcedimiento: crear

De esta manera, el diagrama quedaría de la siguiente forma detallado:

ILUSTRACIÓN 98. DESCRIPCIÓN DE LOS MÉTODOS DE LAS CLASES10

El paso siguiente es incorporar las asociaciones de acuerdo a la cercanía de las clases del diagrama.

Esto es bastante rápido 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 pasaría a ser de la siguiente forma:

10

Las clases fueron reorganizadas para alcanzar a ver mayor detalle en el documento.


137

ILUSTRACIÓN 99. DESCRIPCIÓN DE ASOCIACIONES ENTRE LAS CLASES

Como podemos ver incorporamos también el concepto de composición en varias de esas

asociaciones, por el hecho de ser creadores de otros objetos.

Observemos por un momento la relación entre Procedimiento – DetalleDeProcedimiento y

Anamnesis – DetalleDeAnamnesis. Podemos notar una semejanza con la caja del supermercado,

porque en este caso Procedimiento y Anamnesis están jugando el papel de “línea 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 generalización en el diagrama, incorporaremos la clase

RegistroDeFicha (que reemplazará Procedimiento y Anamnesis como “línea de venta”) y una clase

DetalleDeRegistro que será la superclase que incorporará ambos tipos de registros.

Además, 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 más detalle y podemos mostrar

finalmente el siguiente diagrama de clases de diseño como una primera versión de nuestro SEFP:


138

ILUSTRACIÓN 100. DIAGRAMA DE CLASES DE DISEÑO DEL SEFP


139

UNIDAD IV: INTRODUCCIÓN A LA

IMPLEMENTACIÓN

Gracias a la metodología UP planteada, la construcción del software se torna un

poco más sencilla, ya que con el diagrama de clases de diseño, más las

especificaciones que se encontraron en las realizaciones a través de la visibilidad y

los mensajes definidos, nos permiten al menos tener una estructura rápida de

implementar. En este capítulo veremos una técnica utilizada principalmente por

las herramientas CASE en el ámbito para transformar estos modelos en “códigos”

de programas.


140

FUNDAMENTOS DE LA IMPLEMENTACIÓN DEL SOFTWARE

La implementación del software es la parte en donde se concretan los diseños realizados y se

codifica gran parte del sistema final que se está definiendo.

CODIFICACIÓN DE CALIDAD

Los especialistas deben perseguir la obtención de “programas” de calidad. Para ello se establece

una serie de factores que determinan la calidad de un programa:

Corrección: Un programa es correcto si hace lo que debe hacer tal y como se estableció en

el análisis y diseño.

Claridad: Es muy importante que el programa sea lo más claro y legible posible, para

facilitar así su desarrollo y posterior mantenimiento.

Eficiencia: Se trata de que el programa, además 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 aquélla en la que se elaboró.

ESTÁNDARES DE CODIFICACIÓN

Los estándares de codificación se refieren a un conjunto de reglas y lineamientos que se usan al

escribir los códigos fuentes de un software. El uso de un estándar particular ayuda a los

programadores a leer y entender el código evitando los errores de la mejor manera.

Un buen estilo de programación (o estándar) es difícil de definir ya que depende del lenguaje de

programación seleccionado, sin embargo existen algunos aspectos comunes a ellos que ayudan a

tener un estándar definido:

Apariencia del Código: Los estándares apuntan a que el código debe ser de fácil

entendimiento humano. De esta forma se pueden utilizar algunas técnicas básicas como

indentación, alineamiento vertical, espaciado y tabuladores.

Nombrado de Variables: Una buena selección de nombres de variables indica que ellas

deben ser nombradas según su función. La utilización de nombres deficientes de variables

solo complican el entendimiento del código fuente.

Valores Booleanos en Estructuras de Decisión: Es mejor siempre evitar la utilización 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 también es

parte de un buen estilo de programación.


141

HERRAMIENTAS CASE

Las CASE-Tools o Herramientas CASE (Computer Aided Software Engineering, Ingeniería de

Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar

la productividad en el desarrollo de software reduciendo el costo de las mismas en términos 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 diseño del proyecto, calculo de costes,

implementación de parte del código automáticamente con el diseño dado, compilación

automática, documentación o detección de errores entre otras.

A pesar de que las CASE-Tools nacieron en los años 70, actualmente siguen siendo una gran ayuda

en el ámbito de la ingeniería de software y sobretodo en etapas menos técnicas como el análisis y

diseño.


El modelo de implementación define el mapeo que debemos hacer del diseño de software

realizado a través de los artefactos del UP con la codificación. De esta manera podemos definirlo

en dos partes:

Definición de las Clases (a partir de los DCD)

Definición de los Métodos (a partir de las colaboraciones)

A continuación veremos algunos aspectos básicos con los cuales debe trabajar el arquitecto antes

de llegar a obtener un diseño completo.

CONCEPTOS BÁSICOS


CÓDIGO

Podemos definir que:

EL CÓDIGO ES LA SINTAXIS DE LOS PROGRAMAS, EN UN LENGUAJE

DE MÁQUINA PARTICULAR, Y QUE REPRESENTAN EL DISEÑO

ESPECIFICADO.

Lo que estamos definiendo tan sencillamente es que utilizaremos “código” para especificar la

implementación.

En este caso, en lenguaje de programación que usaremos para los ejemplos será Java por su

orientación al objeto y pertinencia con la carrera.


142


En particular, en este modelo no utilizaremos algún artefacto UML en específico, sin embargo

definiremos como artefactos dos productos que utilizaremos en el curso:

Diagrama de Clases de Implementación: Diagrama complementario que especifica detalle

técnico en el diagrama de clases de diseño (como normalización de tipos de datos al

lenguaje de programación) e incorpora información de código para las clases.

Estructura de Clases: Estructura de programas que se obtiene de la transformación del

diagrama de clases de implementación en el lenguaje de programación seleccionado.



El proceso de desarrollo de ambos artefactos se reduce en realidad a una sola técnica, sin

embargo la especificaremos a continuación de manera segmentada para un mejor entendimiento

de ellos.

DIAGRAMA DE CLASES DE IMPLEMENTACIÓN

Tal como ya habíamos mencionado, el artefacto “cumbre” de la fase de diseño es el que

conocemos como Diagrama de Clases de Diseño (DCD), pero solo lo mencionamos. Ahora tenemos

la oportunidad de justificarlo mostrando cómo 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

implementación:

ILUSTRACIÓN 101. DIAGRAMA DE CLASES DE DISEÑO DEL SPDV


143

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 programación

seleccionado. Pensemos en Java, entonces el diagrama anterior quedaría transformado a:

ILUSTRACIÓN 102. DIAGRAMA DE CLASES DE NORMALIZADO AL LENGUAJE JAVA

Ahora que ya lo tenemos normalizado, debemos saber de dónde vamos sacando los códigos

respectivos de cada clase. La regla es siempre comenzar desde la menos acoplada (más específica)

a la más acoplada. En el ejemplo, podemos definir el siguiente orden de acoplamiento:

Producto

Pago

LíneaDeVenta

Catalogo

Venta

CajaControlador

Luego de saber el orden de implementación, se debe comenzar poniendo los códigos de las clases

desde la definición que ya se ha encontrado en el DCD, lo que llamaremos atributos y métodos

simples. De esta manera, la clase se va construyendo a partir directamente de la definición que

dice el DCD.

Por ejemplo, tomemos LineaDeVenta para comenzar la definición:


144

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() { }

}

LineaDeVenta

-cantidad: short

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

ILUSTRACIÓN 103. DEFINICIÓN DE CÓDIGO PARA LA CLASE LINEADEVENTA

Esto lo debemos hacer para todas las clases del DCD, de manera que tenemos una primera

estructura básica 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 raíz de la relación que tienen las clases. De esta

manera, cada vez que veamos una “asociación” en el diagrama de clases, entonces estaremos

pensando que en la implementación debemos “referenciar” la clase dependiente a través de un

atributo.

Por ejemplo, en la relación entre LineaDeVenta y Producto podemos obtener claramente un

atributo de referencia. Este se ve en la clase Linea de Venta:


/* 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() { }

}

LineaDeVenta

-cantidad: short


-p

1

1

Producto

-codigo: long-glosa: String-precio: double

+getCodigo(): long+getPrecio(): double

ILUSTRACIÓN 104. IDENTIFICACIÓN DEL ATRIBUTO DE REFERENCIA DE LINEADEVENTA

Para este caso lo estamos haciendo a partir de una composición. En el caso del lenguaje Java,

tanto la composición como la agregación se representan de la misma forma, sin embargo, cuando

estemos utilizando lenguajes cuya representación se torna diferente, entonces debemos

preocuparnos de si hablamos de composición y no de agregación.


145

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 relación. De

esta forma, ese “papel” debe ser usado como nombre del objeto de referencia.

Otra consideración 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 código nos vemos con la complicación 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 relación 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

definición quedaría de la siguiente forma:

Venta

-fecha: Date

+new(fecha: Date): Venta-setFecha(fecha: Date)+crearLDV(p: Producto, cant: short)+obtenerTotal(): double+crearPago(monto: double, tipo: byte)

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) { }

}

-ldv1..*

1

LineaDeVenta

-cantidad: short


ILUSTRACIÓN 105. ESPECIFICANDO ATRIBUTOS DEL CONTENEDOR VENTA

En este ejemplo, podemos ver que quedó puesto un objeto Vector llamado ldv que,

conceptualmente, no es más 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 través de esta técnica es posible realizar es describir los métodos que se

encontraron como mensajes y responsabilidades en los diagramas de colaboración. De esta

manera, podemos escribir los cuerpos de los métodos (al menos en parte) mirando estos

diagramas.

Veamos el ejemplo de la operación agregarProducto de CajaControlador. Su diagrama de

colaboración (parte de él) sería:


146

ILUSTRACIÓN 106. COLABORACIÓN PARA AGREGARPRODUCTO EN LA VENTA ACTUAL

Nótese que los mensajes que salen de CajaControlador están representando parte del cuerpo del

método agregarProducto de CajaControlador. Por lo tanto, si revisamos la secuencia y vamos

agregando las llamadas respectivas a la definición de la clase, tenemos:

Catalogo

+buscar(cod: long): Producto

CajaControlador

+iniciarVenta()+agregarProducto(cod: long, cant: short)+registrarPago(monto: double, tipo: byte)

Venta

-fecha: Date

+new(fecha: Date): Venta-setFecha(fecha: Date)+crearLDV(p: Producto, cant: short)+obtenerTotal(): double+crearPago(monto: double, tipo: byte)

-v0..*

1

-c

11

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) {}

}

ILUSTRACIÓN 107. ESPECIFICACIÓN DEL CUERPO DE LA OPERACIÓN AGREGARPRODUCTO

Como se puede ver acá aparecen directamente los métodos que ya definimos en cada clase y

hasta el orden de llamada relativa por supuesto a la responsabilidad en cuestión. En este caso

ingresarProducto queda aparentemente definido en su totalidad, por lo tanto no requiere agregar

nada más para que sea un procedimiento programado.

Finalmente, con esta documentación tendremos un gran diagrama de clases con comentarios que

especifican cada clase de diseño como si fuera una fuente de información técnica para la

programación.


147

ILUSTRACIÓN 108. DIAGRAMA DE CLASES DE IMPLEMENTACIÓN PARA EL SPDV

ESTRUCTURA DEL CÓDIGO

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 serían las clases formales, pero como

ejercicio, en este caso, lo haremos “a mano”.

La técnica para escribir el código es muy sencilla: basta recorrer el diagrama de clases de

implementación y comenzar a describir las clases con el detalle esperado.

El resultado entonces de realizar este proceso completo para el caso del SPDV sería 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);

}

}


148

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;


149

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 métodos el

detalle y estructuras de control necesarias que permitan que el sistema opere de manera efectiva

y correcta según las especificaciones de requisitos realizadas al principio del curso.


Ahora completaremos la realización del ejemplo del sistema electrónico de fichas de pacientes,

complementando lo que se refiere al modelo de implementación del sistema.


En este modelo especificaremos solo la estructura de clases a partir del DCD y usando Java.



150

Describiremos el diagrama de clases de implementación, utilizando el DCD de la unidad anterior.

Para ello entonces pasaremos por los pasos básicos indicados en la técnica de desarrollo del

modelo respectivo.

Primero, comencemos normalizando los tipos de datos al lenguaje elegido (Java). El diagrama de

clases quedaría algo parecido a lo siguiente:

ILUSTRACIÓN 109. DIAGRAMA DE CLASES DE DISEÑO CON TIPOS DE DATOS JAVA DEL SEFP

Luego de realizado esto, se van describiendo las clases a través de anotaciones en el diagrama

considerando no solo los atributos explícitos, sino que también operaciones complejas y atributos

de asociación.

Para el caso de las asociaciones múltiples 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 número de elementos que finalmente vamos a registrar.

De esta manera, tendremos un diagram parecido a este:


151

ILUSTRACIÓN 110. DIAGRAMA DE CLASES DE IMPLEMENTACIÓN COMPLETO DEL SEFP

El siguiente paso (que aparece en la técnica vista en este capítulo) indica incorporar lógica de

programación en el diagrama, sin embargo, dada la complejidad de éste, vamos a optar por

escribir el código (estructura de clases) a partir de lo ya obtenido, y luego incorporar lógica

programática.

ESTRUCTURA DE CLASES

La estructura obtenida corresponde a las clases, con sus atributos y las firmas de todos los

métodos identificados. Sin embargo, vamos a aprovechar de incorporar lógica en los métodos de

las clases según corresponda.

A continuación el listado de las clases desde las menos acopladas a las más 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;

}


152

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;

}

}


153

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);

}

}


154

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);

}

}


155

ANEXOS


156

PLANTILLA DE DOCUMENTACIÓN DEL A/DOO

A continuación se presenta una estructura para documentar el proceso de análisis y desarrollo

orientado al objeto planteado en este documento. Es importante recordar que esta

documentación se realizar para cada iteración del proceso de desarrollo, por lo que es importante

priorizar las funciones a abordar en cada una de ellas.

ESPECIFICACIÓN DE REQUISITOS

En esta sección se describe la visión funcional del sistema a la luz de los requerimientos

expresados por el cliente final.

IDENTIFICACIÓN DEL SISTEMA

El sistema se describe de la siguiente forma:

Nombre del Sistema:

Panorama:

Clientes:

Metas:

ESPECIFICACIÓN DE FUNCIONES

La especificación funcional del sistema se detalla a través de las siguientes funciones:

# Ref:

Función:

Descripción:

Categoría:



En esta sección se describen los casos de uso, su detalle y la relación que tienen con las funciones

determinadas en la sección anterior. Es importante incorporar el detalle de cada iteración

priorizado de manera de mantener coherencia con lo que se realize a través del proceso de

desarrollo complete.


CASOS DE USO DE ALTO NIVEL

Los casos de uso encontrados en esta iteración son los siguientes:

Caso de Uso:

Actores:

Tipo:

Descripción:

Es importante destacar que solo los CU principales serán expandidos a continuación.


157

CASOS DE USO EXPANDIDOS

El detalle de los casos de uso identificados es el siguiente:

Caso de Uso:

Actores:

Propósito:

Resumen:

Tipo:

Ref. Cruzadas:

Curso Normal


A continuación se muestra gráficamente la relación de los actores con los casos de uso

especificados.

<INSERTAR DIAGRAMA>

GLOSARIO

En esta sección se describen los conceptos más importantes del dominio y que impactan en su

entendimiento.


MODELO DE DOMINIO

En esta sección se describen los artefactos que muestran la visión 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 sección se describen los artefactos que describen el comportamiento del sistema.


158


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 través de los siguientes contraltos:


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 sección se describen las decisiones de la arquitectura que afectan a la organización de los

programas finales.


El diagrama que define la distribución de componentes es el siguiente:

<INSERTAR DIAGRAMA>

MODELO DE DISEÑO

En esta sección se describe en detalle el diseño del sistema a partir de las operaciones de éste y

completando con una vision técnica de las clases de diseño.


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>


159


En esta sección se describen las labores de preparación de la codificación.


El diagrama de clases normalizado y preparado para la codificación es:

<INSERTAR DIAGRAMA>

ESTRUCTURA DE CLASES

La estructura básica de clases que se deriva del diseño es:

<INSERTAR ESTRUCTURA DE CLASES>


160

GUÍA DE USO DE STARUML

Para complementar este apunte, presentamos una guía rápida de uso de StarUML, que es el

software con el cual fueron desarrollados todos los modelos gráficos que aquí se describen,

incluyendo no solo la utilización “formal”, sino que también el uso de trucos que nos ayuden a

producir modelos de acuerdo a las técnicas y recomendaciones aquí planteadas.

Además, la idea central es permitir al alumno aprender a utilizar una herramienta CASE de acceso

liberado (al menos hasta la creación de este documento) tanto a nivel académico como en su

desarrollo profesional.

INTRODUCCIÓN A LAS HERRAMIENTAS CASE

Las CASE-Tools o Herramientas CASE (Computer Aided Software Engineering, Ingeniería de

Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar

la productividad en el desarrollo de software reduciendo el costo de las mismas en términos 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 diseño del proyecto, calculo de costes,

implementación de parte del código automáticamente con el diseño dado, compilación

automática, documentación o detección de errores entre otras.

HISTORIA

Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que

analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos

generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la

aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statemente

Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos

informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y

trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM

había 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 más

específicas para cada fase del ciclo de vida del software.

OBJETIVOS

Los objetivos que buscan resolver las herramientas CASE son:


161

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 informáticos.

Mejorar la planificación de un proyecto

Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la

búsqueda de soluciones para los requisitos.

Automatizar el desarrollo del software, la documentación, la generación de código, las

pruebas de errores y la gestión del proyecto.

Ayudar a la reutilización del software, portabilidad y estandarización de la documentación

Gestionar globalmente todas las fases de desarrollo de software con una misma

herramienta.

Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

CLASIFICACIÓN DE LAS HERRAMIENTAS

Las herramientas CASE no tienen una sola clasificación. De acuerdo a diferentes características, 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 clasificación por plataforma indica sobre qué arquitectura física trabajan (sistema operativo,

hardware, etc). En particular, la clasificación tradicional al igual que cualquier lenguaje es la

siguiente:

Multiplataforma

Windows

Unix/Linux (y sus diferentes sabores)

MacOS

Otros


162

También existen software compatibles entre plataformas, pero definitivamente depende un poco

del fabricante y de la tecnología que utilicen para hacer cada herramienta.

FASES DEL CICLO DE VIDA DEL SOFTWARE

Esta es la clasificación más habitual de las herramientas, y se ha definido en 3 niveles:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de

requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la

aplicación.

Lower CASE (L-CASE), herramientas que semiautomatizan la generación de código, crean

programas de detección de errores, soportan la depuración de programas y pruebas.

Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las

herramientas de desarrollo rápido de aplicaciones11.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación

excluyente entre sí, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo

software, desde análisis hasta implementación.

MetaCASE, herramientas que permiten la definición de nuestra propia técnica 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 definiéramos 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 gestión de proyectos y gestión de la

configuración.

ARQUITECTURAS PRODUCIDAS

En esta clasificación se han definido los siguientes tipos de arquitectura producida:

Monolítica. Donde el software se estructura en grupos funcionales muy acoplados.

Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes

independientes pero sin reparto claro de funciones.

Arquitectura de Tres Capas. Especialización 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

presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el

11

Ver http://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicaciones

http://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicaciones


163

negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación

con la siguiente.

Otras arquitecturas menos utilizadas incluyen la de pipeline, entre pares, en pizarra, orientada a

servicios y máquinas virtuales.

FUNCIONALIDADES

De acuerdo a sus funcionalidades, las herramientas se pueden agrupar de la siguiente forma:

Herramientas de generación semiautomática de código.

Editores UML.

Herramientas de Refactorización de código.

Herramientas de mantenimiento como los sistemas de control de versiones.

UML CASE-TOOL: STARUML

FICHA TÉCNICA

Nombre: StarUML

Empresa: Ninguna (Proyecto Open Source)

Versión Actual: 5.0

Tipo de Licencia: Open Source

Costos: Ninguno

Plataforma: Microsoft Windows

Idiomas: Inglés

Página Web: http://staruml.sourceforge.net/

DESCRIPCIÓN

Es un proyecto Open Source, por lo que es de descarga gratuita. Su última versión liberada a la

fecha de construcción de este apunte es la 5.0 y posee soporto para la notación 2.0 de UML. Están

continuamente en recolección de contribuidores quienes son premiados utilizando sus nombres

como valores aleatorios cuando se crean objetos.

Cada proyecto puede ser utilizado con estándares de diferente naturaleza (estilo Rational, UML

estándar, MDA, COM-Compatible, o personalizable).

Además, posee capacidad de generación de códigos en C, C++, C#, Java, Visual Basic, VB.Net,

Delphi, JScript, VBScript, etc.

http://staruml.sourceforge.net/


164

FUNCIONALIDADES

A continuación veremos las diferentes funcionalidades para trabajar con la herramienta.

CREACIÓN 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 organización de

modelos o vistas que deben ser completadas con los artefactos de UML por el arquitecto.

ILUSTRACIÓN 111. VENTANA DE INICIO DE STARUML

Los estilos de modelamiento disponible en la versión 5.0 son:

Aproximación Estándar

Aproximación Rational

Aproximación de Componentes UML

Aproximación de Modelo 4+1

Aproximación Personalizada

El estilo utilizado para el desarrollo de los artefactos presentados en este apunte fue Rational, ya

que es el más cercano al proceso de desarrollo personalizado que se utilizó, sin embargo, no se

descarta crear una aproximación especial adecuada para el curso en el futuro12.

Además, independientemente el tipo de aproximación, 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.


165

Veamos en detalle cada aproximación para entender las secciones siguientes:

APROXIMACIÓN ESTÁNDAR

La aproximación estándar 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 interacción del sistema desde el punto de vista funcional a través

de la utilización del artefacto del mismo nombre.

Modelo de Análisis: El centro de este modelo es el Diagrama de Clases, en el cual se

define una primera aproximación de la estructura de clases de diseño del sistema.

Modelo de Diseño: El centro de este modelo es el mismo Diagrama de Clases, sin

embargo, la utilización es para refinar la información preparando la implementación.

Modelo de Implementación: El centro de este modelo es el Diagrama de Componentes,

en donde se pueden organizar las clases de diseño modularmente según 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 físicas a través de las

cuales será “instalado” el sistema en la organización del cliente final.

APROXIMACIÓN RATIONAL

La aproximación 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 descripción funcional del proyecto

guiado a través de los Casos de Uso del sistema. Su centro es el Diagrama de Casos de Uso.

Vista Lógica: Esta vista pretende mostrar la visión tanto de negocio como de

comportamiento del sistema desde el punto de vista lógico (no físico). Su centro es el

Diagrama de Clases (conceptuales).

Vista de Componentes: Esta vista pretende mostrar la visión física 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 (instalación)

del sistema de acuerdo a las necesidades modulares y funcionales del problema. Su centro

es el Diagrama de Despliegue.

APROXIMACIÓN DE COMPONENTES UML

La aproximación de componentes UML está basada en la definición original del lenguaje y organiza

el proyecto de acuerdo a 2 ámbitos:

13

The Three Amigos: Booch, Jacobson y Rumbaugh, autores también del lenguaje de modelamiento UML.


166

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

análisis 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

análisis y diseño del sistema como tal. Incorpora por defecto los modelos de Tipos del

Negocio, Especificación de Interfaz, Especificación y Arquitectura de Componentes.

APROXIMACIÓN DE MODELO 4+1

La aproximación 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 interacción de objetos y

procesos de los casos de uso que definen la arquitectura 4+1 (Diagramas de Casos de Uso).

Vista Lógica: En este ámbito se describen los diagramas que representan lógica del

negocio y del sistema (Diagramas de Comunicación, Clases Conceptuales y Secuencia).

Vista de Desarrollo: En este ámbito se describen los diagramas que representan la vista

del programador y de administración del software (Diagramas de Componentes y

Paquetes).

Vista de Procesos: En este ámbito se describen los diagramas que representan los

aspectos dinámicos del sistema, a nivel de procesos y comportamiento de éste (Diagramas

de Actividades).

Vista Física: En este ámbito se describen los diagramas que representan la visión del

ingeniero en sistemas sobre las capas físicas y la comunicación entre las componentes

(Diagramas de Despliegue).

APROXIMACIÓN PERSONALIZADA

La aproximación personalizada no define ámbitos ni modelos, sino que un proyecto vacío dejando

el trabajo de organización del proyecto al arquitecto. Es muy útil cuando el arquitecto no se siente

cómodo con ninguna de las otras aproximaciones disponibles.

ANATOMÍA DE LA HERRAMIENTA

StarUML posee diferentes regiones en donde se muestra información. Estas regiones son las

siguientes:

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.

14

http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model


167

Explorador del Modelo (Model Explorer): Espacio para ver la organización del proyecto a

partir de la aproximación 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.

Documentación (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 dinámica que muestra los elementos de la

notación del tipo de diagrama seleccionado.

Salidas (Output): Espacio que muestra la bitácora de cambios que se van realizando

durante la modificación del proyecto.

La presentación de la herramienta es la siguiente:

ILUSTRACIÓN 112. VENTANA PRINCIPAL DE STARUML


168

CREACIÓN DE DIAGRAMAS

Para crear un diagrama, éste debe ser incorporado a algún ámbito del proyecto. Para ello se debe

seleccionar el ámbito del proyecto, con el menú “Model” o con el botón derecho, hacer clic en

“Add Diagram” y seleccionar el tipo de diagrama a realizar.

ILUSTRACIÓN 113. AGREGANDO UN DIAGRAMA EN STARUML

El resultado de esta operación 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. También existe un cambio en la barra de herramientas (Toolbox), la cual

cambia según el tipo de diagrama seleccionado.

TIPOS DE DIAGRAMAS

Los diagramas básicos que vienen con la versión 5.0 son los siguientes:

Diagrama de Clases

Diagrama de Casos de Uso

Diagramas de Secuencia y Colaboración (con roles y sin roles)

Diagrama de Estados

Diagrama de Actividades

Diagrama de Componentes

Diagrama de Despliegue

Diagrama de Estructura Compuesta

Diagrama de Robustez


169

GENERACIÓN DE CÓDIGO FUENTE

Para poder generar código fuente es importante incorporar al proyecto el lenguaje en el cual se

desea generar el código. Esto se realiza a través del menú “Model” > “Profiles”.

ILUSTRACIÓN 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 botón “Include >” quedarían automáticamente incorporados.

Cabe destacar que la generación de código se realiza a partir de las clases de diseño del sistema,

por lo que es importante que se utilicen tipos de datos acordes al lenguaje en su definición.

Si ambos factores son cumplidos, se puede generar el código 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:

ILUSTRACIÓN 115. VENTANA DEL PASO 1 DE GENERACIÓN DE CÓDIGO DE STARUML


170

Es necesario seleccionar la vista, modelo o paquete del proyecto que contiene la definición de las

clases de diseño, y luego presionar “Next >”.


Luego se requiere seleccionar las clases o paquetes de clases que van a ser utilizadas para generar

el código. Como la definición de las clases queda asociada al elemento, los atributos y operaciones

de las clases también se ven amarradas a dicha definición.


Además, se debe seleccionar la carpeta en donde se desea guardar el código y presionar la acción

“Next >”.


171


Finalmente, es necesario fijar algunas opciones de generación y estilo, finalizando el proceso con

la acción “Next >”, lo que comenzará a generar el código. Una vez iniciado el proceso de

generación, StarUML construirá las clases .java de todos los elementos seleccionados en el paso 2.

RECOMENDACIONES Y BUENAS PRÁCTICAS

Para completar esa guía, se puede decir que:

Es importante acomodar la aproximación al modelo más cómodo que tiene el arquitecto

en cuestión. Lo más probable sea que alguna de las aproximaciones sea suficiente, pero no

necesariamente exacto, así que se deberá ajustar dicho modelo al que más le acomode

siempre.

StarUML no apoya el proceso de generación de los diagramas, sino que solo los permite

dibujar, lo que por supuesto es complejo para arquitectos poco experimentados. Por esta

razón es necesario que el arquitecto conozca su propia metodología 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.


172

BIBLIOGRAFÍA

El material principal utilizado para estos apuntes es:

UML y Patrones Craig Larman Editorial Pearson Education

Además, 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 Editorial Pearson Education

UML gota a gota Martin Fowler Editorial Addison Wesley

Ingeniería de Software Orientado a Objetos Bertrand Meyer Editorial Prentice Hall

Utilización de UML en Ingeniería del Software con Objetos y Componentes Perdita Stevens, Rob Pooley Editorial Addison Wesley

Ingeniería de Software Orientado a Objetos Bernd Bruegge – Allen Dutoit Editorial Pearson Education

The Unified Modeling Language Reference Manual Grady Booch, James Rumbaugh, Ivar Jacobson Editorial Addison Wesley

Guía del Usuario del Lenguaje Unificado de Modelado UML Grady Booch, James Rumbaugh, Ivar Jacobson Editorial Addison Wesley

Utilización de UML en Ingeniería de Software Perdita Stevens Editorial Prentice Hall

Learning UML 2.0 Kim Hamilton, Russell Miles Editorial O’Really

Manual de UML Paul Kimmel Editorial Mc Graw Hill


173

Object Oriented Analysis and Design Mike O’Docherty Editorial Prentice Hall

Diseño Orientado a Objetos con UML Raúl Alarcón Grupo Eidos

Orientación al Objeto: Conceptos, Terminología y Lenguajes Miguel Ángel Alarcón http://www.javahispano.org

http://www.javahispano.org/


174

TABLA DE ILUSTRACIONES

Ilustración 1. Notación del Modelo de Objetos de OMT .................................................................. 19

Ilustración 2. Notación del Modelo Dinámico ................................................................................... 20

Ilustración 3. Notación del Modelo Funcional .................................................................................. 22

Ilustración 4. Iteraciones del Proceso Unificado de Desarrollo ........................................................ 23

Ilustración 5. Fases del Proceso Unificado de Desarrollo ................................................................. 25

Ilustración 6. Carga de Trabajo por Disciplina en el Proceso Unificado de Desarrollo ..................... 27

Ilustración 7. Metamodelos Aplicados a la Metodología .................................................................. 30

Ilustración 8. Plantilla de Especificación de Funciones ..................................................................... 40

Ilustración 9. Continuación de la Plantilla de Especificación de Funciones ...................................... 41

Ilustración 10. Plantilla de Especificación de Funciones para el SPDV.............................................. 42

Ilustración 11. Tabla de Identificación de Actores y Objetivos ......................................................... 46

Ilustración 12. Documento de Especificación de Caso de Uso de Alto Nivel .................................... 46

Ilustración 13. Documento de Especificación de Caso de Uso Expandida ........................................ 47

Ilustración 14. Notación de los Diagramas de Casos de Uso ............................................................ 48

Ilustración 15. Plantilla de Especificación de Casos de Uso y Glosario ............................................. 49

Ilustración 16. Diagrama de Casos de Uso del SPDV ......................................................................... 50

Ilustración 17. Documento del Glosario ............................................................................................ 50

Ilustración 18. Glosario para el Problema del SPDV ......................................................................... 51

Ilustración 19.Notación de los Diagramas de Actividades ................................................................ 54

Ilustración 20. Diagrama de Casos de Uso del SPDV ......................................................................... 54

Ilustración 21. Diagrama de Actividades para el SPDV ..................................................................... 55

Ilustración 22.Tabla de Identificación de Clases conceptuales según Categorías ............................ 57

Ilustración 23.Análisis de Clases conceptuales por Frases Nominales.............................................. 58

Ilustración 24.Ejemplo de Asociación de Clases conceptuales ......................................................... 59

Ilustración 25.Tabla de Clasificación de Multiplicidad ...................................................................... 60


175

Ilustración 26.Notación de los Diagramas de Clases Conceptuales .................................................. 62

Ilustración 27.Diagrama de Actividades del SPDV ............................................................................ 63

Ilustración 28.Diagrama de Clases conceptuales del SPDV............................................................... 63

Ilustración 29. Notación de los Diagramas de Secuencia .................................................................. 66

Ilustración 30. Mensaje de Creación de Objeto ................................................................................ 66

Ilustración 31. Mensaje de Autodelegación ...................................................................................... 67

Ilustración 32. Diagrama de Secuencia para el proceso de venta (sin pago) del TPDV. ................... 67

Ilustración 33. Notación para los Contratos de las Operaciones ...................................................... 68

Ilustración 34. Diagrama de Secuencia con las operaciones de la Venta ......................................... 69

Ilustración 35. Contrato para la Operación ingresarProducto del TPDV .......................................... 70

Ilustración 36. Notación de los Diagramas de Estado ....................................................................... 72

Ilustración 37. Diagrama de Estados para el objeto venta del TPDV ................................................ 73

Ilustración 38. Especificación de Funciones del SEFP ....................................................................... 76

Ilustración 39. Tabla de Actores y Objetivos del SEFP ...................................................................... 76

Ilustración 40. Especificación de Casos de Uso de Alto Nivel para el SEFP ....................................... 77

Ilustración 41. Especificación de CU Expandidos para el caso SEFP ................................................. 79

Ilustración 42. Diagrama de Casos de Uso del SEFP .......................................................................... 80

Ilustración 43. Glosario para el SEFP ................................................................................................. 80

Ilustración 44. Diagrama de Actividades del SEFP ............................................................................ 82

Ilustración 45. Identificación de Clases conceptuales según Categorías para el SEFP ...................... 83

Ilustración 46. Frases Nominales para Escenarios del SEFP .............................................................. 84

Ilustración 47. Diagrama de Clases conceptuales del SEFP ............................................................... 85

Ilustración 48. Diagrama de Secuencia para el CU1. Registrar Paciente .......................................... 86

Ilustración 49. Diagrama de Secuencia para el CU2. Consultar Historial .......................................... 86

Ilustración 50. Diagrama de Secuencia para el CU3. Registrar Anamnesis ....................................... 87

Ilustración 51. Diagrama de Secuencia para CU5. Registrar Resultado de Procedimiento .............. 88

Ilustración 52. Diagrama de Secuencia para el CU7. Actualizar Agenda Médica .............................. 88


176

Ilustración 53. Contratos de las Operaciones del SEFP ..................................................................... 90

Ilustración 54. Diagrama de Estados para FichaDePaciente del SEFP............................................... 90

Ilustración 55. Tabla de Factores de la Arquitectura ........................................................................ 96

Ilustración 56. Tabla de Factores de la Arquitectura del SPDV ......................................................... 96

Ilustración 57. Tabla de Decisiones de la Arquitectura ..................................................................... 97

Ilustración 58. Notación de los Diagramas de Componentes ........................................................... 97

Ilustración 59. Diagrama de Componentes del SPDV ....................................................................... 98

Ilustración 60. Notación de los Diagramas de Colaboración .......................................................... 102

Ilustración 61. Diagrama de Colaboración de Ingresar Producto para TPDV ................................. 103

Ilustración 62. Contrato de Operación ingresar Producto del SPDV ............................................... 105

Ilustración 63. Delegación de Responsabilidad de Experto de Información ................................... 106

Ilustración 64. Delegación de Responsabilidad de Creador de Instancias ...................................... 107

Ilustración 65. Identificación del Controlador de las Operaciones del Sistema.............................. 109

Ilustración 66. Notación para los Diagramas de Clases de Diseño.................................................. 117

Ilustración 67. Asociación a nivel de Clases Conceptuales ............................................................. 117

Ilustración 68. Asociación a nivel de Clases de Diseño ................................................................... 117

Ilustración 69. Identificación de las Clases de Diseño ..................................................................... 118

Ilustración 70. Identificación de un Método a partir de una Colaboración .................................... 118

Ilustración 71. Identificación de Métodos de las Clases ................................................................. 119

Ilustración 72. Agregando Asociaciones con Navegabilidad ........................................................... 120

Ilustración 73. Diagrama de Clases de Diseño Parcial para el SPDV ............................................... 121

Ilustración 74. Diagrama de Clases de Diseño Refinado para el SPDV ........................................... 122

Ilustración 75. Representación en la Codificación de la Clase ........................................................ 123

Ilustración 76. Generalización de los Tipos de Pago en el SPDV ..................................................... 123

Ilustración 77. Agregación de Productos en el SPDV ...................................................................... 124

Ilustración 78. Composición de Líneas de Venta en el SPDV .......................................................... 125

Ilustración 79. Asociaciones entre los Componentes Funcionales ................................................. 126


177

Ilustración 80. Capa Funcional del SEFP .......................................................................................... 126

Ilustración 81. Capas de Interfaz y Funcional del SEFP ................................................................... 127

Ilustración 82. Capas de Compoentes del SEFP .............................................................................. 127

Ilustración 83. Diagrama de Clases conceptuales del SEFP ............................................................. 128

Ilustración 84. Contrato de la Operación validarRut ....................................................................... 129

Ilustración 85. Diagrama de Colaboración para validarRut ............................................................ 130

Ilustración 86. Contrato de la Operación ingresarDetalle............................................................... 130

Ilustración 87. Diagrama de Colaboración para ingresaDetalle ...................................................... 131

Ilustración 88. Contrato de la Operación consultar ........................................................................ 131

Ilustración 89. Diagrama de Colaboración para validarRut modificado ......................................... 132

Ilustración 90. Diagrama de Colaboración para ingresarDetalle Modificado ................................. 132

Ilustración 91. Diagrama de Colaboración para consultar .............................................................. 132

Ilustración 92. Contrato de la Operación registrarInformacion ...................................................... 132

Ilustración 93. Diagrama de Colaboración de registrarAnamnesis ................................................. 133

Ilustración 94. Diagrama de Colaboración de registrarProcedimiento ........................................... 133

Ilustración 95. Contrato de la Operación cerrarAtencion ............................................................... 134

Ilustración 96. Identificación de Clases de Diseño y Atributos ....................................................... 134

Ilustración 97. Detalle de Visibilidad y Tipos de Datos de Atributos .............................................. 135

Ilustración 98. Descripción de los Métodos de las Clases ............................................................... 136

Ilustración 99. Descripción de Asociaciones entre las clases .......................................................... 137

Ilustración 100. Diagrama de Clases de Diseño del SEFP ................................................................ 138

Ilustración 101. Diagrama de Clases de Diseño del SPDV ............................................................... 142

Ilustración 102. Diagrama de Clases de Normalizado al Lenguaje Java .......................................... 143

Ilustración 103. Definición de Código para la Clase LineaDeVenta ................................................. 144

Ilustración 104. Identificación del Atributo de Referencia de LineaDeVenta ................................. 144

Ilustración 105. Especificando Atributos del Contenedor Venta .................................................... 145

Ilustración 106. Colaboración para agregarProducto en la Venta Actual ....................................... 146


178

Ilustración 107. Especificación del Cuerpo de la Operación agregarProducto ............................... 146

Ilustración 108. Diagrama de Clases de Implementación para el SPDV ......................................... 147

Ilustración 109. Diagrama de Clases de Diseño con Tipos de Datos Java del SEFP ......................... 150

Ilustración 110. Diagrama de Clases de Implementación Completo del SEFP ................................ 151

Ilustración 111. Ventana de Inicio de StarUML ............................................................................... 164

Ilustración 112. Ventana Principal de StarUML .............................................................................. 167

Ilustración 113. Agregando un Diagrama en StarUML .................................................................... 168

Ilustración 114. Ventana Administradora de Perfiles de StarUML ................................................. 169

Ilustración 115. Ventana del Paso 1 de Generación de Código de StarUML .................................. 169




Andres Munoz - Analisis y Diseno Orientado Al Objeto

Documents

Transcript of Andres Munoz - Analisis y Diseno Orientado Al Objeto