Andres Munoz - Analisis y Diseno Orientado Al Objeto
-
Upload
andres-munoz-ordenes -
Category
Documents
-
view
342 -
download
0
description
Transcript of 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
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
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
Conceptos Básicos ......................................................................................................... 51
Dominio ................................................................................................................................. 51
Clases Conceptuales .............................................................................................................. 52
Proceso .................................................................................................................................. 52
Artefactos del Modelo .................................................................................................. 53
Proceso de Desarrollo del Modelo ................................................................................ 53
Especificación del Proceso de Negocio ................................................................................. 53
Identificación de Clases Conceptuales .................................................................................. 55
Diagrama de Clases Conceptuales......................................................................................... 62
MODELO DE COMPORTAMIENTO ............................................................................................... 64
Conceptos Básicos ......................................................................................................... 64
Evento.................................................................................................................................... 64
Contrato ................................................................................................................................ 64
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
4
Estado .................................................................................................................................... 64
Artefactos del Modelo .................................................................................................. 65
Proceso de Desarrollo del Modelo ................................................................................ 65
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
Conceptos Básicos ......................................................................................................... 94
Refinamiento ......................................................................................................................... 94
Componente .......................................................................................................................... 95
Artefactos del Modelo .................................................................................................. 95
Proceso de Desarrollo del Modelo ................................................................................ 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
Conceptos Básicos ......................................................................................................... 99
Realización de Caso de Uso ................................................................................................... 99
Responsabilidad .................................................................................................................... 99
Patrones de Diseño ............................................................................................................. 100
Artefactos del Modelo ................................................................................................ 101
Proceso de Desarrollo del Modelo .............................................................................. 101
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
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
Diagramas de Colaboración ................................................................................................ 129
Diagrama de Clases de Diseño ............................................................................................ 134
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
Diagrama de Clases 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
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
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
Diagramas de Colaboración ................................................................................................ 158
Diagrama de Clases de Diseño ............................................................................................ 158
Modelo de Implementación ........................................................................................ 159
Diagrama de Clases 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
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
7
INTRODUCCIÓN
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
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.
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
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.
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
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.
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
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:
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
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:
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
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:
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
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.
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
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
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
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:
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
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
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
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:
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
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.
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
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:
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
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.
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
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:
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
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)
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
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:
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
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:
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
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:
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
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
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
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:
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
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.
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
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.
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
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.
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
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.
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
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:
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
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.
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
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
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
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.
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
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.
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
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:
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
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
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
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
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
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.
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
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
Atributo Detalles y Restricciones Categoría
# 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.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
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.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
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
MODELO DE CASOS DE USO
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:
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
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:
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
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.
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
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
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
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.
ESPECIFICACIÓN DE CASOS DE USO
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:
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
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. …
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
48
DIAGRAMA DE CASOS DE USO
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.
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
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
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
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
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
51
Por ejemplo, aquí está parte del glosario al problema que hemos visto durante las secciones
anteriores.
Glosario
Término Definición
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.
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
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.
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
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.
ARTEFACTOS DEL MODELO
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.
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 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.
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
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
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
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
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
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.
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
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.
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
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.
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
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.
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
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 *
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
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.
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
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:
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
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
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
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
A continuación algunos conceptos importantes que son necesarios de entender para este modelo.
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:
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
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 DEL MODELO
Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos
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.
Veamos ahora cómo se desarrollan estos artefactos.
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 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.
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
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.
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
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
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
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.
CONTRATOS DE LAS OPERACIONES
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:
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
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
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
70
Operación: CO2. ingresarProducto(cod : CodigoBarras, cant : Int)
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.
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
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:
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
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:
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
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
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
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.
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
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).
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# 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.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# 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.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# 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.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
# 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.
Categoría: Evidente
Atributo Detalles y Restricciones Categoría
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
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
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
Atributo Detalles y Restricciones Categoría
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.
MODELO DE CASOS DE USO
A continuación definiremos el modelo de casos de uso del problema.
ESPECIFICACIÓN DE CASOS DE USO
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:
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
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
en box incluyendo los procedimientos y medicamentos indicados.
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.
Caso de Uso: CU1: Registrar Paciente
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
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
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.
Caso de Uso: CU2: Consultar Historial
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.
Tipo: Primario y Esencial
Ref. Cruzadas: R2.1
Curso Normal
Acciones de los Actores Respuestas del Sistema
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.
Caso de Uso: CU3: Registrar Anamnesis
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
en box incluyendo los procedimientos y medicamentos indicados.
Tipo: Primario y Esencial
Ref. Cruzadas: R1.2, CU7
Curso Normal
Acciones de los Actores Respuestas del Sistema
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,
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
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.
Caso de Uso: CU5: Registrar Resultado de Procedimiento
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.
Tipo: Primario y Esencial
Ref. Cruzadas: R1.4
Curso Normal
Acciones de los Actores Respuestas del Sistema
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.
Caso de Uso: CU7: Actualizar Agenda Médica
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.
Tipo: Primario y Esencial
Ref. Cruzadas: R2.2, CU3
Curso Normal
Acciones de los Actores Respuestas del Sistema
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.
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
80
DIAGRAMA DE CASOS DE USO
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:
Término Definición
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
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
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.
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
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
DIAGRAMA DE CLASES CONCEPTUALES
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:
Categoría de Clase Conceptual Ejemplos
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
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
83
Categoría de Clase Conceptual Ejemplos
Paciente
Contenedores de otras cosas -
Cosas en un contenedor -
Otros sistemas externos AgendaMedica
Conceptos abstractos Anamnesis Procedimiento FichaDePaciente
Organizaciones -
Hechos -
Procesos Anamnesis Procedimiento
Reglas y 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:
Caso de Uso: CU1: Registrar Paciente
Curso Normal
Acciones de los Actores Respuestas del Sistema
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.
Caso de Uso: CU2: Consultar Historial
Curso Normal
Acciones de los Actores Respuestas del Sistema
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.
Caso de Uso: CU3: Registrar Anamnesis
Curso Normal
Acciones de los Actores Respuestas del Sistema
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
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
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.
Caso de Uso: CU5: Registrar Resultado de Procedimiento
Curso Normal
Acciones de los Actores Respuestas del Sistema
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.
Caso de Uso: CU7: Actualizar Agenda Médica
Curso Normal
Acciones de los Actores Respuestas del Sistema
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:
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
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.
MODELO DE COMPORTAMIENTO
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.
DIAGRAMAS DE SECUENCIA
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:
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
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:
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
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:
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
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.
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
89
CONTRATOS DE LAS OPERACIONES
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
Tipo o Clase: Sistema
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
Tipo o Clase: Sistema
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.
Tipo o Clase: Sistema
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.
Tipo o Clase: Sistema
Ref. Cruzadas: CU3, CU5
Notas: Objeto puede tomar valores de DetalleAnamnesis y
DetalleProcedimiento
Excepciones: -
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
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.
Tipo o Clase: Sistema
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.
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
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.
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
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.
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
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
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
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.
MODELO ARQUITECTÓNICO
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
A continuación algunos conceptos importantes que son necesarios de entender para este modelo.
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.
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
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 DEL MODELO
Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos
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.
Veamos ahora cómo se desarrollan estos artefactos.
PROCESO DE DESARROLLO DEL MODELO
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
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
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.
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
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.
DIAGRAMA DE COMPONENTES
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:
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
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.
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
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.
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
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.
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
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 DEL MODELO
Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos
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.
Veamos ahora cómo se desarrollan estos artefactos.
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 cada una de ellas en detalle.
DIAGRAMAS DE COLABORACIÓN
UML nos dice que:
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
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:
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
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.
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
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:
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
105
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:
Operación: CO2. ingresarProducto(cod : CodigoBarras, cant : Int)
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:
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
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
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
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
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
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:
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
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.
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
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).
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
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?
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
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
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
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.
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
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.
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
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.
DIAGRAMA DE CLASES DE DISEÑO
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.
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
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:
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
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
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
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
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
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.
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
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:
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
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.
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
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:
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
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.
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
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í:
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
125
ILUSTRACIÓN 78. COMPOSICIÓN DE LÍNEAS DE VENTA EN EL SPDV
CASO DE ESTUDIO: SISTEMA ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP)
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.
MODELO ARQUITECTÓNICO
En este ejemplo solo nos referiremos al diagrama de componentes del modelo.
DIAGRAMA DE COMPONENTES
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:
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
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:
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
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
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
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
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 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.
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
129
DIAGRAMAS DE COLABORACIÓN
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.
Operación: CO1. validarRut(rut)
Responsabilidad: Validar que el RUT exista dentro del catalogo de pacientes
Tipo o Clase: Sistema
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:
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
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
Tipo o Clase: Sistema
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í:
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
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.
Tipo o Clase: Sistema
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).
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
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.
Tipo o Clase: Sistema
Ref. Cruzadas: CU3, CU5
Notas: Objeto puede tomar valores de DetalleAnamnesis y
DetalleProcedimiento
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
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
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).
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
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.
Tipo o Clase: Sistema
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.
DIAGRAMA DE CLASES DE DISEÑO
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.
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
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
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
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.
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
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:
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
138
ILUSTRACIÓN 100. DIAGRAMA DE CLASES DE DISEÑO DEL SEFP
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
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.
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
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.
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
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.
MODELO DE IMPLEMENTACIÓN
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
A continuación algunos conceptos importantes que son necesarios de entender para este modelo.
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.
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
142
ARTEFACTOS DEL MODELO
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.
Veamos ahora cómo se desarrollan estos artefactos.
PROCESO DE DESARROLLO DEL MODELO
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
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
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:
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
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:
public class LineaDeVenta {
/* ATRIBUTOS */
private short cantidad;
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
+new(p: Producto, cant: short): LineaDeVenta-setProducto(p: Producto)-setCantidad(cant: short)+obtenerSubTotal(): double
-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.
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
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
+new(p: Producto, cant: short): LineaDeVenta-setProducto(p: Producto)-setCantidad(cant: short)+obtenerSubTotal(): double
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:
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
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.
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
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);
}
}
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
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
public class LineaDeVenta {
private short cantidad;
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;
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
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.
CASO DE ESTUDIO: SISTEMA ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP)
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.
MODELO DE IMPLEMENTACIÓN
En este modelo especificaremos solo la estructura de clases a partir del DCD y usando Java.
DIAGRAMA DE CLASES DE IMPLEMENTACIÓN
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
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:
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
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;
}
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
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;
}
}
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
153
public class Procedimiento {
private DetalleDeProcedimiento detalle;
public Procedimiento(String observaciones, String resultados,
String diagnostico) {
this.detalle = new DetalleDeProcedimiento(observaciones,
resultados, diagnostico);
}
}
public class Anamnesis {
private DetalleDeAnamnesis detalle;
public Anamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
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,
String fono, String email) {
this.detalle = new DetalleDePaciente(rut, nombre, direccion,
fono, email);
}
public DetalleDePaciente consultarRut(int rut) {
return this.detalle;
}
public void crearAnamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
Anamnesis anam = new Anamnesis(inspeccion, observaciones,
indicaciones, otros);
this.anamnesis.addElement(anam);
}
public void crearProcedimiento(String observaciones, String resultados,
String diagnostico) {
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);
}
}
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
154
public class ConsultaControlador {
private FichaDePaciente paciente;
public void registrarAnamnesis(String inspeccion, String observaciones,
String indicaciones, String otros) {
this.paciente.crearAnamnesis(inspeccion, observaciones,
indicaciones, otros);
}
}
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,
String fono, String email) {
this.fichas.crearFichaDePaciente(rut, nombre, direccion,
fono, email);
}
public void consultar(int rut) {
FichaDePaciente f = this.fichas.buscar(rut);
}
}
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
155
ANEXOS
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
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:
Atributo Detalles y Restricciones Categoría
MODELO DE CASOS DE USO
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.
ESPECIFICACIÓN DE CASOS DE USO
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.
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
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
DIAGRAMA DE CASOS DE USO
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.
Término Definición
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>
DIAGRAMA DE CLASES CONCEPTUALES
El dominio se observa en el siguiente diagram:
<INSERTAR DIAGRAMA>
MODELO DE COMPORTAMIENTO
En esta sección se describen los artefactos que describen el comportamiento del sistema.
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
158
DIAGRAMAS DE SECUENCIA
Los casos de uso se describen en los siguientes diagramas de secuencia:
<INSERTAR DIAGRAMAS POR CASO DE USO>
CONTRATOS DE LAS OPERACIONES
Las operaciones del sistema se describen a través de los siguientes contraltos:
Operación: CO1. validarRut(rut)
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>
MODELO ARQUITECTÓNICO
En esta sección se describen las decisiones de la arquitectura que afectan a la organización de los
programas finales.
DIAGRAMA DE COMPONENTES
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.
DIAGRAMAS DE COLABORACIÓN
Las operaciones se realizan en el sistema de la siguiente forma:
<INSERTAR DIAGRAMAS POR OPERACION DE SISTEMA>
DIAGRAMA DE CLASES DE DISEÑO
El diagrama de clases que define el sistema es el siguiente:
<INSERTAR DIAGRAMA>
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
159
MODELO DE IMPLEMENTACIÓN
En esta sección se describen las labores de preparación de la codificación.
DIAGRAMA DE CLASES DE IMPLEMENTACIÓ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>
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
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:
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
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
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
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
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
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.
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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 >”.
ILUSTRACIÓN 116. VENTANA DEL PASO 2 DE GENERACIÓN DE CÓDIGO DE STARUML
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.
ILUSTRACIÓN 117. VENTANA DEL PASO 3 DE GENERACIÓN DE CÓDIGO DE STARUML
Además, se debe seleccionar la carpeta en donde se desea guardar el código y presionar la acción
“Next >”.
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
171
ILUSTRACIÓN 118. VENTANA DEL PASO 4 DE GENERACIÓN DE CÓDIGO DE STARUML
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Ilustración 116. Ventana del Paso 2 de Generación de Código de StarUML .................................. 170
Ilustración 117. Ventana del Paso 3 de Generación de Código de StarUML .................................. 170
Ilustración 118. Ventana del Paso 4 de Generación de Código de StarUML .................................. 171