Modelado estructural

Un modelo estructural o conceptual describe la estructura de los objetos que soportan

los procesos de negocio en una organización. Durante el análisis, el modelo estructural presenta
la organización lógica de los objetos sin indicar cómo se almacenan, crean o manipulan para que
los analistas puedan enfocarse en el negocio, sin distraerse por los detalles de los problemas
técnicos.

Más tarde durante el diseño, el modelo estructural se actualiza para reflejar exactamente
cómo los objetos se almacenarán en bases de datos y archivos. Este capítulo describe la
responsabilidad de clase

tarjetas de colaboración (CRC), diagramas de clases y diagramas de objetos, que se utilizan

para crear el

modelo estructural.

OBJETIVOS

■ Comprender las reglas y pautas de estilo para crear tarjetas CRC, diagramas de clases,

y diagramas de objetos.

■ Comprender los procesos utilizados para crear tarjetas CRC, diagramas de clases y diagramas
de objetos.

■ Ser capaz de crear tarjetas CRC, diagramas de clases y diagramas de objetos.

■ Comprender la relación entre los modelos estructurales.

■ Comprender la relación entre los modelos estructurales y funcionales.

INTRODUCCIÓN

Durante el análisis, los analistas crean procesos de negocio y modelos funcionales para
representar cómo el sistema de negocios se comportará. Al mismo tiempo, los analistas deben
comprender la información que usa y crea el sistema comercial (por ejemplo, información del
cliente, información del pedido).

En este capítulo, discutimos cómo los objetos subyacentes al comportamiento modelaron en el

proceso de negocio y modelos funcionales son organizados y presentados.

Como se señaló en el Capítulo 1, todos los enfoques de desarrollo de sistemas orientados a

objetos son

guiado por casos de uso, centrado en la arquitectura e iterativo e incremental. Casos de uso,
descritos en

El Capítulo 4, forma la base sobre la cual se crea el sistema de información comercial. De

una perspectiva centrada en la arquitectura, el modelado estructural apoya la creación de un

vista estructural o estática de un sistema de información comercial en el que muestra cómo es

el sistema
estructurado para soportar los procesos de negocios subyacentes. Finalmente, como con el
proceso comercial y

modelado funcional, encontrará que necesitará no solo iterar a través de la estructura

modelos (descritos en este capítulo), pero también tendrá que iterar a través de los tres

vistas (funcionales, estructurales y de comportamiento) para capturar y representar

completamente los requisitos

para un sistema de información comercial.

Un modelo estructural es una forma formal de representar los objetos que se usan y crean
mediante un sistema de negocios. Ilustra personas, lugares o cosas sobre las cuales se captura
información y cómo están relacionados el uno con el otro. El modelo estructural se dibuja
usando un iterativo proceso en el que el modelo se vuelve más detallado y menos conceptual a
lo largo del tiempo. En análisis,

los analistas dibujan un modelo conceptual, que muestra la organización lógica de los objetos
sin que indica cómo se almacenan, crean o manipulan los objetos. Porque este modelo es
gratis

desde cualquier implementación o detalles técnicos, los analistas pueden enfocarse más
fácilmente en la correspondencia

el modelo a los requisitos comerciales reales del sistema.

En diseño, los analistas evolucionan el modelo estructural conceptual en un modelo de diseño

que

Refleja cómo se organizarán los objetos en bases de datos y software. En este punto, el
modelo es

se verificó la redundancia y los analistas investigan formas de facilitar la recuperación de los

objetos.

Las especificaciones del modelo de diseño se discuten en detalle en los capítulos de diseño.

MODELOS ESTRUCTURALES

Cada vez que un analista de sistemas encuentra un nuevo problema para resolver, el analista
debe aprender dominio del problema subyacente. El objetivo del analista es descubrir los
objetos clave contenidos en el dominio del problema y para construir un modelo estructural. El
modelado orientado a objetos permite

analista para reducir la brecha semántica entre el dominio del problema subyacente y la
evolución

modelo estructural. Sin embargo, el mundo real y el mundo de software son muy diferentes.
Los

el mundo real tiende a ser desordenado, mientras que el mundo de software debe ser
ordenado y lógico. Nosotros,

un mapeo exacto entre el modelo estructural y el dominio del problema puede no ser posible.
De hecho, tal vez ni siquiera sea deseable.

Uno de los propósitos principales del modelo estructural es crear un vocabulario que pueda
ser

utilizado por el analista y los usuarios. Los modelos estructurales representan las cosas, ideas o
conceptos

contenido en el dominio del problema. También permiten la representación de las relaciones

entre las cosas, ideas o conceptos. Creando un modelo estructural del problema

dominio, el analista crea el vocabulario necesario para que el analista y los usuarios se
comuniquen efectivamente.

Es importante recordar que en esta etapa de desarrollo, el modelo estructural no

representar componentes de software o clases en un lenguaje de programación orientado a

objetos, incluso

aunque el modelo estructural contiene clases de análisis, atributos, operaciones y relaciones

entre las clases de análisis. El refinamiento de estas clases iniciales en el nivel de programación

los objetos vienen después No obstante, el modelo estructural en este punto debe representar
las responsabilidades

de cada clase y las colaboraciones entre las clases. Por lo general, los modelos estructurales
son

representado con tarjetas CRC, diagramas de clases y, en algunos casos, diagramas de objetos.
Sin embargo, antes

describiendo las tarjetas CRC, diagramas de clases y diagramas de objetos, describimos los
elementos básicos de

modelos estructurales: clases, atributos, operaciones y relaciones.

Clases, atributos y operaciones

Una clase es una plantilla general que usamos para crear instancias u objetos específicos en el
problema

dominio. Todos los objetos de una clase dada son idénticos en estructura y comportamiento,
pero contienen diferentes datos en sus atributos. Hay dos tipos generales de clases de interés
durante el análisis:

concreto y abstracto. Normalmente, cuando un analista describe las clases de dominio de la

aplicación,

él o ella se está refiriendo a clases concretas; es decir, las clases concretas se usan para crear
objetos.

Las clases abstractas no existen realmente en el mundo real; son simplemente abstracciones
útiles.
Por ejemplo, de una clase de empleado y una clase de cliente, podemos identificar una
generalización

de las dos clases y el nombre de la persona de la clase abstracta. Es posible que no creemos
una instancia del

clase de persona en el sistema mismo, en lugar de crear y usar solo empleados y clientes.1

Una segunda clase de clases es el tipo de cosas del mundo real que representa una clase.

Existen clases de dominio, clases de interfaz de usuario, clases de estructura de datos,

estructura de archivos

clases, clases de entorno operativo, clases de documentos y varios tipos de multimedia

clases En este punto del desarrollo de nuestro sistema en evolución, solo estamos interesados

en clases de dominio. Más tarde en el diseño e implementación, los otros tipos de clases se
vuelven

más relevantes.

Un atributo de una clase de análisis representa una información relevante para el

descripción de la clase dentro del dominio de la aplicación del problema que se está
investigando.

Un atributo contiene información que el analista o usuario siente que el sistema debe seguir.

Por ejemplo, un posible atributo relevante de una clase de empleado es el nombre del
empleado, mientras que

uno que podría no ser tan relevante es el color de pelo. Ambos describen algo acerca de un
empleado,

pero el color del cabello probablemente no sea tan útil para la mayoría de las aplicaciones
comerciales. Solo atributos

que son importantes para la tarea deben incluirse en la clase. Finalmente, solo atributos que

son tipos primitivos o atómicos (es decir, enteros, cadenas, dobles, fecha, hora, booleano, etc.)
deberían

ser agregado. La mayoría de los atributos complejos o compuestos son realmente marcadores
de posición para las relaciones

entre clases. Por lo tanto, deben modelarse como relaciones, no como atributos (ver

la siguiente sección).

El comportamiento de una clase de análisis se define en una operación o servicio. En fases

posteriores, el

las operaciones se convierten a métodos. Sin embargo, debido a que los métodos están más
relacionados con la implementación,

en este punto del desarrollo usamos el término operación para describir las acciones
a lo que las instancias de la clase son capaces de responder. Como atributos, solo problema

las operaciones específicas del dominio que son relevantes para el problema que se investiga
deben ser

considerado. Por ejemplo, normalmente se requiere que las clases proporcionen medios para
crear

instancias, eliminación de instancias, acceso a valores de atributos individuales,

establecimiento de atributos individuales

valores, acceder a valores de relación individuales y eliminar la relación individual

valores. Sin embargo, en este punto del desarrollo del sistema en evolución, el analista debería

evite saturar la definición de la clase con estos tipos básicos de operaciones y enfoque

solo en operaciones problemáticas específicas del dominio problemático.

Relaciones

Hay muchos tipos diferentes de relaciones que se pueden definir, pero todas se pueden
clasificar

en tres categorías básicas de mecanismos de abstracción de datos: relaciones de

generalización,

relaciones de agregación y relaciones de asociación. Estos mecanismos de abstracción de datos

permitir que el analista se centre en las dimensiones importantes sin tener en cuenta las no
esenciales

dimensiones. Al igual que con los atributos, el analista debe tener cuidado de incluir solo

relaciones.

Relaciones de generalización

La abstracción de generalización permite al analista crear

clases que heredan atributos y operaciones de otras clases. El analista crea una superclase

que contiene los atributos básicos y las operaciones que se usarán en varias subclases.

Las subclases heredan los atributos y las operaciones de su superclase y también pueden
contener

atributos y operaciones que son únicos solo para ellos. Por ejemplo, una clase de cliente y

una clase de empleado puede generalizarse en una clase de persona extrayendo los atributos y

operaciones ambas tienen en común y las coloca en la nueva superclase, persona. En esto

De esta forma, el analista puede reducir la redundancia en las definiciones de clase para que el
común

los elementos se definen una vez y luego se reutilizan en las subclases. La generalización está
representada
con la relación a-kind-of, de modo que decimos que un empleado es una especie de persona.

El analista también puede usar lo opuesto a la generalización. La especialización descubre

clases adicionales al permitir que se creen nuevas subclases a partir de una clase existente. por

ejemplo, una clase de empleado puede ser especializada en una clase de secretaria y una clase
de ingeniero.

Además, las relaciones de generalización entre clases se pueden combinar para formar una
generalización

jerarquías En base a los ejemplos anteriores, una clase de secretaria y una clase de ingeniero

pueden ser subclases de una clase de empleado, que a su vez podría ser una subclase de una
clase de persona.

Esto se leería como un secretario y un ingeniero son un tipo de empleado y un cliente

y un empleado es una especie de persona.

La abstracción de datos de generalización es un mecanismo muy poderoso que fomenta la

analista para centrarse en las propiedades que hacen que cada clase sea única al permitir las
similitudes

para tener en cuenta en las superclases. Sin embargo, para asegurar que la semántica de las
subclases sea

mantenido, el analista debe aplicar el principio de sustituibilidad. Con esto queremos decir que

la subclase debería ser capaz de sustituir la superclase en cualquier lugar que use la superclase

(Por ejemplo, en cualquier lugar donde usemos la superclase de empleados, también

podríamos usar lógicamente su secretaria)

subclase). Al centrarse en la interpretación a-kind-of de la relación de generalización, el

principio de sustituibilidad se aplica.

Relaciones de agregación

En términos generales, todas las relaciones de agregación se relacionan con partes

totalidades o asambleas. Para nuestros propósitos, utilizamos la relación semántica de una

parte de o partes

para representar la abstracción de agregación. Por ejemplo, una puerta es una parte de un
automóvil, un empleado es

una parte de un departamento, o un departamento es una parte de una organización. Como la

generalización

relación, las relaciones de agregación se pueden combinar en jerarquías de agregación. por

Por ejemplo, un pistón es una parte de un motor, y un motor es una parte de un automóvil.

Las relaciones de agregación son bidireccionales. El lado fl ip de la agregación es la

descomposición.
El analista puede usar la descomposición para descubrir partes de una clase que deberían
modelarse por separado.

Por ejemplo, si una puerta y un motor son parte de un automóvil, entonces un automóvil tiene
partes de puerta y

motor. El analista puede rebotar entre las distintas partes para descubrir nuevas partes. por

Por ejemplo, el analista puede preguntar: ¿Qué otras partes hay para un automóvil? o A qué
otras asambleas

¿Puede una puerta pertenecer?

Relaciones de asociación

Existen otros tipos de relaciones que no encajan perfectamente en

un marco de generalización (a-kind-of) o aggregation (a-part-of). Tecnicamente hablando,

estas relaciones suelen ser una forma más débil de la relación de agregación. Por ejemplo, un

el paciente programa una cita. Se podría argumentar que un paciente es parte de una cita.

Sin embargo, existe una clara diferencia semántica entre este tipo de relación y uno

que modela la relación entre puertas y automóviles o incluso trabajadores y sindicatos.

Nosotros, ellos

simplemente se consideran asociaciones entre instancias de clases.

IDENTIFICACIÓN DE OBJETOS

Se han sugerido diferentes enfoques para ayudar al analista a identificar un conjunto de

candidatos

objetos para el modelo estructural. Los cuatro enfoques más comunes son el análisis textual,

lluvia de ideas, listas de objetos comunes y patrones. La mayoría de los analistas usan una
combinación de estos

técnicas para asegurarse de que no haya objetos importantes ni atributos de objetos,

operaciones y

las relaciones han sido pasadas por alto.

Análisis textual

El analista realiza un análisis textual revisando los diagramas de caso de uso y examinando

el texto en las descripciones del caso de uso para identificar posibles objetos, atributos,
operaciones y

relaciones. Los nombres en el caso de uso sugieren posibles clases, y los verbos sugieren
posibles

operaciones. La Figura 5-1 presenta un resumen de pautas útiles. El análisis textual de

 • Un nombre común o impropio implica una clase de objetos.

• Un nombre propio o referencia directa implica una instancia de una clase.

• Un sustantivo colectivo implica una clase de objetos compuesta por grupos de

instancias de otra clase.

• Un adjetivo implica un atributo de un objeto.

• Un verbo doing implica una operación.

• Un verbo ser implica una relación de clasificación entre un objeto y su clase.

• Un verbo tener implica una relación de agregación o asociación.

• Un verbo transitivo implica una operación.

• Un verbo intransitivo implica una excepción.

• Un predicado o frase verbal descriptiva implica una operación.

Lineamientos
• Undel análisisimplica
adverbio textualun atributo de una relación o una operación.

descripciones de caso
Adaptado de: Estasde uso hasesido
pautas criticada
basan por ser
en Russell demasiado
J. Abbott, simple,
"Diseño pero debido a su
de programas
propósito principal mediante descripciones informales en inglés".

es Comunicaciones
crear un modelodelestructural
ACM 26,básico
no. 11inicial,
(1983):su882
simplicidad es una
- 894; Peter gran ventaja.
P-S Chen, "Estructura
de oraciones en inglés y
Por ejemplo, si aplicamos estas reglas al caso de uso de Make Old Patient Appt descrito en
Diagramas de relaciones entre entidades, "Information Sciences: An International
Capítulo 4 y replicado en la Figura 5-2, podemos identificar fácilmente objetos potenciales
Journal 29, no. 2-3 (1983): 127 - 149;
para un viejo
Ian Graham, migrando a la tecnología de objetos (Reading, MA: Addison Wesley
paciente, doctor, cita, paciente, oficina, recepcionista, nombre, dirección, información del
Longman, 1995).
paciente,

pago, fecha y hora. También podemos identificar fácilmente operaciones potenciales que
pueden ser

asociado con los objetos identificados. Por ejemplo, la oficina de contactos del paciente, hace
una nueva

cita, cancela una cita existente, cambia una cita existente, coincide

fechas y fechas de citas solicitadas con las horas y fechas solicitadas, y encuentra actual

cita.

Reunión creativa

La lluvia de ideas es una técnica de descubrimiento que se ha utilizado con éxito para
identificar al candidato

clases Esencialmente, en este contexto, la lluvia de ideas es un proceso que un conjunto de

individuos

sentados alrededor de una mesa sugieren clases potenciales que podrían ser útiles para el
problema bajo
consideración. Por lo general, una sesión de tormenta de ideas la inicia un facilitador que
pregunta al

conjunto de personas para abordar una pregunta o declaración específica que enmarca la
sesión. por

Por ejemplo, utilizando el problema de cita descrito anteriormente, el facilitador podría

preguntar al

el equipo de desarrollo y los usuarios a pensar en sus experiencias de hacer citas y

para identificar clases candidatas basadas en sus experiencias pasadas. Tenga en cuenta que
este enfoque no

no use los modelos funcionales desarrollados anteriormente. Simplemente pide a los

participantes que identifiquen

los objetos con los que han interactuado. Por ejemplo, un conjunto potencial de objetos que

vienen a la mente médicos, enfermeras, recepcionistas, citas, enfermedades, tratamientos,

recetas,

tarjeta de seguro y registros médicos. Una vez que un número suficiente de objetos candidatos

han sido identificados, los participantes deben discutir y seleccionar cuál de los candidatos

los objetos deben considerarse más. Una vez que estos han sido identificados, más lluvia de
ideas

puede tener lugar para identificar posibles atributos, operaciones y relaciones para cada uno
de

los objetos identificados.

Bellin y Simone2 han sugerido un conjunto de principios útiles para guiar una lluvia de ideas

sesión. Primero, todas las sugerencias deben tomarse en serio. En este punto del desarrollo

Nombre del caso de uso:

Actor principal:
Interesados e intereses:
Breve descripción:
ID: Nivel de importancia:
Desencadenar:
Flujo normal de eventos:
Subflujos:
Flujos alternativos / excepcionales:
Tipo: Externo
Hacer Old Patient Appt 2 Low
Paciente viejo
Paciente anciano: quiere hacer, cambiar o cancelar una cita
Doctor: quiere asegurarse de que las necesidades del paciente se cumplan de manera oportuna
Usar tipo de caso: detalle, esencial
Llamadas de pacientes y solicita una nueva cita o pide cancelar o cambiar una cita existente.
Paciente viejo
Actualice la información del paciente
Administrar citas
del sistema, es mucho mejor tener que eliminar algo más tarde que dejar accidentalmente

algo crítico fuera. En segundo lugar, todos los participantes deberían comenzar a pensar rápida
y furiosamente. Después

todas las ideas están en la mesa proverbial, entonces se puede alentar a los participantes a
meditar

las clases candidatas que han identificado. Por supuesto, el facilitador debe administrar el
ayuno y
proceso de pensamiento furioso. De lo contrario, el proceso será caótico. Además, el
facilitador

debe garantizar que todos los participantes participen y que algunos participantes no dominen

el proceso. Para obtener la visión más completa del problema, sugerimos utilizar un round-
robin

enfoque en el cual los participantes se turnan para sugerir clases candidatas. Otro enfoque es

utilizar una herramienta electrónica de intercambio de ideas que apoye el anonimato.3 En

cuarto lugar, el facilitador puede

use el humor para romper el hielo para que todos los participantes puedan sentirse cómodos
al hacer sugerencias.

Listas de objetos comunes

Como su nombre lo indica, una lista de objetos común es simplemente una lista de objetos
comunes a la empresa

dominio del sistema. Se han encontrado varias categorías de objetos para ayudar al analista

al crear la lista, como cosas físicas o tangibles, incidentes, roles e interacciones.4

Los analistas deberían primero buscar cosas físicas o tangibles en el dominio comercial. Esto
podría

incluye libros, escritorios, sillas y equipo de oficina. Normalmente, este tipo de objetos son

más fácil de identificar Los incidentes son eventos que ocurren en el ámbito comercial, como
reuniones,

vuelos, actuaciones o accidentes. La revisión de los casos de uso puede identificar fácilmente
los roles que

las personas juegan en el problema, como doctor, enfermera, paciente o recepcionista.

Típicamente, un

interacción es una transacción que tiene lugar en el dominio comercial, como una transacción
de venta.

Otros tipos de objetos que se pueden identificar incluyen lugares, contenedores,

organizaciones,

registros comerciales, catálogos y políticas. En casos raros, los procesos mismos pueden
necesitar información

almacenado sobre ellos. En estos casos, los procesos pueden necesitar un objeto, además de
un uso

caso, para representarlos. Finalmente, hay bibliotecas de objetos reutilizables que se han
creado

para diferentes dominios comerciales. Por ejemplo, con respecto al problema de la cita, el
Objetos médicos comunes de código abierto5 podrían ser útiles para investigar sobre objetos
potenciales

eso debería ser incluido.

Patrones

La idea de usar patrones es un área relativamente nueva en el desarrollo de sistemas

orientados a objetos.

Ha habido muchas definiciones de lo que es exactamente un patrón. Desde nuestra

perspectiva, un patrón

es simplemente un grupo útil de clases colaboradoras que proporcionan una solución a un

problema que ocurre. Debido a que los patrones proporcionan una solución a los problemas
comunes,

son reutilizables Un arquitecto, Christopher Alexander, ha inspirado gran parte del trabajo
asociado con

utilizando patrones en el desarrollo de sistemas orientados a objetos. De acuerdo con

Alexander y sus colegas,

7 es posible hacer edificios muy sofisticados al unirlos comúnmente

patrones encontrados, en lugar de crear conceptos y diseños completamente nuevos. De

forma similar,

es posible armar patrones comunes orientados a objetos para formar elegantes

sistemas de información orientados a objetos. Por ejemplo, muchas transacciones comerciales

involucran a

los mismos tipos de objetos e interacciones. Prácticamente todas las transacciones requerirían
una transacción

clase, una clase de elemento de línea de transacción, una clase de elemento, una clase de
ubicación y una clase de participante. Por

reutilizando estos patrones de clases existentes, podemos definir de forma más rápida y más
completa

el sistema que si comenzamos con un pedazo de papel en blanco.

Se han propuesto muchos tipos de patrones, que van desde negocios de alto nivel orientados

patrones a patrones de diseño de más bajo nivel. Por ejemplo, la Figura 5-3 muestra un
conjunto de útiles

patrones de análisis.8 La figura 5-4 muestra un diagrama de clases que creamos al fusionar los
patrones

contenido en la figura 5-3 en un solo patrón reutilizable. En este caso, fusionamos la

Transacción-
Patrón de cuenta de entrada (ubicado en la esquina inferior izquierda de la Figura 5-3) con
Place-Transaction-

Patrón participante-línea de transacción-elemento (ubicado en la esquina superior izquierda

de la Figura 5-3) en el

Patrones de muestra----Ejemplo de integración de patrones de muestra

clase de transacción común. Luego, fusionamos Party-Person-Organization (ubicado en el

arriba a la derecha de la Figura 5-3) fusionando las clases Participante y Partida. Finalmente,
extendimos

la clase Item al fusionar la clase Item con la clase Product del Product-Good-Service

patrón (ubicado en la parte inferior derecha de la Figura 5-3).

De esta manera, el uso de patrones de diferentes fuentes permite al equipo de desarrollo

para aprovechar el conocimiento más allá de los miembros inmediatos del equipo y permite
que el equipo

desarrollar modelos más completos y robustos del dominio del problema Por ejemplo, en el
caso

del problema de la cita, podemos mirar los objetos previamente identificados a través de
textual

análisis, lluvia de ideas y / o listas de objetos comunes y ver si tiene sentido mapear cualquiera
de

en cualquier patrón reutilizable predefinido. En este caso específico, podemos ver una cita

como un tipo de transacción en la que participa la oficina de un médico. Al mirar una cita como
un

tipo de transacción, podemos aplicar el patrón que creamos en la Figura 5-4 y descubrir un
conjunto de

Objetos no identificados, como Lugar, Paciente como tipo de participante y Línea de

transacción

Artículos que están asociados con diferentes tipos de Artículos (Bienes y / o Servicios).
Descubriendo

estos objetos adicionales específicos podrían ser útiles para desarrollar el lado de facturación
de la cita

sistema. Aunque estos objetos adicionales podrían ser aplicables, no fueron descubiertos

usando las otras técnicas.

Con base en este ejemplo simple, es obvio que el uso de patrones para desarrollar estructural

los modelos pueden ser ventajosos. La Figura 5-5 enumera algunos dominios comerciales
comunes para los cuales
patrones han sido desarrollados y su fuente. Si estamos desarrollando una información
comercial

sistema en uno de estos dominios comerciales, entonces los patrones desarrollados para ese
dominio pueden

ser un punto de partida muy útil para identificar las clases necesarias y sus atributos,
operaciones,

y relaciones

Dominios comerciales Fuentes de patrones

Contabilidad 3, 4
Actor-Rol 2
Asamblea-Parte 1
Contenedor-Contenido 1
Contrato 2, 4
Documento 2, 4
Empleo 2, 4
Contratos de Derivados Financieros 3
Ubicación geográfica 2, 4
Miembro del grupo 1
Interacción 1
Planificación de los requisitos de material 4
Organización y fiesta 2, 3
Plan 1, 3
Proceso de fabricación 4
Trading 3
Transacciones 1, 4
1. Peter Coad, David North y Mark Mayfi eld, Modelos de objetos: estrategias, patrones y aplicaciones,
2nd Ed. (Englewood Cliffs, NJ: Prentice Hall, 1997).
2. Hans-Erik Eriksson y Magnus Penker, Business Modeling with UML: Patrones de negocios en el trabajo
(Nueva York: Wiley, 2000).
3. Martin Fowler, Patrones de análisis: Modelos de objetos reutilizables (Reading, MA: Addison-Wesley, 1997).
4. David C. Hay, Modelos de modelos de datos: Conventions of Thought (Nueva York, NY, Dorset House, 1996).

TARJETAS CRC

Las tarjetas CRC (Class-Responsibility-Collaboration) se usan para documentar las

responsabilidades y

colaboraciones de una clase. En algunas metodologías de desarrollo de sistemas orientadas a

objetos, CRC

se considera que las tarjetas son un competidor alternativo al empleo del Proceso Unificado de
casos de uso

y diagramas de clase. Sin embargo, los vemos como un enfoque útil y de baja tecnología que
puede complementar un enfoque típico de proceso de alta tecnología que utiliza herramientas
CASE. Usamos una extensión
formulario de la tarjeta CRC para capturar toda la información relevante asociada con una
clase.9 Describimos

los elementos de nuestras tarjetas CRC más adelante, después explicamos responsabilidades y
colaboraciones.

Responsabilidades y colaboraciones

Las responsabilidades de una clase se pueden dividir en dos tipos separados: saber y hacer.

Conocer las responsabilidades son aquellas cosas que una instancia de una clase debe ser
capaz de conocer.

Una instancia de una clase normalmente conoce los valores de sus atributos y sus relaciones.

Hacer responsabilidades son aquellas cosas que una instancia de una clase debe ser capaz de
hacer. En

este caso, una instancia de una clase puede ejecutar sus operaciones o puede solicitar una
segunda instancia,

que conoce, para ejecutar una de sus operaciones en nombre de la primera instancia.

El modelo estructural describe los objetos necesarios para respaldar los procesos comerciales

modelado por los casos de uso. La mayoría de los casos de uso involucran un conjunto de
varias clases, no solo una clase.

Estas clases forman colaboraciones. Las colaboraciones le permiten al analista pensar en

términos de clientes,

servidores y contratos.10 Un objeto cliente es una instancia de una clase que envía una
solicitud a un

instancia de otra clase para que se ejecute una operación. Un objeto de servidor es la instancia
que

recibe la solicitud del objeto del cliente. Un contrato formaliza las interacciones entre

objetos de cliente y servidor. El Capítulo 8 proporciona una explicación más detallada de los
contratos y

ejemplos de su uso.

Un analista puede usar la idea de las responsabilidades de clase y las colaboraciones cliente-
servidor-contrato

para ayudar a identificar las clases, junto con los atributos, operaciones y relaciones,

involucrado con un caso de uso. Una de las maneras más fáciles de usar tarjetas CRC en el
desarrollo de una estructura

el modelo es a través del antropomorfismo, pretendiendo que las clases tienen características
humanas.

Los miembros del equipo de desarrollo pueden hacerse preguntas o hacerse preguntas

preguntas de otros miembros del equipo. Por lo general, las preguntas son de la forma:
¿Quién o qué eres?

¿Que sabes?

¿Qué puedes hacer?

Las respuestas a las preguntas se usan luego para agregar detalles a las tarjetas CRC en
evolución. por

ejemplo, en el problema de la cita, un miembro del equipo puede pretender que él o ella es

cita. En este caso, la cita respondería que él o ella sabe sobre el doctor

y el paciente que participa en la cita y sabrían la fecha y la hora

de la cita. Además, una cita debería saber cómo crearse a sí misma,

eliminarse a sí mismo, y posiblemente cambiar diferentes aspectos de sí mismo. En algunos

casos, este enfoque

descubrir objetos adicionales que deben agregarse al modelo estructural en evolución.

Elementos de una tarjeta CRC

El conjunto de tarjetas CRC contiene toda la información necesaria para construir un modelo
lógico estructural

del problema bajo investigación. La figura 5-6 muestra una muestra de tarjeta CRC. Cada
captura de tarjeta CRC

y describe los elementos esenciales de una clase. El frente de la tarjeta contiene la clase

nombre, ID, tipo, descripción, casos de uso asociados, responsabilidades y colaboradores. El

nombre

de una clase debe ser un sustantivo (pero no un nombre propio, como el nombre de una
persona específica o

cosa). Al igual que en los casos de uso, en etapas posteriores de desarrollo, es importante
poder rastrear

respaldar decisiones de diseño con requisitos específicos. En conjunción con la lista de uso
asociado

En algunos casos, el número de ID de cada clase se puede usar para lograr esto. La descripción
es simplemente

una breve declaración que puede usarse como una definición textual para la clase. Las
responsabilidades de

la clase tiende a ser las operaciones que la clase debe contener (es decir, las responsabilidades
de hacer).

La parte posterior de una tarjeta CRC contiene los atributos y las relaciones de la clase. Los
atributos

de la clase representan las responsabilidades de conocimiento que cada instancia de la clase

tiene que cumplir.
Normalmente, el tipo de datos de cada atributo se enumera con el nombre del atributo (por
ejemplo, la cantidad

el atributo es doble y la compañía de seguros es texto). Estos tipos de relaciones suelen ser

capturado en este punto: generalización, agregación y otras asociaciones. En la figura 5-6,

vemos

que un paciente es un tipo de persona y que un paciente está asociado con citas.

Las tarjetas CRC se usan para documentar las propiedades esenciales de una clase. Sin
embargo, una vez

las cartas se completan, el analista puede usar las cartas y los antropomorfismos en el juego de
rol

(descrito en la siguiente sección) para descubrir las propiedades que faltan mediante la
ejecución de la diferencia

Muestra de tarjeta CRC

escenarios asociados con los casos de uso (ver Capítulo 4). El juego de roles también se puede
usar como

base para probar la claridad y la integridad de la representación evolutiva del sistema.

Role-Playing CRC Cards with Use Cases11, 12

Además de los enfoques de identificación de objetos descritos anteriormente (análisis textual,

tormenta de ideas,

listas de objetos comunes, y patrones), las tarjetas CRC se pueden usar en un ejercicio de role-
playing

que se ha demostrado que es útil para descubrir objetos adicionales, atributos, relaciones,

y operaciones. Además, además de tutoriales, que se describen más adelante en este capítulo,

El juego de roles es muy útil para probar la fidelidad del modelo estructural en evolución. En
general,

los miembros del equipo realizan roles asociados con los actores y objetos previamente
identificados con los diferentes casos de uso. Técnicamente hablando, los miembros del
equipo realizan las diferentes

pasos asociados con un escenario específico de un caso de uso. Recuerde, un escenario es

único,

ruta de ejecución única a través de un caso de uso. Un lugar útil para buscar los diferentes
escenarios de un

el caso de uso son los diagramas de actividad (p. ej., véanse las Figuras 4-8, 4-9, 4-10 y 4-12).
Un escenario diferente

existe para cada vez que un nodo de decisión causa una división en la ruta de ejecución del
caso de uso. También,
los escenarios se pueden identificar a partir de los flujos alternativos / excepcionales en una
descripción del caso de uso.

Teniendo en cuenta la naturaleza incremental e iterativa y los diagramas de actividad y caso de

uso

las descripciones deben contener la misma información, revisar ambas representaciones

asegurará

que los escenarios relevantes no se pierden

El primer paso es revisar las descripciones de los casos de uso (ver Figura 5-2). Esto permite al
equipo

elige un caso de uso específico para el juego de roles. Aunque es tentador tratar de completar
tantos usos

En la medida de lo posible en un corto tiempo, el equipo no debería elegir primero los casos de
uso más fáciles. En lugar,

En este punto del desarrollo del sistema, el equipo debe elegir el caso de uso que es el

más importante, el más complejo, o el menos entendido.

El segundo paso es identificar los roles relevantes que se van a jugar. Cada rol está asociado

con un actor o un objeto. Para elegir los objetos relevantes, el equipo revisa cada uno de los

Tarjetas CRC y elige las que están asociadas con el caso de uso elegido. Por ejemplo, en

La figura 5-6, vemos que la tarjeta CRC que representa la clase Old Patient está asociada con

Use el número de caso 2. Entonces, si vamos a representar el caso de uso de Make Old Patient
Appt (consulte

Figura 5-2), necesitaríamos incluir la tarjeta Old Patient CRC. Al revisar el caso de uso

descripción, podemos identificar fácilmente a los actores de Viejo Paciente y Doctor (ver Actor
Primario y

Sección de partes interesadas de la descripción del caso de uso en la Figura 5-2). Al leer la
sección de eventos de

la descripción del caso de uso, identificamos el rol del actor interno de Recepcionista. Después
de identificar

todas las funciones relevantes, asignamos cada una a un miembro diferente del equipo.

El tercer paso es representar los escenarios del caso de uso haciendo que los miembros del
equipo rindan

cada uno. Para hacer esto, cada miembro del equipo debe fingir que él o ella es una instancia

del papel asignado a él o ella. Por ejemplo, si a un miembro del equipo se le asignó el rol de

la recepcionista, entonces él o ella tendría que ser capaz de realizar los diferentes pasos en el

escenario asociado con la recepcionista. En el caso del escenario de cita de cambio,

esto incluiría los pasos 2, 5, 6, S-3, S-1 y S-2. Sin embargo, cuando se realiza este escenario

(role-played), se descubriría que los pasos 1, 3 y 4 estaban incompletos. Por ejemplo,

en el Paso 1, ¿qué ocurre en realidad? ¿El paciente hace una llamada telefónica? Si es así,
¿quién responde?

¿el teléfono? En otras palabras, mucha información contenida en la descripción del caso de
uso es

solo identificado de manera implícita, no explícita. Cuando la información no está identificada

explícitamente, hay mucho espacio para la interpretación, lo que requiere que los miembros
del equipo hagan

suposiciones. Es mucho mejor eliminar la necesidad de hacer una suposición haciendo cada

paso explícito En este caso, el paso 1 del flujo normal de eventos debe modificarse. Una vez el

el paso ha sido fijado, el escenario se prueba de nuevo. Este proceso se repite hasta que el
escenario pueda

ser ejecutado a una conclusión exitosa. Una vez que el escenario ha concluido con éxito, la

El próximo escenario se realiza. Th se repite hasta que todos los escenarios del caso de uso
puedan ser

realizado con éxito. 13

El cuarto paso es simplemente repetir los pasos 1 a 3 para los casos de uso restantes

Revisa los casos de uso

Identificar los actores y objetos relevantes

Juego de rol

Escenarios

Repita los pasos 1 a 3

DIAGRAMAS DE CLASE

Un diagrama de clases es un modelo estático que muestra las clases y las relaciones entre
clases

que permanecen constantes en el sistema a lo largo del tiempo. El diagrama de clase

representa las clases, que incluyen

ambos comportamientos y estados, con las relaciones entre las clases. Las siguientes secciones

presentar los elementos del diagrama de clases, diferentes enfoques que se pueden utilizar
para simplificar una

diagrama de clases, y un diagrama de estructura alternativo: el diagrama de objetos.

Elementos de un diagrama de clase

La Figura 5-7 muestra un diagrama de clase que fue creado para reflejar las clases y relaciones
asociado con el sistema de citas. Este diagrama está basado en las clases descubiertas

a través de las técnicas de identificación de objetos y el juego de roles de las tarjetas CRC

descrito anteriormente.

Clase El bloque de construcción principal de un diagrama de clases es la clase, que almacena y

administra

información en el sistema (vea la Figura 5-8). Durante el análisis, las clases se refieren a las
personas,

lugares y cosas sobre las cuales el sistema capturará información. Más tarde, durante el diseño

e implementación, las clases pueden referirse a artefactos específicos de implementación tales

como ventanas,

formularios y otros objetos utilizados para construir el sistema. Cada clase se dibuja usando un
threepart

rectángulo, con el nombre de la clase en la parte superior, atributos en el medio y operaciones

en el fondo. Podemos ver que las clases identificadas anteriormente, como Participante,
Doctor,

Paciente, recepcionista, historial médico, cita y síntoma, se incluyen en la figura

5-7. Los atributos de una clase y sus valores definen el estado de cada objeto creado a partir
de

clase, y el comportamiento está representado por las operaciones.

Los atributos son propiedades de la clase sobre la que queremos capturar información

(vea la Figura 5-8). Observe que la clase participante en la figura 5-7 contiene los atributos:

apellido, primer nombre, dirección, teléfono y fecha de nacimiento. A veces, es posible que
desee almacenar

atributos derivados, que son atributos que pueden calcularse o derivarse; estos especiales

los atributos se denotan colocando una barra inclinada (/) antes del nombre del atributo.
Observe cómo el

la clase de persona contiene un atributo derivado llamado / edad, que puede derivarse
sustrayendo

la fecha de nacimiento del paciente a partir de la fecha actual. También es posible mostrar la
visibilidad

del atributo en el diagrama. La visibilidad se relaciona con el nivel de información que se

esconde

impuesto por el atributo. La visibilidad de un atributo puede ser pública (+), protegida (#),

o privado (-). Un atributo público es aquel que no está oculto de ningún otro objeto. Como tal,
otros objetos pueden modificar su valor. Un atributo protegido es uno que está oculto de
todos los demás

clases excepto sus subclases inmediatas. Un atributo privado es uno que está oculto de todos

otras clases. La visibilidad predeterminada para un atributo es normalmente privada.

Las operaciones son acciones o funciones que una clase puede realizar (consulte la Figura 5-8).
Las funciones

que están disponibles para todas las clases (por ejemplo, crear una nueva instancia, devolver
un valor para un determinado

atributo, establecer un valor para un atributo en particular, eliminar una instancia) no se

muestran explícitamente

dentro del rectángulo de la clase. En cambio, solo se incluyen operaciones exclusivas de la

clase, tales

como la operación cancelar sin aviso en la clase Cita y calcular la última visita

operación en la clase de Paciente en la Figura 5-7. Observe que ambas operaciones son
seguidas por

paréntesis, que contienen los parámetros necesarios para la operación. Si una operación no
tiene

parámetros, los paréntesis todavía se muestran pero están vacíos. Al igual que con los
atributos, la visibilidad

de una operación se puede designar pública, protegida o privada. La visibilidad

predeterminada para un

la operación es normalmente pública.

Hay cuatro tipos de operaciones que una clase puede contener: constructor, consulta,
actualización,

y destructor. Una operación de constructor crea una nueva instancia de una clase. Por
ejemplo, el

la clase de paciente puede tener un método llamado insert (), que crea una nueva instancia de
paciente como

Una clase:
• Tiene un nombre escrito en negrita y centrado en su parte superior
compartimiento.
• Tiene una lista de atributos en su compartimento central.
• Representa un tipo de persona, lugar o cosa sobre
que el sistema necesitará capturar y almacenar
información.
• Tiene una lista de operaciones en su compartimento inferior.
Nombre del Atributo
/ nombre del atributo derivado
nombre de operación ()
• No muestra explícitamente operaciones que son
disponible para todas las clases.
Un atributo:
• Representa propiedades que describen el estado de un
objeto.
• Puede derivarse de otros atributos, mostrados por
colocando una barra antes del nombre del atributo.
Una operación:
• Representa las acciones o funciones que una clase
Sintaxis del Diagrama de Clase

Una operación de actualización cambia el valor de algunos o todos los atributos del objeto,
que pueden

provocar un cambio en el estado del objeto. Considere cambiar el estado de un paciente de

nuevo

a la corriente con un método llamado estado de cambio () o asociar a un paciente con un

particular

cita con cita (cita). Si el resultado de la operación puede

cambiar el estado del objeto, entonces la operación debe incluirse explícitamente en la clase

diagrama. Por otro lado, si la operación de actualización es una operación de asignación

simple, puede
ser omitido del diagrama.

Una operación de destrucción simplemente elimina o elimina el objeto del sistema. Por
ejemplo,

si un objeto empleado ya no representa un empleado real asociado con la empresa,

el empleado podría necesitar ser eliminado de la base de datos de empleados, y una operación
de destrucción

se usaría para implementar este comportamiento. Sin embargo, eliminar un objeto es uno de
los básicos

funciones y, por lo tanto, no se incluirán en el diagrama de clases.

Relaciones

Un objetivo principal de un diagrama de clases es mostrar las relaciones, o asociaciones,

que las clases tienen entre sí. Estos se representan en el diagrama mediante un dibujo

líneas entre clases (ver Figura 5-8). Cuando varias clases comparten una relación (o una

la clase comparte una relación consigo misma), se dibuja una línea y se etiqueta con el nombre
de

la relación o los roles que las clases juegan en la relación. Por ejemplo, en la figura

5-7 las dos clases paciente y cita se asocian entre sí cada vez que

un paciente programa una cita. Nosotros, una línea etiquetada como horarios conecta al
paciente y

cita, que representa exactamente cómo las dos clases están relacionadas entre sí. Además,
aviso

que hay un pequeño triángulo sólido al lado del nombre de la relación. El triángulo permite

una dirección para asociar con el nombre de la relación. En la figura 5-7, los horarios

relación incluye un triángulo, lo que indica que la relación debe leerse como "paciente

programa la cita. "La inclusión del triángulo simplemente aumenta la legibilidad del

diagrama. En la figura 5-9, se representan tres ejemplos adicionales de asociaciones: una

factura

se asocia con una orden de compra (y viceversa), un piloto vuela una aeronave y un repuesto

Tire está ubicado en un tronco.

A veces una clase se relaciona consigo misma, como en el caso de un paciente que es el seguro
primario

portador para otros pacientes (por ejemplo, cónyuge, hijos). En la Figura 5-7, observe que una
línea era

dibujado entre la clase del paciente y sí mismo y llamado compañía de seguros primaria para
representar
el papel que la clase juega en la relación. Observe que un signo más (+) se coloca antes

la etiqueta para comunicar que es un rol en lugar del nombre de la relación. Cuando

etiquetando una asociación, usamos un nombre de relación o un nombre de función (no

ambos), cualquiera que sea

comunica una comprensión más completa del modelo.

Asociación de muestra

Las relaciones también tienen multiplicidad, que documenta cómo una instancia de un objeto
puede

estar asociado con otras instancias. Los números se colocan en la ruta de asociación para
denotar el

instancias mínimas y máximas que se pueden relacionar a través de la asociación en el formato

número mínimo .. número máximo (vea la Figura 5-10). Los números especifican la relación

de la clase al final de la línea de relación hasta el final con el número. Por ejemplo,

en la figura 5-7, hay un 0 .. * en la cita de la cita de citas del paciente

relación. Esto significa que un paciente puede asociarse con cero a través de muchas
diferencias

equipo. En el extremo paciente de esta misma relación, hay un 1..1, lo que significa que

la cita debe estar asociada con uno y solo un paciente. En la figura 5-9, vemos que

una instancia de la clase de Factura debe asociarse con una instancia de la orden de compra

clase y que una instancia de la clase de orden de compra puede asociarse con cero o más

instancias de la clase Factura, que una instancia de la clase Piloto vuela cero o más instancias

de la clase de Aviones, y que una instancia de la clase de Aviones puede volar por cero o más

instancias de la clase Piloto. Finalmente, vemos que una instancia de la clase Spare Tire
IsLocatedIn

cero o una instancia de la clase Trunk, mientras que una instancia de la clase Trunk puede
contener

cero o una instancia de la clase Spare Tire.

Hay momentos en que una relación en sí tiene propiedades asociadas, especialmente cuando

las clases comparten una relación de muchos a muchos. En estos casos, una clase llamada una
clase de asociación

se forma, que tiene sus propios atributos y operaciones.14 Se muestra como un rectángulo
adjunto

Multiplicidad
por una línea discontinua a la ruta de asociación, y el nombre del rectángulo coincide con la
etiqueta de la

asociación. Tinta sobre el caso de capturar información sobre enfermedades y síntomas.

Una enfermedad (por ejemplo, la gripe) puede asociarse con muchos síntomas (por ejemplo,
dolor de garganta, fiebre),

y un síntoma (por ejemplo, dolor de garganta) puede asociarse con muchas enfermedades (p.
ej., la gripe, el estreptococo)

garganta, el resfriado común). La Figura 5-7 muestra cómo una clase de asociación puede
capturar información

sobre los remedios que cambian dependiendo de las diversas combinaciones. Por ejemplo, un

El dolor de garganta causado por la faringitis estreptocócica requiere antibióticos, mientras

que el tratamiento para el dolor de garganta

de la gripe o un resfriado pueden ser pastillas para la garganta o té caliente. Otra forma de
decidir cuándo

usar una clase de asociación es cuando los atributos que pertenecen a la intersección de las
dos clases

involucrado en la asociación debe ser capturado. Podemos pensar visualmente sobre una
asociación

clase como un diagrama de Venn. Por ejemplo, en la Figura 5-11, la idea de Grado es
realmente una intersección

de las clases de Estudiante y Curso, porque una calificación existe solo en la intersección de
estos

dos ideas Otro ejemplo que se muestra en la Figura 5-11 es que un trabajo se puede ver como
la intersección

entre una Persona y una Compañía. La mayoría de las clases están relacionadas a través de una
normal

asociación; Sin embargo, hay dos casos especiales de una asociación que verá aparecer

bastante a menudo: generalización y agregación.

Generalización y asociaciones de agregación

Una asociación de generalización muestra que

una clase (subclase) hereda de otra clase (superclase), lo que significa que las propiedades

y las operaciones de la superclase también son válidas para los objetos de la subclase. La
generalización

la ruta se muestra con una línea continua desde la subclase hasta la superclase y una flecha
hueca apuntando

en la superclase (ver Figura 5-8). Por ejemplo, la Figura 5-7 comunica que los médicos,
las enfermeras y recepcionistas son todo tipo de empleados y esos empleados y pacientes son

tipos de participantes. Recuerde que la relación de generalización ocurre cuando lo necesita

usar palabras como "es un tipo de" para describir la relación. Algunos ejemplos adicionales de

la generalización se da en la figura 5-12. Por ejemplo, Cardinal es un tipo de Bird, que es

un tipo de Animal; un médico general es un tipo de médico, que es un tipo de persona;

y un camión es un tipo de vehículo terrestre, que es un tipo de vehículo.

Se usa una asociación de agregación cuando las clases realmente comprenden otras clases. por

Por ejemplo, piense en la oficina de un médico que ha decidido crear equipos de atención
médica que

incluye médicos, enfermeras y personal administrativo. Cuando los pacientes ingresan a la

oficina, son

asignado a un equipo de atención médica, que se preocupa por sus necesidades durante sus
visitas. Podríamos

Clases de muestra de asociación

incluir este nuevo conocimiento en la Figura 5-7 agregando dos nuevas clases (Administrativo

Personal y Equipo de Salud) y las relaciones de agregación del Doctor, la Enfermera,

y las nuevas clases de Personal Administrativo para la nueva clase del Equipo de Salud. Un
diamante

se coloca más cerca de la clase que representa la agregación (equipo de atención médica), y las
líneas son

extraído del diamante para conectar las clases que sirven como sus partes (médicos,
enfermeras y

personal administrativo). Por lo general, puede identificar este tipo de asociaciones cuando

necesita usar palabras como "es parte de" o "está hecho de" para describir la relación. Sin
embargo,

desde una perspectiva UML, hay dos tipos de asociaciones de agregación: agregación y

composición (vea la Figura 5-8).

La agregación se usa para representar relaciones lógicas de una parte y se representa en un

UML

Diagrama de clase por un diamante hueco o blanco. Por ejemplo, en la figura 5-13, tres lógicos

Generalizaciones de muestra

agregaciones se muestran. Lógico implica que es posible que una parte se asocie con

múltiples enteros o eso es relativamente simple para que la parte sea eliminada del todo. por
ejemplo, una instancia de la clase Empleado IsPartOf una instancia de al menos una instancia
del

Clase de departamento, una instancia de la clase Wheel IsPartOf una instancia de la clase
Vehicle,

y una instancia de la clase Desk IsPartOf una instancia de la clase Office. Obviamente, en
muchos

Cuando un empleado puede estar asociado con más de un departamento, es relativamente

fácil

para quitar una rueda de un vehículo o mover un escritorio de una oficina.

La composición se utiliza para retratar una parte física de las relaciones y se muestra por un
negro

diamante. Física implica que la parte se puede asociar con un solo todo. Por ejemplo

en la figura 5-14, se ilustran tres composiciones físicas: una instancia de una puerta puede ser
una

como parte de una sola instancia de un automóvil, una instancia de una habitación puede ser
parte de una instancia solo de

un solo edificio, y una instancia de un botón puede ser parte de un solo mouse. Sin embargo,
en

En muchos casos, la distinción que puede lograr incluye la agregación (diamantes blancos)

y la composición (diamantes negros) en un diagrama de clase podría no valer el precio de

agregar

notación gráfica adicional para que el cliente aprenda. Por lo tanto, muchos expertos de UML
ven

la inclusión de la notación de agregación y composición en el diagrama de clase UML como

simplemente

"Azúcar sintáctico" y no es necesario porque la misma información siempre puede ser

retratada por

simplemente usando la sintaxis de asociación.

Ejemplos de asociaciones de agregación

Asociaciones de composición de muestra

Simplificando Diagramas de Clase

Cuando un diagrama de clases está completamente poblado con todas las clases y relaciones
para un mundo real

sistema, el diagrama de clases puede ser muy difícil de interpretar (es decir, puede ser muy

complejo). Cuando esto ocurre, a veces es necesario simplificar el diagrama. De una sola mano
simplificar el diagrama de clases es mostrar solo clases concretas.15 Sin embargo,
dependiendo del

número de asociaciones que están conectadas a clases abstractas y, por lo tanto, heredadas
hasta

las clases concretas: esta sugerencia particular podría hacer que el diagrama sea más difícil de

comprender.

Una segunda forma de simplificar el diagrama de clases es a través del uso de un mecanismo
de visualización.

Las vistas se desarrollaron originalmente con sistemas de administración de bases de datos

relacionales para mostrar solo

un subconjunto de la información contenida en la base de datos. En este caso, la vista sería útil

subconjunto del diagrama de clases, como una vista de caso de uso que muestra solo las clases
y las relaciones

relevante para un caso de uso particular. Una segunda vista podría ser mostrar solo un tipo
particular

de relación: agregación, asociación o generalización. Un tercer tipo de vista es restringir

la información que se muestra con cada clase, por ejemplo, muestra solo el nombre de la
clase, el

nombre y atributos, o el nombre y las operaciones. Estos mecanismos de vista se pueden

combinar

para simplificar aún más el diagrama.

Un tercer enfoque para simplificar un diagrama de clases es mediante el uso de paquetes (es
decir,

grupos lógicos de clases). Para que los diagramas sean más fáciles de leer y mantener los
modelos en una

nivel razonable de complejidad, las clases se pueden agrupar en paquetes. Paquetes

son construcciones generales que se pueden aplicar a cualquiera de los elementos en los
modelos UML. En

En el Capítulo 4, presentamos la idea del paquete para simplificar los diagramas de casos de
uso. En el caso de

diagramas de clases, es simple ordenar las clases en grupos en función de las relaciones que

ellos comparten.16

Diagramas de objetos

Aunque los diagramas de clase son necesarios para documentar la estructura de las clases, un
segundo
tipo de diagrama de estructura estática, llamado diagrama de objeto, puede ser útil para
revelar

información. Un diagrama de objetos es esencialmente una instancia de toda o parte de una

clase

diagrama. La creación de instancias significa crear una instancia de la clase con un conjunto de

valores de atributo.

Los diagramas de objetos pueden ser muy útiles al tratar de descubrir detalles de una clase. En
general

hablando, es más fácil pensar en términos de objetos concretos (instancias) en lugar de

abstracciones

de objetos (clases). Por ejemplo, en la Figura 5-15, una parte del diagrama de clases en

La Figura 5-7 ha sido copiada e instanciada. La parte superior de la figura simplemente es una
copia

de una pequeña vista del diagrama de clase general. La parte inferior es el diagrama de objetos
que

crea una instancia de ese subconjunto de clases. Al revisar las instancias reales involucradas,
John Doe,

Appt1, Symptom1 y Dr. Smith, podemos descubrir atributos relevantes adicionales, relaciones,

y / u operaciones o atributos, relaciones y / u operaciones posiblemente fuera de lugar.

Por ejemplo, una cita tiene un atributo de razón. Tras un examen más detallado, la razón

atributo podría haberse modelado mejor como una asociación con la clase Síntoma.

Actualmente, la clase Symptom está asociada a la clase Patient. Después de revisar el objeto

diagrama, esto parece estar en error. Por lo tanto, debemos modificar el diagrama de clases
para reflejar

esta nueva comprensión del problema.

Diagrama de objeto de muestra

CREAR MODELOS ESTRUCTURALES USANDO TARJETAS CRC

Y DIAGRAMAS DE CLASE

Crear un modelo estructural es un proceso incremental e iterativo mediante el cual el analista

realiza un corte aproximado del modelo y luego lo refinancia con el tiempo. Los modelos
estructurales pueden convertirse

bastante complejo; de hecho, hay sistemas que tienen cientos de clases. Es importante

recuerde que las tarjetas CRC y los diagramas de clases se pueden usar para describir tanto el
tal como es y
modelos estructurales futuros del sistema en evolución, pero en la mayoría de los casos se
utilizan para el futuro

modelo. Hay muchas formas diferentes de identificar un conjunto de objetos candidatos y

crear

Tarjetas CRC y diagramas de clases. Hoy la mayoría de las identificaciones de objetos

comienzan con los casos de uso

identificado para el problema (ver Capítulo 4). En esta sección, describimos un caso de uso
impulsado

proceso que puede usarse para crear el modelo estructural de un dominio problemático.

Podríamos comenzar a crear el modelo estructural con un diagrama de clases en lugar de

tarjetas CRC.

Sin embargo, debido a la naturaleza de baja tecnología y la facilidad de los escenarios de uso
de roles de juego de roles

con tarjetas CRC, preferimos crear primero las tarjetas CRC y luego transferir la información

de las tarjetas CRC en un diagrama de clase más tarde. Como resultado, el primer paso de
nuestra recomendación

proceso es crear tarjetas CRC. Realización de análisis textuales en el caso de uso

descripciones hace esto. Si recuerda, el flujo normal de eventos, subflujos y alternativas /

los flujos excepcionales de la descripción del caso de uso se escribieron en una forma especial
llamada Subject-

Verb-Direct-Object-Preposition-Objeto indirecto (SVDPI). Al escribir los eventos de caso de uso

de esta forma, es más fácil usar las pautas para el análisis textual en la Figura 5-1 para
identificar

los objetos. Revisión de los principales actores, partes interesadas e intereses, y breves
descripciones

de cada caso de uso permite que se identifiquen objetos candidatos adicionales. Es útil volver

y revisar los requisitos originales para buscar información que no estaba incluida en el

texto de los casos de uso. Registre toda la información descubierta para cada objeto candidato
en un

Tarjeta CRC

El segundo paso es revisar las tarjetas CRC para determinar si hay objetos candidatos
adicionales,

atributos, operaciones y relaciones faltan. En conjunto con esta revisión, usando

los enfoques de la lluvia de ideas y la lista de objetos comunes descritos anteriormente pueden
ayudar al equipo en

identifica clases faltantes, atributos, operaciones y relaciones. Por ejemplo, el equipo

podría comenzar una lluvia de ideas con una serie de preguntas como:

■ ¿Cuáles son las cosas tangibles asociadas con el problema?

■ ¿Cuáles son los roles desempeñados por las personas en el dominio del problema?

■ ¿Qué incidentes e interacciones tienen lugar en el dominio del problema?

Como puede ver fácilmente, al comenzar con las descripciones de los casos de uso, muchas de
estas preguntas

ya tiene respuestas parciales Por ejemplo, los actores principales y las partes interesadas son
los roles que

son jugado por las personas en el dominio del problema. Sin embargo, es posible descubrir

roles no pensados previamente. Es obvio que esto causaría las descripciones del caso de uso, y
posiblemente

el diagrama de caso de uso, para modificar y posiblemente expandir. Como en el paso anterior,
asegúrese

para registrar toda la información descubierta en las tarjetas CRC. Th incluye cualquier modifi
cación

descubierto para cualquier objeto candidato previamente identificado y cualquier información

con respecto a cualquier

nuevos objetos candidatos identificados

El tercer paso es representar roles en cada caso de uso con las tarjetas CRC. Cada tarjeta CRC

debe asignarse a un individuo que realizará las operaciones para la clase en el CRC

tarjeta. A medida que los artistas interpretan sus roles, el sistema tiende a descomponerse.
Cuando esto ocurre,

objetos adicionales, atributos, operaciones o relaciones serán identificados. De nuevo, como

en el

pasos anteriores, cada vez que se descubre información nueva, se crean nuevas tarjetas CRC o

se realizan modificaciones a las tarjetas CRC existentes.

El cuarto paso es crear el diagrama de clases basado en las tarjetas CRC. Información contenida

en las tarjetas CRC se transfiere a los diagramas de clase. Las responsabilidades se transfieren

como operaciones; los atributos se dibujan como atributos; y las relaciones están dibujadas

como generalización, agregación o relaciones de asociación. Sin embargo, el diagrama de clase

también requiere que se conozca la visibilidad de los atributos y las operaciones. Como general

regla, los atributos son privados y las operaciones son públicas. Por lo tanto, a menos que el
analista tenga un

Crear tarjetas CRC

Revisa las tarjetas CRC

Role-Play las tarjetas CRC

Crear diagrama de clase

Revisar Diagrama de Clase

Incorporar patrones

Revise el modelo

una buena razón para cambiar la visibilidad predeterminada de estas propiedades, entonces
los valores predeterminados deberían

ser aceptado. Finalmente, el analista debe examinar el modelo para oportunidades adicionales
para

usar relaciones de agregación o generalización. Estos tipos de relaciones pueden simplificar

las descripciones de clases individuales. Como en los pasos anteriores, todos los cambios
deben registrarse

en las tarjetas CRC.

El quinto paso es revisar el modelo estructural para clases faltantes y / o innecesarias,

atributos,

operaciones y relaciones. Hasta este paso, el enfoque del proceso ha estado en agregar

información al modelo en evolución. En este punto, el enfoque comienza a cambiar de

simplemente

agregar información para también cuestionar las razones por las cuales se incluye la
información contenida

en el modelo. Un enfoque muy útil aquí es hacer de abogado del diablo, donde un miembro
del equipo,

solo por ser un dolor en el cuello, desafía el razonamiento para incluir todos los aspectos

del modelo.

El sexto paso es incorporar patrones útiles en el modelo estructural en evolución. Un útil

patrón es aquel que permitiría al analista describir más completamente el dominio subyacente
de

el problema está siendo investigado Mirando la colección de patrones disponibles (Figura 5-5)

y comparar las clases contenidas en los patrones con aquellos en el diagrama de clase en
evolución

habilitar esto Después de identificar los patrones útiles, el analista incorpora la identificación

edió patrones en el diagrama de clases y modificó las tarjetas CRC afectadas. Esto incluye

agregar y eliminar clases, atributos, operaciones y / o relaciones.

El séptimo y último paso es validar el modelo estructural, incluidas las tarjetas CRC

y el diagrama de clase. Discutimos este contenido en la siguiente sección del capítulo y en

Capítulo 7.

Ejemplo de Vivienda del Campus

En el capítulo anterior, identificamos un conjunto de casos de uso (Agregar un apartamento,

Eliminar un

Apartamento, y Buscar unidades de alquiler disponibles) para el servicio de alojamiento del

campus que ayuda

los estudiantes encuentran apartamentos. Al revisar los casos de uso, podemos determinar
fácilmente que el campus

El servicio de vivienda debe llevar un registro de la información de cada apartamento

disponible y su

propietario. La información que se debe capturar para cada apartamento es la ubicación del
apartamento,

el número de habitaciones en el departamento, el alquiler mensual y cuán lejos está el

apartamento

del campus En cuanto al propietario del apartamento, necesitamos capturar el propietario

información de contacto (por ejemplo, nombre, dirección, número de teléfono, dirección de

correo electrónico). Desde estudiantes

son simplemente usuarios del sistema, no es necesario capturar ninguna información sobre
ellos;

es decir, en este caso, los estudiantes son simplemente actores. Finalmente, con respecto a las
relaciones entre

las clases, existe una relación de asociación única, opcional, de uno a muchos, que vincula el

dos clases juntas. La tarjeta CRC del propietario del apartamento se muestra en la figura 5-16,
y el

el diagrama de clases para esta situación se muestra en la Figura 5-17.

Ejemplo de biblioteca

Al igual que con el ejemplo de Campus Housing, el primer paso es crear las tarjetas CRC que
representan

las clases en el modelo estructural. En el capítulo anterior, utilizamos el Libro de la Biblioteca

Ejemplo del sistema de gestión de colecciones para describir el proceso de creación de

funcional

modelos (caso de uso y diagramas de actividad y descripciones de casos de uso). En este

capítulo, seguimos

el mismo ejemplo familiar. Porque estamos siguiendo un enfoque basado en casos de uso para
desarrollo de sistemas orientados a objetos, primero revisamos los eventos descritos en el
caso de uso

descripciones (ver Figura 5-18).

Vivienda del campus

Propietario de apartamento

Tarjeta CRC

Diagrama de clase de la vivienda del campus

A continuación, realizamos un análisis textual de los eventos aplicando las reglas de análisis
textual

descrito en la Figura 5-1. En este caso, podemos identificar rápidamente la necesidad de incluir
clases

para prestatario, libros, bibliotecario, mostrador de salida, tarjeta de identificación, estudiante

prestatario, facultad /

Empleado Prestatario, Prestatario Invitado, Base de Datos de Registrador, Base de Datos de

Personal, Biblioteca

Base de datos de invitados, Libros atrasados, Multas, Solicitud de libros. También podemos
identificar operaciones fácilmente

para "verificar la validez" de una solicitud de libro, para "verificar" los libros, y para "rechazar"
un

solicitud de libro Además, los eventos sugieren una relación "trae" entre el Prestatario

y Libros y una relación de "entrega" entre el Prestatario y el Bibliotecario. Este paso

Flujo normal de eventos:

Subflujos:
1. El prestatario trae libros al bibliotecario en el mostrador de check-out.
2. El Prestatario proporciona a la Bibliotecaria su tarjeta de identificación.
3. El bibliotecario verifica la validez de la tarjeta de identificación.
Si el Prestatario es un Prestatario del Estudiante, Valide la Tarjeta de Identificación contra la Base de Datos del Registrador.
Si el Prestatario es un Prestatario del Personal / Facultad, Valide la Tarjeta de Identificación contra la Base de Datos del
Personal.
Si el Prestatario es un Prestatario Invitado, Valide la Tarjeta de Identificación contra la Base de Datos de Invitados de la
 Nombre del caso de uso:
Actor principal:
Interesados e intereses:
Breve descripción:
ID: Nivel de importancia:
Desencadenar:
Tipo: Externo
Usar tipo de caso:
Relaciones:
Borrow Books 2 High
Prestatario
El prestatario trae libros para revisar el escritorio.
Detalle, esencial
Este caso de uso describe cómo se sacan libros de la biblioteca.
Prestatario: quiere sacar libros
Bibliotecario: quiere asegurarse de que el prestatario solo reciba los libros
FIGURA 5-19 Descripción general para el caso de uso de libros prestados (figura 4-20)

también sugiere que deberíamos revisar la sección de descripción general de la descripción del
caso de uso (ver

Figura 5-19). En este caso, la única información adicional obtenida del caso de uso

descripción es la posible inclusión de clases para la Oficina de Personal y la Oficina de Registro.

Este mismo proceso también se completará para los casos de uso restantes contenidos en

modelo funcional: procesar libros vencidos, mantener la colección de libros, buscar colección,

y Libros de Devolución (vea la Figura 4-6). Como no discutimos estos casos de uso en el
anterior

capítulo, revisaremos la descripción del problema como base para comenzar el siguiente paso
(ver

Figura 5-20).
 Los requisitos funcionales para un sistema automatizado de circulación de bibliotecas universitarias incluyen el
necesidad de apoyar las actividades de búsqueda, préstamo y mantenimiento de libros. El sistema debería
ayuda para buscar por título, autor, palabras clave e ISBN. Buscando en la base de datos de la colección de la biblioteca
debería estar disponible en las terminales de la biblioteca y disponible para posibles prestatarios a través del mundo
Banda ancha. Si el libro de interés está actualmente prestado, se debe permitir a un prestatario válido
para solicitar que el libro sea devuelto. Una vez que el libro ha sido devuelto, el prestatario
se debe notificar a la solicitud del libro la disponibilidad del libro.
Las actividades de endeudamiento se basan en chequear libros y devolver libros
por los prestatarios. Hay tres tipos de prestatarios: estudiantes, profesores y personal, e invitados.
Independientemente del tipo de prestatario, el prestatario debe tener una tarjeta de identificación válida. Si el prestatario
es un estudiante, tener la verificación del sistema con la base de datos de estudiantes del registrador valida la identificación
tarjeta. Si el prestatario es un miembro de la facultad o del personal, haga que el sistema verifique con el personal
La base de datos de empleados de la oficina valida la tarjeta de identificación. Si el prestatario es un invitado, la tarjeta de
identificación es
comprobado con la base de datos de prestatarios de la biblioteca. Si la tarjeta de identificación es válida, el sistema debe
también verifique para determinar si el prestatario tiene libros atrasados o multas no pagadas. Si la ID
la tarjeta no es válida, el prestatario tiene libros vencidos, o el prestatario tiene multas no pagadas, el sistema
debe rechazar la solicitud del prestatario de sacar un libro; de lo contrario, la solicitud del prestatario
debe ser honrado. Si se saca un libro, el sistema debe actualizar la colección de la biblioteca
base de datos para reflejar el nuevo estado del libro.
Las actividades de mantenimiento de libros se ocupan de agregar y eliminar libros de la biblioteca
colección de libros. Esto requiere que el administrador de la biblioteca agregue lógica y físicamente y
quitar el libro Libros comprados por la biblioteca o libros devueltos en un sitio dañado
estado típicamente causa estas actividades. Si se determina que un libro está dañado cuando se devuelve
y debe ser eliminado de la colección, el último prestatario será evaluado como tal.
Sin embargo, si el libro puede ser reparado, dependiendo del costo de la reparación, el prestatario podría
no se evaluará como una multa Finalmente, todos los lunes, la biblioteca envía correos electrónicos recordatorios a los
prestatarios
que tienen libros vencidos. Si un libro está vencido más de dos semanas, el prestatario es evaluado
una multa. Dependiendo de cuánto tiempo el libro esté vencido, el prestatario puede ser evaluado
Fines adicionales todos los lunes.

Descripción general del sistema de gestión de la colección de libros de la biblioteca

El segundo paso es revisar las tarjetas CRC para determinar si hay alguna información

desaparecido. En el caso del sistema bibliotecario, porque solo usamos los libros prestados

descripción del caso de uso, obviamente falta información. Al revisar la Figura 5-20,

vemos que debemos incluir la posibilidad de buscar en la colección de libros por título, autor,

palabras clave e ISBN. Esto obviamente implica una clase de colección de libros con cuatro
diferencias

operaciones de búsqueda: búsqueda por título, búsqueda por autor, búsqueda por palabras
clave y búsqueda por

ISBN. Curiosamente, la descripción también implica un conjunto de subclases o estados para el

Clase de libro: desprotegido, vencido, solicitado, disponible y dañado. Volveremos

a la cuestión de estados versus subclases en el próximo capítulo. La descripción implica
muchos

operaciones adicionales, incluidos Libros de vuelta, Solicitud de libros, Agregar libros,

Eliminación de libros, reparación de libros, reducción de prestatarios y recordatorios por

correo electrónico.

A continuación, debemos usar nuestra propia experiencia de biblioteca para generar una lluvia
de ideas potencial adicional

clases, atributos, operaciones y relaciones que podrían ser útiles para incluir en

Sistema de gestión de colección de libros de biblioteca. En nuestra biblioteca, también existe la

necesidad de

Recuperar libros del almacenamiento, mover libros al almacenamiento, solicitar libros de la

biblioteca interbibliotecaria

Sistema de préstamos, devolución de libros al sistema de préstamos interbibliotecarios y trato

con libros electrónicos. Tú

también podría incluir clases para Revistas, DVD y otros medios. Como puedes ver, muchos

clases, atributos, operaciones y relaciones pueden ser identificadas.

El tercer paso, el juego de roles de las tarjetas CRC, requiere que apliquemos los tres juegos de
rol

pasos descritos anteriormente:

■ Revisar casos de uso

■ Identificar actores y objetos relevantes

■ Escenarios de juego de roles

Para nuestros propósitos, usaremos el caso de uso de Libros prestados para demostrar. Lo
relevante

Los actores incluyen a los Prestatarios de Estudiantes, Prestatarios de Facultad / Personal,

Prestatarios Invitados, Bibliotecarios,

Oficina de Personal y Oficina de Registraduría. Esto se puede deducir fácilmente del resumen

sección de la descripción del caso de uso (ver Figura 5-19) y el diagrama de casos de uso (ver
Figura

4-6). Los objetos relevantes parecen incluir Libros, Prestatario y Tarjeta de identificación.
Finalmente, para

role-play los escenarios, tenemos que asignar los roles a los diferentes miembros del equipo

e intente realizar cada una de las rutas a través de los eventos del caso de uso (consulte la
Figura 5-18).

Basado en los Eventos del caso de uso y el diagrama de actividad del caso de uso (ver Figura 5-
21),
podemos identificar rápidamente nueve escenarios, tres para cada tipo de Prestatario
(Estudiante, Facultad /

Personal e Invitado): identificación válida y libros atrasados y sin multas, identificación válida
solamente y sin validez.

CARNÉ DE IDENTIDAD. Al interpretar estos escenarios, surge una pregunta: ¿qué sucede con
los libros que

se solicitan cuando se rechaza la solicitud? Con base en el funcional y estructural actual

modelos, los libros se dejan sentados en el mostrador de salida. Esto no parece del todo
correcto. En

realidad, los libros se vuelven a guardar. De hecho, la noción de volver a guardar libros
también es relevante para

cuando los libros se devuelven o cuando se reparan los libros. Además, la idea de

agregar libros a la colección también debe incluir la operación de archivar los libros. Como

debería ver fácilmente, la construcción de modelos estructurales también ayudará a descubrir

el comportamiento que fue

omitido al construir los modelos funcionales. Recuerde, desarrollo de sistemas orientados a

objetos

no solo está dirigido a casos de uso, sino que también es incremental e iterativo.

El cuarto paso es juntar todo y dibujar el diagrama de clases. Figura 5-22

representa el primer corte en el dibujo del diagrama de clases para la gestión de la colección
de libros de la biblioteca

Sistema. Las clases identificadas en los pasos anteriores se han vinculado con otras clases
mediante asociación,

agregación y relaciones de generalización. Para simplificar, solo mostramos el

clases y sus relaciones; no sus atributos, operaciones o incluso las multiplicidades en el

relaciones de asociación.

Diagrama de actividad para el caso de uso de libros prestados

(Figura 4-12)

El quinto paso es revisar cuidadosamente lo que se ha creado. No solo debes mirar

para las clases, atributos, operaciones y / o relaciones que faltan, pero también debe

desafiar cada aspecto del modelo actual. Específicamente, ¿hay clases, atributos,

operaciones y / o relaciones que deberían eliminarse del modelo? Si es así, puede

ser clases en el diagrama que deberían haberse modelado como atributos. Por ejemplo, el

Los ID de Estudiante, Fac / Personal e Invitado deben haber sido atributos con sus respectivas
clases.
Además, como se trata de un sistema de gestión de colecciones de libros, la inclusión de otros

los medios parecen ser inapropiados. Finalmente, la Oficina de Personal y la Oficina de

Registro son

en realidad solo actores en el sistema, no objetos. En base a todas estas eliminaciones, una
nueva versión

del diagrama de clase fue dibujado (ver Figura 5-23). Este diagrama es mucho más simple y
fácil

comprender.

El sexto paso, que incorpora patrones útiles, nos permite aprovechar el conocimiento

que fue desarrollado en otro lugar. En este caso, el patrón utilizado en el problema de la
biblioteca incluye

demasiadas ideas que no son relevantes para el problema actual. Sin embargo, mirando hacia
atrás a

La figura 5-3, vemos que uno de los patrones originales (el lugar, la transacción, el participante,

El ítem de línea de transacción y el patrón de ítem, vea la parte superior izquierda de la figura,
son relevantes. Nosotros

incorpore ese patrón en el diagrama de clase reemplazando el lugar por el mostrador de

salida,

Participante del Prestatario, Transacción por Transferencia y Artículo por Libro (Figura 5-24).

Técnicamente hablando, cada uno de estos reemplazos es simplemente un patrón

personalizado para el

problema a mano. También agregamos la clase de elemento de línea de transacción que

habíamos perdido en

el modelo estructural original.

El séptimo paso es revisar el estado actual del modelo estructural. No hace falta decir que el

La versión de la tarjeta CRC y la versión del diagrama de clases ya no están de acuerdo entre sí.

Volvemos a este paso en la próxima sección del capítulo.

Diagrama de clase de segundo corte para el sistema de colección de libros de la biblioteca

VERIFICANDO Y VALIDANDO EL MODELO ESTRUCTURAL

Antes de pasar a la creación de modelos de comportamiento (ver Capítulo 6) del dominio del
problema,

necesitamos verificar y validar el modelo estructural. En el capítulo anterior, presentamos

la noción de tutoriales como una forma de verificar y validar los procesos de negocios y
funcionales
modelos. En este capítulo, combinamos recorridos con el poder de los juegos de rol como una
forma

para verificar y validar completamente el modelo estructural que subyace en el negocio

procesos y modelos funcionales. De hecho, todos los enfoques de identificación de objetos

descritos

en este capítulo puede verse como una forma de probar la fidelidad del modelo estructural.
Porque nosotros

ya han introducido la idea del juego de roles de las tarjetas CRC y la identificación de objetos,
en

esta sección nos enfocamos en realizar recorridos.

En este caso, se verifica la verificación y validación del modelo estructural

durante una reunión de revisión formal usando un enfoque de recorrido en el que un analista
presenta

el modelo para un equipo de desarrolladores y usuarios. El analista recorre el modelo

explicando

cada parte del modelo y todos los razonamientos detrás de la decisión de incluir cada una de
las clases

en el modelo estructural. Esta explicación incluye justificaciones para los atributos,

operaciones,

y relaciones asociadas con las clases. Cada clase debe vincularse con al menos una

caso de uso; de lo contrario, el propósito de incluir la clase en el modelo estructural no será

Diagrama de clase con patrón incorporado para el sistema de colección de libros de la

biblioteca

entendido. También se incluyen personas ajenas al equipo de desarrollo que produjeron el

modelo

puede traer una nueva perspectiva al modelo y descubrir objetos faltantes.

Previamente, sugerimos tres representaciones que podrían usarse para el modelado

estructural:

Tarjetas CRC, diagramas de clases y diagramas de objetos. Porque un diagrama de objetos es

simplemente

una ejemplificación de alguna parte de un diagrama de clases, limitamos nuestra discusión a

las tarjetas CRC y

diagramas de clase. Similar a cómo verificamos y validamos el proceso comercial y funcional

modelos en el último capítulo, ofrecemos un conjunto de reglas que probarán la consistencia

dentro de los modelos estructurales Por ejemplo, utilizamos el problema de cita

descrito en el Capítulo 4 y en este capítulo. Un ejemplo de la tarjeta CRC para el viejo paciente
clase se muestra en la Figura 5-6, y el diagrama de clase asociado se muestra en la Figura 5-7.

Primero, cada tarjeta CRC debe asociarse con una clase en el diagrama de clases, y viceversa

versa. En el ejemplo de cita, la clase Old Patient representada por la tarjeta CRC no

no parece estar incluido en el diagrama de clases. Sin embargo, hay una clase de pacientes en
la clase

diagrama (vea las Figuras 5-6 y 5-7). Es muy probable que se deba cambiar la tarjeta CRC del
paciente anciano

simplemente paciente.

En segundo lugar, las responsabilidades enumeradas en el anverso de la tarjeta CRC se deben

incluir como

operaciones en una clase en un diagrama de clase, y viceversa. Usted hace la responsabilidad

de la cita

en la nueva tarjeta Patient CRC también aparece como la operación make appointment () en

Clase de paciente en el diagrama de clase. Toda responsabilidad y operación deben ser

verificadas.

Por supuesto, los colaboradores en el frente de la tarjeta CRC implican algún tipo de relación
en

la parte posterior de la tarjeta CRC y algún tipo de asociación que esté conectada a la tarjeta
asociada

clase en el diagrama de clase. El colaborador de cita en el frente de la tarjeta CRC también

aparece como otra asociación en la parte posterior de la tarjeta CRC y como una asociación en
el

Diagrama de clase que conecta la clase Patient con la clase Appointment.

En cuarto lugar, los atributos enumerados en la parte posterior de la tarjeta CRC se deben
incluir como atributos en

una clase en un diagrama de clase, y viceversa. Por ejemplo, el atributo de cantidad en el

nuevo

La tarjeta CRC del paciente se incluye en la lista de atributos de la clase Patient en el diagrama
de clases.

Fift h, el tipo de objeto de los atributos enumerados en la parte posterior de la tarjeta CRC y
con el

atributos en la lista de atributos de la clase en un diagrama de clases implica una asociación de

la

clase a la clase del tipo de objeto. Por ejemplo, técnicamente hablando, el atributo de cantidad

implica una asociación con el tipo doble. Sin embargo, tipos simples como int y double
nunca se muestran en un diagrama de clase. Además, dependiendo del dominio del problema,
objeto

tipos como Persona, Dirección o Fecha pueden no mostrarse explícitamente tampoco. Sin
embargo, si nosotros

saber que los mensajes se envían a instancias de esos tipos de objetos, probablemente
deberíamos

incluir estas asociaciones implícitas como relaciones.

En sexto lugar, las relaciones incluidas en la parte posterior de la tarjeta CRC deben retratarse
usando

la notación apropiada en el diagrama de clase. Por ejemplo en la Figura 5-6, instancias de

La clase del paciente es una especie de persona, tiene instancias de la clase de historia médica
como parte de ella,

y tiene una asociación con instancias de la clase de Cita. Th us, la asociación de

la clase de paciente a la clase de persona debe indicar que la clase de persona es una
generalización de

sus subclases, incluida la clase Patient; la asociación de la clase de Pacientes a los Médicos

La clase de historial debe tener la forma de una asociación de agregación (un diamante
blanco); y el

asociación entre instancias de la clase Patient e instancias de la clase Appointment

debería ser una simple asociación. Sin embargo, cuando revisamos el diagrama de clases en la
Figura 5-7,

esto no es lo que encontramos. Si recuerdas, incluimos en el diagrama de clases el patrón de

transacción

retratado en la Figura 5-4. Cuando hicimos esto, se hicieron muchos cambios a las clases
contenidas

en el diagrama de clase. Todos estos cambios deberían haberse realizado en cascada a través
de todos

las tarjetas CRC. En este caso, la tarjeta CRC para la clase de paciente debe mostrar que un
paciente está

un tipo de Participante (no Persona) y que la relación entre el Paciente y la Historia Médica

debe ser una asociación simple (vea la Figura 5-25).

Séptimo, se debe crear una clase de asociación, como la clase de Tratamiento en la Figura 5-7.

solo si hay alguna característica única (atributo, operación o relación) sobre

la intersección de las clases de conexión. Si no existe una característica única, entonces la

asociación

clase debe eliminarse y solo una asociación entre las dos clases de conexión
debe ser mostrado.

Finalmente, como en los modelos funcionales, se deben aplicar reglas de representación

específicas. por

ejemplo, una clase no puede ser una subclase de sí misma. La tarjeta del paciente CRC no
puede mostrar al paciente con

las relaciones de generalización en la parte posterior de la tarjeta CRC, ni puede una relación
de generalización

ser extraído de la clase de Paciente a sí mismo. De nuevo, todas las restricciones detalladas
para cada

la representación está más allá del alcance de este libro.18 La figura 5-26 retrata las
asociaciones

entre los modelos estructurales.

Tarjeta de paciente CRC

Interrelaciones entre modelos estructurales

APLICANDO LOS CONCEPTOS EN PATTERSON

HIPERMERCADO

En el Capítulo 4, aprendiste cómo los modelos funcionales se desarrollaron de forma iterativa

manera. Después de crear el modelo funcional para la programación móvil (versión 1) de

el Sistema Integrado de Entrega de Clínicas de Salud, el equipo tenía una buena comprensión
de la

Procesos de negocios. Ahora es el momento de identificar los datos clave y desarrollar la

estructura

modelo de los objetos que respaldan esos procesos comerciales. Modelado estructural para

La Programación móvil (Versión 1) implica la creación, verificación y validación de tarjetas CRC.

Diagrama de clases y diagramas de objetos.

Puede encontrar el resto del caso en: www.wiley.com/go/dennis/casestudy

REVISIÓN DEL CAPÍTULO

Después de leer y estudiar este capítulo, usted debería ser capaz de:

Describe el propósito de un modelo estructural.

Describe los diferentes elementos de un modelo estructural.

Explicar la diferencia entre clases abstractas y concretas.

Describa los tres tipos generales de relaciones que típicamente se usan en un modelo
estructural.
Cree un modelo estructural usando el análisis textual de descripciones de casos de uso, lluvia
de ideas, listas de objetos comunes,

y patrones

Explicar el propósito de una tarjeta CRC en modelado estructural.

Crea un modelo estructural usando tarjetas CRC.

Describe los diferentes elementos de una tarjeta CRC.

Describe cómo jugar roles de cartas CRC usando escenarios de caso de uso.

Describe los diferentes elementos de un diagrama de clases.

Describe las cuatro operaciones básicas que se pueden representar en un diagrama de clases.

Explicar las diferencias entre los tipos de relaciones admitidas en un diagrama de clases.

Crea un diagrama de clase que represente un modelo estructural.

Describe los diferentes elementos de un diagrama de objetos.

Cree un diagrama de objeto que represente una instanciación de una parte de un diagrama de
clase.

Verifique y valide el modelo estructural en evolución utilizando juegos de rol y tutoriales.

Verificar y validar el modelo funcional asegurando la consistencia de las tres representaciones

estructurales: CRC

cartas, diagramas de clases y diagramas de objetos.

TÉRMINOS CLAVE

Una especie de

Una parte de

Clase abstracta

Asociación de agregación

Asambleas

Asociación

Clase de asociación

Atributo

Reunión creativa

Clase

Diagrama de clase

Cliente

Colaboración
Lista de objetos comunes

Modelo conceptual

Clase de hormigón

Operación de constructor

Contrato

Responsabilidad de la clase-

Colaboración (CRC)

Tarjetas CRC

Descomposición

Atributo derivado

Hacer la responsabilidad

Operación del destructor

Generalización

asociación

Has-partes

Incidentes

Ejemplo

Interacciones

Conociendo la responsabilidad

Método

Multiplicidad

Objeto

Diagrama de objeto

Operación

Paquete

Partes

Patrón

Privado

Protegido

Público

Operación de consulta
Responsabilidad

Juego de rol

Roles

Servidor

Estado

Modelo estático

Estructura estática

diagrama

Modelo estructural

Subclase

Sustituibilidad

Superclase

SVDPI

Cosas tangibles

Analisis textual

Operación de actualización

Ver

Visibilidad

Wholes

PREGUNTAS

1. Describe a un hombre de negocios la multiplicidad de una relación

entre dos clases.

2. ¿Por qué son las suposiciones importantes para un estructural

¿modelo?

3. ¿Qué es una clase de asociación?

4. Compare los siguientes conjuntos de términos: objeto, clase,

método, atributo, superclase, subclase, clase concreta,

clase abstracta.

5. Dé tres ejemplos de atributos derivados que pueden

existir en un diagrama de clase. ¿Cómo se los denotaría?

en el diagrama de clase?
6. ¿Cuáles son los diferentes tipos de visibilidad? Cómo podría

se denotan en un diagrama de clase?

7. Dibuja las relaciones que se describen mediante el siguiente

reglas del negocio. Incluye las multiplicidades para

cada relación.

Un paciente debe ser asignado a un solo médico, y un

el doctor puede tener uno o muchos pacientes.

Un empleado tiene una extensión de teléfono y una única

la extensión del teléfono está asignada a un empleado.

Una sala de cine muestra al menos una película y una película

se puede ver en hasta cuatro salas de cine

alrededor del pueblo.

Una película tiene una estrella, dos coestrellas o más de

diez personas protagonizando juntos. Una estrella debe estar en

al menos una película.

8. ¿Cómo se designa la dirección de lectura de una relación?

en un diagrama de clase?

9. ¿Para qué se usa una clase de asociación en un diagrama de clase?

Da un ejemplo de una clase de asociación que

se puede encontrar en un diagrama de clase que captura a los estudiantes

y los cursos que han tomado.

10. Da dos ejemplos de agregación, generalización y

relaciones de asociación. ¿Cómo es cada tipo de asociación?

representado en un diagrama de clase?

11. Identifique las siguientes operaciones como constructor,

consulta o actualización. Qué operaciones no necesitarían

para ser mostrado en el rectángulo de la clase?

Calcular aumento de empleados (aumentar el porcentaje)

Calcular días enfermos ()

Incrementar el número de días de vacaciones de los empleados ()

Ubicar el nombre del empleado ()

Solicitud de lugar de vacaciones (día de vacaciones)

Buscar la dirección del empleado ()

Insertar empleado ()

Cambiar la dirección del empleado ()

Insertar cónyuge ()

12. ¿Cómo se relacionan los diferentes modelos estructurales y cómo?

¿Esto afecta la verificación y validación del modelo?

CEREMONIAS

A. Crea una tarjeta CRC para cada una de las siguientes clases:

Película (título, productor, duración, director, género)

Boleto (precio, adulto o niño, showtime, película)

Patrón (nombre, adulto o niño, edad)

B. Crea un diagrama de clase basado en las cartas CRC

creado para el ejercicio A.

C. Crea una tarjeta CRC para cada una de las siguientes clases.

Considere que las entidades representan un sistema para

sistema de facturación paciente. Incluye solo los atributos que

sería apropiado para este contexto.

Paciente (edad, nombre, pasatiempos, tipo de sangre, ocupación,

compañía de seguros, dirección, teléfono)

Compañía de seguros (nombre, número de pacientes en el plan,

dirección, nombre de contacto, teléfono)

Doctor (especialidad, número de identificación del proveedor,

handicap de golf, edad, teléfono, nombre)

D. Crea un diagrama de clase basado en las cartas CRC

creado para el ejercicio C.

E. Dibuje un diagrama de clases para cada una de las siguientes situaciones:

1. Cuando se ven nuevos pacientes por primera vez,

completan un formulario de información del paciente que pregunta

su nombre, dirección, número de teléfono y seguro

portador, que se almacenan en la información del paciente

archivo. Los pacientes pueden registrarse con solo un proveedor,

pero deben estar registrados para ser vistos por el médico.

Cada vez que un paciente visita al médico, un seguro

el reclamo se envía al transportista para el pago. La reclamación

debe contener información sobre la visita, como

la fecha, el propósito y el costo. Sería posible

un paciente para presentar dos reclamos el mismo día.

2. El estado de Georgia está interesado en diseñar un

sistema que rastreará a sus investigadores. Información

de interés incluye el nombre del investigador, el título, la posición,

nombre de la universidad del investigador, ubicación de la universidad, universidad

inscripción e intereses de investigación del investigador.

Los investigadores están asociados con una institución,

y cada investigador tiene varios intereses de investigación.

3. Una tienda departamental tiene un registro de bodas. Esta

registro mantiene información sobre el cliente

(generalmente la novia), los productos que la tienda

lleva, y los productos para los cuales cada cliente

registros. Los clientes generalmente se registran para un gran

número de productos, y muchos clientes se registran

para los mismos productos.

4. La concesionaria de Jim Smith vende Ford, Hondas y

Toyotas. Para ponerse en contacto con estos fabricantes

fácilmente, el concesionario guarda información

sobre cada uno de ellos. El concesionario mantiene

información sobre los modelos de automóviles de cada

fabricante, incluido el precio del distribuidor, el nombre del modelo,

y series (por ejemplo, Honda, Civic, LX). Adicionalmente,

el concesionario también guarda toda la información de ventas,

incluyendo el nombre del comprador, dirección y número de teléfono,

automóvil comprado y monto pagado.

F. Crear diagramas de objetos basados en los diagramas de clases

dibujaste para el ejercicio F.

G. Examina los diagramas de clases que creaste para el ejercicio

F. ¿Cómo cambiarían los modelos (si es que lo hicieron)?

en estas nuevas suposiciones?

1. Dos pacientes tienen el mismo nombre y apellido.

2. Los investigadores pueden estar asociados con más de uno

institución.

3. A la tienda le gustaría hacer un seguimiento de la compra

artículos.

4. Muchos compradores han comprado varios autos de

Jim con el tiempo porque es un buen distribuidor.

H. Visite un sitio web que permita a los clientes pedir un

producto en la web (por ejemplo, Amazon.com). Crear un

modelo estructural (tarjetas CRC y diagrama de clases) que

el sitio debe necesitar apoyar su proceso comercial.

Incluye clases para mostrar lo que necesitan información

acerca de. Asegúrese de incluir los atributos y operaciones

para representar el tipo de información que utilizan y crean.

Finalmente, dibujar relaciones, hacer suposiciones

acerca de cómo las clases están relacionadas.

I. Usando el proceso de siete pasos descrito en este capítulo,

crear un modelo estructural (tarjetas CRC y diagrama de clases)

para el ejercicio C en el Capítulo 4.

J. Realizar un recorrido de validación y verificación para

el modelo estructural creado para el ejercicio J.

K. Usando el proceso de siete pasos descrito en este

capítulo, crea un modelo estructural para el ejercicio E en

Capítulo 4.

L. Realizar un recorrido de validación y verificación para

el modelo estructural creado para el ejercicio L.

M. Usando el proceso de siete pasos descrito en este

capítulo, crea un modelo estructural para el ejercicio G en

Capítulo 4.

N. Realizar un recorrido de validación y verificación para

el modelo estructural creado para el ejercicio N.

O. Usando el proceso de siete pasos descrito en este capítulo,

crear un modelo estructural para el ejercicio I en el Capítulo 4.

P. Realizar un recorrido de validación y verificación para

el modelo estructural creado para el ejercicio P.

Q. Usando el proceso de siete pasos descrito en este capítulo,

cree un modelo estructural para el ejercicio L en el Capítulo 4.

R. Realizar un recorrido de validación y verificación para

el modelo estructural creado para el ejercicio R.

S. Usando el proceso de siete pasos descrito en este

capítulo, crea un modelo estructural para el ejercicio O en

Capítulo 4.

T. Realizar un recorrido de validación y verificación para

el modelo estructural creado para el ejercicio T.

U. Usando el proceso de siete pasos descrito en este capítulo,

cree un modelo estructural para el ejercicio R en el Capítulo 4.

V. Realizar un recorrido de verificación y validación para

el modelo estructural creado para el ejercicio V.

W. Usando el proceso de siete pasos descrito en este

capítulo, crea un modelo estructural para el ejercicio U en

Capítulo 4.

X. Realice un recorrido de validación y verificación para

el modelo estructural creado para el ejercicio X.

MINICASES

1. West Star Marinas es una cadena de doce marinas que

off servicio de orilla del lago a los navegantes; servicio y reparación de

barcos, motores y equipos marinos; y ventas de

barcos, motores y otros accesorios marinos. Los sistemas

equipo de proyecto de desarrollo en West Star Marinas

ha estado trabajando duro en un proyecto que eventualmente

unirá todas las instalaciones de la marina en una sola,

sistema de red.

El equipo del proyecto ha desarrollado un diagrama de caso de uso

del sistema actual. Este modelo ha sido cuidadosamente

comprobado. La semana pasada, el equipo invitó a varios

usuarios del sistema para representar roles en los diversos casos de uso, y

los casos de uso fueron refinados a la satisfacción de los usuarios.

En este momento, el gerente del proyecto confía en que

el sistema tal como está se ha representado adecuadamente en

el diagrama de casos de uso.

El director de operaciones de West Star es el

patrocinador de este proyecto. Él se sentó en el juego de rol

de los casos de uso y estaba muy contento por la exhaustiva

trabajo que el equipo había hecho en el desarrollo del modelo. Él

le dejó claro a usted, el gerente del proyecto, que él

estaba ansioso por ver a su equipo comenzar a trabajar en el uso

casos para el sistema futuro. Él era un poco escéptico

que era necesario que su equipo gastara

tiempo modelando el sistema actual en el primer lugar

pero a regañadientes admitió que el equipo realmente parecía

para entender el negocio después de pasar por eso

trabajo.

La metodología que estás siguiendo, sin embargo,

especifica que el equipo ahora debe volver su atención

para desarrollar los modelos estructurales para el sistema tal como está.

Cuando declaraste esto al patrocinador del proyecto, él

parecía confundido y un poco irritado. "Vas a ir

pasar aún más tiempo mirando el sistema actual?

¡Pensé que habías terminado con eso! Por qué es esto

¿necesario? Quiero ver un poco de progreso en el camino

¡las cosas funcionarán en el futuro!

¿Cuál es su respuesta al director de operaciones?

¿Por qué realizamos modelos estructurales? Hay alguna

beneficio para desarrollar un modelo estructural de la corriente

sistema en absoluto? ¿Cómo funcionan los casos de uso y el diagrama de casos de uso?

ayudarnos a desarrollar el modelo estructural?

2. Holiday Travel Vehicles vende nuevos vehículos recreativos

y trailers de viajes. Cuando llegan nuevos vehículos

Holiday Travel Vehicles, se crea un nuevo registro de vehículos.

Incluido en el nuevo registro del vehículo son un vehículo

número de serie, nombre, modelo, año, fabricante y

costo base

Cuando un cliente llega a Holiday Travel Vehicles,

él o ella trabaja con un vendedor para negociar un

compra de vehículos. Cuando se ha acordado una compra

una vez, el vendedor completa una factura de venta.

La factura resume la compra, incluido el total

información del cliente, información sobre el intercambio

vehículo (si lo hay), el permiso de entrega e información

en el vehículo comprado Si el cliente

solicita opciones instaladas por el concesionario, se enumeran en

factura también La factura también resume el final

precio negociado, más los impuestos y licencias aplicables

matrícula. La transacción concluye con la firma de un cliente

en la factura de ventas.

a. Identificar las clases descritas en el escenario anterior

(deberías encontrar seis). Crea tarjetas CRC para cada clase.

A los clientes se les asigna una identificación de cliente cuando

haga su primera compra en Holiday Travel Vehicles.

Nombre, dirección y número de teléfono son grabados

para el cliente El vehículo de intercambio es descrito por un

número de serie, marca, modelo y año. Distribuidor instalado

las opciones se describen mediante un código de opción, descripción,

y el precio.

segundo. Desarrolla una lista de atributos para cada clase. Colocar el

atributos en las tarjetas CRC.

Cada factura enumera solo un cliente. Una persona lo hace

no convertirse en cliente hasta que compre una

vehículo. Con el tiempo, un cliente puede comprar un número

de vehículos de Holiday Travel Vehicles.

Cada factura debe ser completada por un solo vendedor.

Un nuevo vendedor podría no haber vendido ninguna

vehículos, pero los vendedores experimentados probablemente

vendió muchos vehículos.

Cada factura solo muestra un vehículo nuevo. Si es nuevo

vehículo en el inventario no se ha vendido, no habrá

facturarlo Una vez que el vehículo se vende, habrá solo

una factura por ello.

Un cliente puede decidir no tener opciones añadidas

al vehículo o puede elegir agregar muchas opciones. Un

la opción puede aparecer sin facturas, o puede estar en la lista

en muchas facturas.

Un cliente puede comerciar en no más de un vehículo

en una compra de un nuevo vehículo. El vehículo de cambio

se puede vender a otro cliente que luego lo intercambie en

en otro vehículo de viaje de vacaciones.

do. Basado en las reglas comerciales precedentes vigentes en

Holiday Travel Vehicles y tarjetas CRC, dibuja un

Diagrama de clase y documentar las relaciones con

las multiplicidades apropiadas. Recuerde actualizar

las tarjetas CRC.