Professional Documents
Culture Documents
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
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.
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).
guiado por casos de uso, centrado en la arquitectura e iterativo e incremental. Casos de uso,
descritos en
modelos (descritos en este capítulo), pero también tendrá que iterar a través de los tres
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
Refleja cómo se organizarán los objetos en bases de datos y software. En este punto, el
modelo es
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
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.
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
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:
é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.
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.
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).
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
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
Relaciones
Hay muchos tipos diferentes de relaciones que se pueden definir, pero todas se pueden
clasificar
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
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.
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.
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
Relaciones de agregación
para representar la abstracción de agregación. Por ejemplo, una puerta es una parte de un
automóvil, un empleado es
Por ejemplo, un pistón es una parte de un motor, y un motor es una parte de un automóvil.
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
Relaciones de asociación
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
IDENTIFICACIÓN DE OBJETOS
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
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
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
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
para identificar clases candidatas basadas en sus experiencias pasadas. Tenga en cuenta que
este enfoque no
los objetos con los que han interactuado. Por ejemplo, un conjunto potencial de objetos que
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
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
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
use el humor para romper el hielo para que todos los participantes puedan sentirse cómodos
al hacer sugerencias.
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
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
interacción es una transacción que tiene lugar en el dominio comercial, como una transacción
de venta.
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
Patrones
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
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
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
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
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
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
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
TARJETAS 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.
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?
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
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
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
el atributo es doble y la compañía de seguros es texto). Estos tipos de relaciones suelen ser
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
escenarios asociados con los casos de uso (ver Capítulo 4). El juego de roles también se puede
usar como
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
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.
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
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
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
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
El cuarto paso es simplemente repetir los pasos 1 a 3 para los casos de uso restantes
Juego de rol
Escenarios
DIAGRAMAS DE CLASE
Un diagrama de clases es un modelo estático que muestra las clases y las relaciones entre
clases
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
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.
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
formularios y otros objetos utilizados para construir el sistema. Cada clase se dibuja usando un
threepart
en el fondo. Podemos ver que las clases identificadas anteriormente, como Participante,
Doctor,
5-7. Los atributos de una clase y sus valores definen el estado de cada objeto creado a partir
de
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
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
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
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
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
cambiar el estado del objeto, entonces la operación debe incluirse explícitamente en la clase
Una operación de destrucción simplemente elimina o elimina el objeto del sistema. Por
ejemplo,
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
Relaciones
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
se asocia con una orden de compra (y viceversa), un piloto vuela una aeronave y un repuesto
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
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
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,
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
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
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
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
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
usar palabras como "es un tipo de" para describir la relación. Algunos ejemplos adicionales de
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
asignado a un equipo de atención médica, que se preocupa por sus necesidades durante sus
visitas. Podríamos
incluir este nuevo conocimiento en la Figura 5-7 agregando dos nuevas clases (Administrativo
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
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
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)
notación gráfica adicional para que el cliente aprenda. Por lo tanto, muchos expertos de UML
ven
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.
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
la información que se muestra con cada clase, por ejemplo, muestra solo el nombre de la
clase, el
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
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
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
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,
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
Y DIAGRAMAS DE CLASE
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
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.
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
los flujos excepcionales de la descripción del caso de uso se escribieron en una forma especial
llamada Subject-
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,
los enfoques de la lluvia de ideas y la lista de objetos comunes descritos anteriormente pueden
ayudar al equipo en
■ ¿Cuáles son los roles desempeñados por las personas 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
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,
pasos anteriores, cada vez que se descubre información nueva, se crean nuevas tarjetas CRC o
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
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
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
las descripciones de clases individuales. Como en los pasos anteriores, todos los cambios
deben registrarse
operaciones y relaciones. Hasta este paso, el enfoque del proceso ha estado en agregar
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.
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
Capítulo 7.
los estudiantes encuentran apartamentos. Al revisar los casos de uso, podemos determinar
fácilmente que el campus
propietario. La información que se debe capturar para cada apartamento es la ubicación del
apartamento,
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
Ejemplo de biblioteca
Al igual que con el ejemplo de Campus Housing, el primer paso es crear las tarjetas CRC que
representan
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
Propietario de apartamento
Tarjeta CRC
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
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
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
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.
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
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
también podría incluir clases para Revistas, DVD y otros medios. Como puedes ver, muchos
El tercer paso, el juego de roles de las tarjetas CRC, requiere que apliquemos los tres juegos de
rol
Para nuestros propósitos, usaremos el caso de uso de Libros prestados para demostrar. Lo
relevante
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
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
no solo está dirigido a casos de uso, sino que también es incremental e iterativo.
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,
relaciones de asociación.
(Figura 4-12)
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,
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
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
Participante del Prestatario, Transacción por Transferencia y Artículo por Libro (Figura 5-24).
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í.
Antes de pasar a la creación de modelos de comportamiento (ver Capítulo 6) del dominio del
problema,
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
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
durante una reunión de revisión formal usando un enfoque de recorrido en el que un analista
presenta
cada parte del modelo y todos los razonamientos detrás de la decisión de incluir cada una de
las clases
y relaciones asociadas con las clases. Cada clase debe vincularse con al menos una
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 la nueva tarjeta Patient CRC también aparece como la operación make appointment () en
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
aparece como otra asociación en la parte posterior de la tarjeta CRC y como una asociación en
el
En cuarto lugar, los atributos enumerados en la parte posterior de la tarjeta CRC se deben
incluir como atributos en
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
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
En sexto lugar, las relaciones incluidas en la parte posterior de la tarjeta CRC deben retratarse
usando
La clase del paciente es una especie de persona, tiene instancias de la clase de historia médica
como parte de ella,
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
debería ser una simple asociación. Sin embargo, cuando revisamos el diagrama de clases en la
Figura 5-7,
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
Séptimo, se debe crear una clase de asociación, como la clase de Tratamiento en la Figura 5-7.
clase debe eliminarse y solo una asociación entre las dos clases de conexión
debe ser mostrado.
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
HIPERMERCADO
el Sistema Integrado de Entrega de Clínicas de Salud, el equipo tenía una buena comprensión
de la
modelo de los objetos que respaldan esos procesos comerciales. Modelado estructural para
Después de leer y estudiar este capítulo, usted debería ser capaz de:
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
Describe cómo jugar roles de cartas CRC usando escenarios de caso de uso.
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.
Cree un diagrama de objeto que represente una instanciación de una parte de un diagrama de
clase.
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
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
¿modelo?
clase abstracta.
en el diagrama de clase?
6. ¿Cuáles son los diferentes tipos de visibilidad? Cómo podría
cada relación.
en un diagrama de clase?
Insertar empleado ()
Insertar cónyuge ()
CEREMONIAS
A. Crea una tarjeta CRC para cada una de las siguientes clases:
C. Crea una tarjeta CRC para cada una de las siguientes clases.
institución.
artículos.
Capítulo 4.
Capítulo 4.
Capítulo 4.
Capítulo 4.
MINICASES
sistema de red.
usuarios del sistema para representar roles en los diversos casos de uso, y
trabajo.
para desarrollar los modelos estructurales para el sistema tal como está.
sistema en absoluto? ¿Cómo funcionan los casos de uso y el diagrama de casos de uso?
costo base
en la factura de ventas.
y el precio.
en muchas facturas.