METODOLOGÍA SOMA:

Un método de análisis orientado a objetos semánticamente rico.

Entre los trece o más métodos que se han descrito hasta el momento, existe un

grado de variación considerable. Oscilan entre las notaciones complejas y

dificultosas de OMT, Ptech y Shlaer/Mellor y las más sencillas, propias de CRC

y Coad/Yourdon; van desde hacer hincapié en los procesos hasta hacer

hincapié en la representación, y van desde la dependencia de un lenguaje a las

más elevadas alturas de la abstracción. También se han examinado algunos

híbridos. Ninguno de estos métodos está completo, en el sentido de que se

traten todos los temas del desarrollo del software, o en el sentido de que sea

posible describir con facilidad cualquier sistema concebible.

Esta sección presenta una aproximación que comenzó a existir como una

extensión del método notación propuesto por Coad y Yourdon, pero que

contiene, ahora, tantas ideas procedentes de otros métodos de diseño y

análisis orientados a objetos, que la conexión con Coad/Yourdon es bastante

tenue. En principio, se podrían extender otras notaciones básicas, tales como

las de principio, se podrían extender otras notaciones básicas, tales como las

de OMT, empleando estructuras de SOMA; esto hace que SOMA sea más un

filtro de métodos que un método en sí. También contiene ideas técnicas

procedentes de los campos de Inteligencia Artificial y del modelado semántico

de datos.

Se intenta que SOMA sea un método semánticamente rico de análisis

orientado a objetos. En su forma básica que es la que se describe aquí, se

pretende que mantenga la simplicidad de notación del método de

Coad/Yourdon, pero añadiendo actividades adicionales y refinando la

semántica de temas (que se denominan capas en SOMA). También modifica la

notación, para ponerla de acuerdo con las convenciones de modelado de

entidad y relación propias del estilo de Chen. Al igual que Coad/Yourdon, se

admiten estructuras de clasificación y de composición, junto con asociaciones

generales. También se admiten condiciones previas, posteriores e invariantes.

Por último, añade reglas parecidas a las de los sistemas expertos a los objetos,

con objeto de aumentar la riqueza semántica de los modelos de análisis en

todos los casos y también para ayudar a modelar el análisis de sistemas

avanzados de conocimiento y de bases de datos. En el momento del diseño,

estas reglas se transforman en afirmaciones lógicas. SOM posee en exclusiva

el apoyo de objetos difusos y la herencia, según se describe en el apéndice I.

Las siete actividades de las que consta SOMA son las siguientes:

 Identificar capas

 Identificar objetos

 Identificar estructuras de utilización, clasificación y composición.

 Definir la semántica de datos y las asociaciones.

 Añadir atributos a los objetos.

 Añadir operaciones a los objetos.

 Añadir la semántica declarativa de objetos (conjuntos de reglas).

En primer lugar, establezcamos algunos puntos de notación. Los objetos de

SOMA se muestran en la forma indicada en la figura. Si el icono posee

esquinas cuadradas, entonces, representa una instancia; si son redondas, será

una clase. De estar manera, cada objeto posee un identificador y tres listas.
El tratamiento explícito de los atributos viola el principio de ocultamiento de

información. Sin embargo, tal como hemos visto, la complejidad de las

estructuras de datos que están presentes en la mayoría de los sistemas

comerciales, comparada con abstracciones sencillas de programación, tales

como las ventanas o las filas, nos lleva a la necesidad de hacer que los

atributos sean explícito y visibles. Por tanto, en este método mantenemos la

ventana de atributos.

CAPAS

Las capas de SOMA no son solamente una forma de descomponer el dominio

del problema, tal como sucede en la mayoría de los demás métodos: son

objetos reales, con su propio derecho, con la semántica de objetos. Las capas

se diferencian de los demás objetos en dos aspectos: (a) se encuentran en la

cima de la estructura de composición; (b) cada uno de sus métodos debe ser

realizado por un método de algún objeto que se encuentra dentro de esa

estructura.
¿Que es lo que sucede cuando un objeto componente necesita enviar un

mensaje fuera de su continente? Aun cuando los mensajes que se envían a las

capas son tratas por la interfaz de la capa y delegados de esta manera a los

métodos de los componentes a lo largo de enlaces del tipo realizado-por, es

menos evidente lo que debería suceder cuando un componente requiera los

servicios de un objeto que se encuentra fuera de la capa que lo contiene.

BUSQUEDA DE OBJETOS

Los objetos se identifican como de costumbre utilizando los métodos de

modelos de datos, o bien los sugeridos por Coad y Yourdon o Shaler y Mellor,

la técnica de análisis textual de Abbott, tal como se utiliza dentro de Booch,

HOOD y CRC, o de cualquier otra manera (quizá examinando DFD, o de

diagramas de sucesos de Jackson, tal como sugiere Ince (1991), SOMA añade

técnicas de identificación e objetos que se han tomado de la práctica de la

captación de conocimientos y de HCI. Específicamente se incluyen: entrevistas

estructuradas y enfocadas, redes Kelly, análisis de tópicos y análisis de tarea.

Se ha añadido una nueva técnica de refinamiento denominada análisis de

objetos (todas estas técnicas se describen en el capítulo 9). Estas técnicas

sirven especialmente de ayuda cuando no existe una especificación escrita de

los requisitos y son necesarias las entrevistas.

Los modelos de estado de sistemas también se pueden utilizar para identificar

y refinar objetos, tal como se hace en OMT o en OSA. La respuesta de los

objetos asociados del sistema se puede indicar mediante cambios de estado

de entidades, transiciones de estados o diagramas de historia vital, con

diagramas de correspondencia de efectos que se han tomado SSADM. Versión

4. El uso de técnicas múltiples es recomendable para aumentar la confianza en

sus productos, que deberían ser los mismos, o al menos equivalentes, sea cual

fuere la técnica utilizada.

La notación de SOMA es únicamente el depósito final de toda la información

descubierta y unifica el modelo estático de objetos con el modelo de

comportamiento dinámico, empleando afirmaciones y reglas.

SEMANTICA DE ESTRUCTURAS Y DE DATOS

Las estructuras que deben ser identificadas son de tres tipos principales: de

utilización, de clasificación y de composición. Las estructuras de utilización

muestran las vías de acceso de mensajes admisibles a través del sistema; las

estructuras de clasificación muestran la herencia de características, y las

estructuras de composición muestran la formación de capas y objetos

agregados.

ESTRUCTURAS DE CLASIFICACION

Las notaciones de algunos métodos resultan ambiguas en algunas ocasiones

debido a la falta de expresividad, o quizá resulten un poco torpes. Un ejemplo

es la notación de Coad/Yourdon para la clasificación y composición que se da

en las figuras, se muestra una alternativa que nosotros sugerimos.

La notación que se encuentra dentro del rombo se interpreta exactamente

según se indicaba en el capítulo 5. esto es, E/O quiere decir

“exclusivo/opcional” e I/O significa “inclusive/opcional”. Recuérdes que el

término “exclusive” indica que la intersección de cada subclase con las demás

subclases está vacía y que “inclusive” indica que las subclases pueden

superponerse. El “opcional” indica que la lista no es exhaustiva: quizás hay

más subclases todavía no identificadas. La M “obligatorio” indica que un

miembro de la superclase debe estar, al menos, en una de las subclases con

una lista exhaustiva o partición de la clase.

También se puede argumentar, por parte de aquellos que estén dedicados una

aproximación basada en objetos al análisis que la herencia es un problema de

realización que no debería entrar en el proceso de análisis, que la herencia es

un problema de realización que no debería entra en el proceso de análisis y

que los usuarios se pueden confundir y pueden distraerse de los objetivos del

sistema. Este argumento es verdadero, pero tiene dos deficiencias. En primer

lugar, confunde la extracción de requisitos con el proceso conceptual de

análisis, que pretende abstraer los conceptos clave de la aplicación,

independientemente de las percepciones de los usuarios. En esto último, se

revelan las características estructurales del dominio, incluyendo las nociones

naturales de especialización y generalización. En segundo lugar, la herencia y

otras estructuras son

parte importante de la semántica del dominio: la forma en que se clasifican los

objetivos define el dominio y, a menudo, el propósito de la aplicación. Por

ejemplo, los objetos de la sociología y de la historia son el mismo, las personas

y las organizaciones, pero en la historia no se clasificará por grupos socio-

económicos, sino por clases sociales, o quizá, por nacionalidades. Las

estructuras representan el propósito del análisis.

ESTRUCTURAS DE COMPOSICION

Al igual que en Coad/Yourdon, toda estructura de composición es una capa.

Las estructuras de clasificación se consideran ortogonales a éstas, y no son

capas ni suelen mostrarse normalmente en los mismos diagramas que la

composición. Los mensajes llegan al exterior de las capas y son delegados a

subobjetos a través de enlaces del tipo realizado-por. Los mensajes pueden

llegar a cualquier parte de la estructura de clasificación, pero la mayoría de las

veces llegan a instancias.

Las ventanas de atributos de las clases o de las instancias que participan en

estructuras de composición deben contener los atributos especiales Partes y

APO. Los mismos comentarios se aplican exactamente al atributo APO: de las

partes y al atributo Miembros: de las superclases. Se trata de ayudas para la

navegación, que deben ser actualizadas automáticamente cuando se añada el

atributo Partes: o se elimine de ellas, puesto que, en caso contrario, cada vez

que se reestructurase un objeto compuesto, sería preciso alterar la

especificación de sus partes. Se pueden utilizar las notaciones E/O E/M I/O,

pero las partes no suelen superponerse.

ASOCIACIONES

También es preciso tener en cuenta otros tipos de asociaciones y su semántica

estática. La semántica de datos en Coad/Yourdon solamente se anota desde el

nivel de instancias. En SOMA, ha resultado útil permitir conexiones de este tipo

en el nivel de clases, al igual que en las estructuras de composición. Esto sirve

para enriquecer la semántica. Las conexiones de este tipo se pueden

considerar como asociaciones; esto es, relaciones estructurales que no son de

utilización ni de clasificación ni de composición. En algunos casos, estas

asociaciones poseen propiedades, y deberían ser expandidas para formar

objetos por sí mismas. En otras, la asociación puede ser tan importante para la

aplicación (por ejemplo, los parentescos en antropología) que será preciso

añadir una cuarta o quinta estructura al modelo. Los enlaces de semántica de

datos que se indican multiplicidad y modalidad se pueden utilizar en enlaces de

estructuras de composición.

Los elementos de la rica notación de OMT se utilizan para registrar complejas

estructuras de composición y asociaciones. En particular, la notación para la

composición recursiva que se muestra en la figura resulta recomendable.

TRIBUTOS Y OPERACIONES

Los atributos se descubren utilizando técnicas estándares de modelados de

datos. Se utilizan dos atributos especiales cuyo valor son listas: AKO y Parts:.

El atributo AKO: tiene como valor una lista, y contiene los nombres de las
superclases de un objeto. El atributo Partes: contiene una lista de los objetos

que forman el objeto. Cuando está disponible el apoyo automatizado, se

pueden emplear los atributos duales Miembros: y APO: como ayuda para la

navegación por el modelo, pero es preciso actualizarlos automáticamente,

porque, en caso contrario, la reutilización queda comprometida.

En SOMA, cada tributo posee un tipo, que debe ser una clase válida definida

por un usuario o primitiva del sistema. El analista tiene libertad para decidir lo

que es primitivo, pero deberá confeccionar una lista. Entre las primitivas típicas

se incluyen los reales, enteros, listas, fechas, etc., En los atributos también se

almacenan asociaciones. Por ejemplo, si se posee la relación semántica que

dice que los empleados deben trabajar exactamente para un departamento

mientras que los departamentos pueden dar empleo a uno o más empleados,

entonces, podríamos registrar.

REGLAS

Al realizar el análisis orientado a objetos y construir un modelo, se puede

aprender mucho de los sistemas de Inteligencia Artificial que se construyen

utilizando redes semánticas, y también del modelado semántico de datos. Las

especificaciones que muestran reutilizabilidad y extensibilidad son una gran

cosa, pero no contienen necesariamente el significado que deseaba darle el

analista o el usuario. Para reutilizar una especificación de un objeto, debería

ser posible leer de ella lo que es (la estructura de datos), lo que hace (sus

operaciones), por que lo hace y de qué forma está relacionada con otros

objetos. Mi punto de vista es que este contenido semántico es´ta contenido

parcialmente en las estructuras de clasificación, de composición y de utilización

y en las reglas que describen su comportamiento.

El hecho es que todas las semánticas comprometen la reutilización. Vimos en

el capítulo I que la herencia lo hace, y que también lo hace cualquier cosa que

haga que el significado de un objeto sea más específico. En la especificación

de sistemas, ambos aspectos son igualmente importantes y el equilibrio entre

ambos debe ser comprendido bien y tratado cuidadosamente, dependiendo de

los objetivos de los analistas y de sus clientes.

Lo mejor es separar la definición de la semántica de datos de la definición tanto

de objetos como de atributos. Deberíamos considerarla como una tarea

importante y distinta. Tal como ya se ha mencionado, las DBMS relacionales

suelen requerir que gran parte de esta información se descarte, o que se

incorpore a programas de aplicación. Por tanto, una justificación de las bases e

datos orientada a objetos, o incluso de las bases de datos relacionales

extendidas o semiorientadas a objetos, es que estas semánticas se pueden

captar en el entorno de desarrollo tenido como blanco, así como en el análisis

en su forma completamente explícita. Al hacerlo explícitamente se consigue la

flexibilidad, en tanto en cuanto la semántica de datos o las reglas de negocios

que modifican la aplicación pueden evolucionar. Si vamos a construir

especificaciones ejecutables y reversibles, es crucial que la información no se

pierda al codificar. Esto incluye todo los tipos de información semántica. La

semántica de datos se puede captar en relaciones, y se puede almacenar

explícitamente en bases de datos orientadas a objetos o deductivas. La

semántica funcional se puede captar explícitamente en forma de reglas.

Pasaremos a continuación, al tema de las reglas y de su representación.

En mi opinión, el defecto más serio de muchos métodos de análisis orientados

a objetos es su carencia de apoyo para la semántica funcional, para la

descripción global del control o para las reglas de negocios. Pasaremos ahora

a todo este tema, que yo denomino semántica declarativa, porque la semántica

de procedimiento se codifica en forma de métodos.

Resulta necesario, en esta etapa de análisis, registrar las reglas de negocios y

el comportamiento de tratamiento de excepciones y de pasos de parámetro del

objeto. El método Coad/Yourdon carece denotación para el tratamiento de

excepciones. Esto no es siempre muy importante, pero, para aquellas

aplicaicoens en que lo es, se puede utilizar una notación similar a OOSD en

las anotaciones hechas en cada objeto, sin violentar la sencillez de la notación

que recomendamos. Yo sugiero más adelante, un método para anotar

excepciones de forma no procedimental, y deberá compararse con la notación

de procedimientos de HOOD o OOSD.

Los métodos orientados a objetos, tales como el de Coad/Yourdon, pueden

extenderse, evidentemente, para tratar la herencia múltiple, aunque ésta no

esté incluida en su descripción, salvo el nivel de la notación. Esta extensión

debe incluir las providencias necesarias para anotar el tratamiento de conflictos

que surjan cuando un mismo atributo o método es heredado de forma distinta a

partir de dos objetos predecesores. También deben permitir una semántica

diferente para las subclases que patricionan a sus superclases en un conjunto

de subclases exhaustivo, y aquellas que sean incompletas, en el sentido de

que las subclases no especificadas en ese momento todavía se pueden añadir.

La sugerencia evidente para abarcar esta semántica declarativa consiste en

añadir reglas a los objetos de SOMA, que no sólo podrán evitar la ambigüedad

en la herencia múltiple, sino, también definir reglas de prioridad para los valores

por omisión y los diablillos. Un diablillo es un método que se despierta cuando

se le necesita: cuando cambia un valor, o cuando este valor se añade o se

borra. Esto es, estas reglas pueden determinar la forma de resolver el conflicto

que surge cuando un atributo hereda dos valores diferentes, o quizá especificar

si el valor por omisión debería ser aplicado antes o después de que se

produzca la herencia, o antes o después de que se active el diablillo. También

pueden especificar las prioridades relativas de la herencia y de los diablillos.

Estas reglas, en sí mismas, pueden tener valores por omisión. Las reglas de

negocios especifican información de segundo orden, tal como las

dependencias entre atributos, por ejemplo, una dependencia entre la edad de

un empleado y su derecho de vacaciones. Por último, quizá sea necesario

especificar como reglas las condiciones previas y posteriores que se aplican a

todos los métodos. Una regla de negocios típica en una aplicación de personal

podría contener “cambiar el derecho de vacaciones a seis semanas cuando el

tiempo en la empresa sobrepase los cinco años” como regla en la ventana de

reglas del objeto Empleado. Con esta extensión, la notación puede enfrentarse
a problemas de análisis en los cuales se tenga como entorno de destino una

base de datos relacional o deductiva con características orientadas a objetos.

Estas reglas se encapsulan dentro de objetos, en lugar de ser declaradas

globalmente, tal como sucede con todas las realizaciones actuales de

lenguajes de programación orientados a objetos. También se pueden heredar e

invalidar. El beneficio de todo esto es que son posibles variaciones locales de

la estrategia de control. Además, el analista puede inspeccionar el impacto de

la estructura de control en todos los objetos (utilizando, quizá, un ojeador

(browser) y no tiene que realizar anotaciones en complejos diagramas para

describir los efectos locales del control global. Si se desea una misión global de

estas características, entonces e pueden utilizar, opcionalmente, STD o

diagramas de sucesos de Ptech. Las reglas realmente globales están

contenidas en un objeto del más alto nivel, denominado “objeto” y serán

heredadas por todos aquellos objetos que no las invaliden. Del mismo modo

que los diagramas de transición de estado, o de cambio de estado, se pueden

utilizar para describir la semántica procedural de métodos, también los árboles

de decisión pueden resultar útiles al describir conjuntos complejos de reglas.

La actividad de semántica declarativa (reglas) es el aspecto más novedoso de

SOMA. Mejora el modelo de objeto habitual al añadir un conjunto de reglas de

un conjunto de conjuntos de reglas a cada objeto. De esta manera, aún cuando

un objeto se considera normalmente como formado por identificador, atributos,

y métodos, los objetos de SOMA constan de identificador, atributos, métodos y

reglas. Las reglas se pueden subdividir, a su vez, en tipos.

Esto tiene un cierto número de consecuencias interesantes, la más notable de

la cuales es que aquellos objetos que sean entidades locales podrán

encapsular las reglas del comportamiento global del sistema, de forma

bastante parecida a como se supone que el DNA encapsula los morfemas.

Otra consecuencia es que se pueden considerar como objetos los conjuntos

de reglas, para el desarrollo de sistemas expertos. En ese caso, una

aproximación natural es considerar los objetos del tipo conjunto de reglas con

sí poseyeran un pequeño número de atributos y métodos. Por ejemplo,

podríamos tener el atributo variable –Objetivo: y el método Encadenamiento-

regresivo: heredados, por supuesto, del objeto del conjunto general de reglas.

Al igual que los atributos y los métodos, la interfaz del objeto muestra

solamente el nombre de una regla o conjunto de reglas. En el caso de un

conjunto de reglas de encadenamiento regresivo esto podría consistir

perfectamente en el nombre del valor que se esta buscando: por ejemplo, Si

Ruta: necesitase BUSCAR Ruta:

A parte de este uso especializado, las reglas pueden ser de diferentes tipos,

Por ejemplo, se pueden tener activadores, reglas de negocios y reglas de

control. La reglas de negocio, típicamente, relacionan dos o más atributos, y los

activadores relacionan atributos con métodos.

Las reglas de negocio especifican información de segundo orden, tal como las

dependencias entre atributos, por ejemplo, una dependencia entre la edad de

un empleado y sus derechos de vacaciones. Por último, quizá sea necesario

especificar condiciones globales previas y posteriores que sean aplicables a

todos los métodos. Una regla de negocio típica en una aplicación de personal

podría incluir “cambiar el derecho de vacaciones a cinco semanas cuando el

tiempo de permanencia en la empresa sobrepase los cinco años”, como regla

en la ventana de reglas del objeto Empleado, Con esta extensión, la notación

puede resolver problemas de análisis en los que se tenga como entorno de

destino una base de datos relacional o deductiva o caracterizas orientales a

objetos. Es posible expresar de forma bastante sencilla unas reglas bastantes

complejas empleando conjuntos de reglas.

Las reglas de integridad se consideran como parte de la semántica de datos, y

se almacenan como parte de la información de tipo. Lo mas interesante en lo

que sucede en las reglas de control.

Examinemos un ejemplo sencillo, pero divertido, que implica herencia múltiple

y valores por omisión de los atributo. Supongamos que se desea construir un

juego de aventuras basado en texto. Acordemos llamemos “ búsqueda”. En una

ventura del tipo representado por la Caverna Colosal se suelen tener las

siguientes clases de entidades: situaciones, actores y cosas. El juego tiene

situaciones que pueden contener objetivo móviles (los llamaremos “ cosas”,

para evitar la confusión), objetos que están enumerados en el atributo

contenido o que poseen propiedades misteriosas descritas mediante métodos.

La vida se vuelve interesante cuando se examina la estructura de la capa

Cosa. Las cosas se pueden desglosar en tesoro que tiene un valor en puntos,

armas, que no lo tiene, y objetos útiles como comida, sacos cosas por el estilo,

se muestra una estructura provisional, en la cual se puede ver que la herencia

múltiple ha hecho su aparición: la espada enjoyada es, a la vez, un tesoro y un

arma. El tesoro contiene un valor positivo en puntos, y a las armas no tiene,

Entonces, ¿Cuáles es el valor de la espada enjoyada que podría heredar tanto

de arma como de tesoro?

Para solucionar conflictos de herencia de este tipo existen varias estrategias. El

sistema puede informar del conflicto al usuario, y pedir un valor, y esta es la

estrategia más común. Lamentablemente, detener la ejecución en un entorno

por lotes suele ser más enojoso: resulta costoso. Todas las demás

aproximaciones requieren que se codifique en el sistema parte de la semántica

de la aplicación.

También puede servir de ayuda para la semántica del objeto sea explicita y

visible. Esto ayuda a realizar la descripción de información que residía

normalmente en un depósito, tal como en las reglas de negocio para la

empresa.

Si esta regla forma parte de la interfaz, todos los demás sistemas y

componente del sistema pueden ver el significado del objeto solo a partir de si

interfaz, eliminando, de esta manera, algunas de las complejidades de la

tecnología de depósitos, llevándola al modelo objeto.

Todavía no han aparecido herramientas que hagan esto forma correcta.

Algunas veces es posible, en casos sencillos, especificar reglas que deban ser

obedecidas por todas las estrategias de control para la herencia múltiple.

Tal como se ha visto, las reglas de control no son las únicas reglas que existen

enana aplicación. Ya hemos mencionado las reglas de negocios. En ambos

casos, tiene sentido encapsular esas reglas en objetos, y mejora la

reutilizabilidad y la extensibilidad, Las reglas cuya validez en todo el sistema

pertenecen a los objetos mas grandes del sistema.

Puede resultar interesante del análisis orientado a objetos, basadas en regla ,

ayudan a enriquecer la semántica de modelos de sistemas comerciales

convencionales. Esto hace que estos modelos sean más legibles y mas

reversibles: en el modelo resulta evidente una mayor parte de las intenciones

del analista. Además, proporciona una aproximación verdaderamente orientada

a objetos a la especificación de sistemas avanzados de base de datos y de

conocimiento.

PASO AL DISEÑO – CONDICIONES FORMALES FRENTE A REGLAS

Cualquier cosa que pueda expresarse en forma de reglas podrá, en principio,

ser expresada como una combinación de condiciones previsa, posteriores e

invariantes, Sin embargo, hacer esto puede resultar complejo e ilegible. La

ventaja que aportan las reglas es la claridad y la concision. El analista podrá

juzgar qué es lo mejor en casos concretos.

A no ser que la realización vaya a ser desarrollada en un lenguaje basado en

reglas, los diseñadores que empleen SOMA sustituirán las reglas de los

análisis de SOMA por afirmaciones.

Esto es mas preciso, pero resulta menos comunicable a los usuarios, así que

es importante seguir la conversión, incluso, automatizarla.

En SOMA, las clases constan de un identificador, punteros de superclases,

punteros de clases componentes, atributos, métodos y conjuntos de reglas. Los

atributos pueden ser simplemente reservas de espacio para objetos, o bien

pueden denotar relaciones con una formación adecuada acerca de la

multiplicidad de la modalidad. Los atributos son una notación taquigráfica para

los métodos estándares de tomar y poner. Los métodos pueden especificar

afirmaciones de tres clases: condiciones previas, condiciones posteriores y

condiciones invariantes.

CASO PRÁCTICAS: SACIS

Para ver un ejemplo más concreto y realista, examinaremos algunos objetos en

SACIS, junto con sus reglas. El escenario implica una clase concreta de

suceso, una venta. Las ventas implican un cliente, que puede ser un adulto o

un niño, y una lista de objetos, que pueden ser de diferentes tipos. Se dispone

de un lector de código de barras que lee y actualiza el sistema de almacenaje,

y de un sistema, cuya tarea es asegurarse de que los objetos vendidos sean

adecuados para los propósitos del cliente.

El termino adecuado abarca varios criterios de “ajuste a nuestra necesidades”,

uno de los cuales es la seguridad.

Supongamos que un cierto cliente está intentando comprar un tubo de

pegamento. El modelo de datos convencional se ha esbozado, la decisión de si

las relaciones que se muestran como rombos en la figura deberían o no ser

objetos se posponen por el momento.

Obsérvese que existe un cierto número de estructuras de herencia múltiple

implicadas: específicamente, son las correspondientes al pegamento y al

cliente, a veces resulta conveniente indicar una herencia múltiple disyuntiva

cuando unja subclase es, o bien un B. La convención es que se utiliza una

barra doble por encima del icono AKO. Esto debe evitarse siempre que sea

posible.

La cuestión es como se puede modelar la derivación de la seguridad para este

tubo de pegamento. Dado que el tubo es pegamento hereda del material de

oficina y de juguete, no debería haber problemas de seguridad. Sin embargo,

las estructuras ilustradas muestran que hemos modelado el hecho de que se

puede abusar del pegamento, utilizándolo como droga intoxicante. En la

actualidad, la mayoría de las tiendas se niegan a vender pegamento a los niños

por esta razón; el modelado estructural de este hecho representa una regla de

negocio para tales tiendas.

En tal caso, el sistema debería permitir la venta o quizás, más estrictamente,

negarse a vender el pegamento o el modelo (que, en todo caso, resulta inútil

sin el pegamento).
Para realizar esto, el sistema debería indicar el valor de seguridad del

pegamento como muy bajo, y exploraría toda la transición completa para

buscar adquisiciones relacionadas con le pegamento.

En resumen, SOMA extiende el nemónica SOSAS de Coad, y Yourdon para

formar un eslogan más extenso: LOSAAMR. En otras palabras, los analistas

deberían desarrollar su actividad identificando.

El método que se recomienda es enfrentarse a estos pasos aproximadamente

por el orden dado, aunque la creación de capas es una actividad que está

sometida a revisiones en la mayoría de las frases. Se puede considerar el

modelo como una cascada con interacción o, preferiblemente, creo yo, como

una espiral. Es problema de estos modelos de ciclo vital se tratará.

En resumen SOMA extiende el nemónico SOSAS de Coad y Yourdon para

formar un eslogan más extenso. LOSAAMR. En otras palabras, los análisis

deberían desarrollar su actividad identificando:

 Capas

 Objetos

 Estructuras

- Estructuras de utilización

- Estructuras de clasificación

- Estructuras de composición

 Asociaciones y su semántica de datos

 Atributos con una notación que represente el tipo, validación, seguridad

y valores por omisión.

 Métodos, con una notación que represente el tratamiento de

excepciones las afirmaciones y el paso de parámetros.

 Reglas:

- Reglas de control

- Reglas de negocios

- Activadores
El método que se recomienda es enfrentarse a estos pasos aproximadamente

por el orden dado, aunque la creación de capas es una actividad que está

sometida a revisiones en la mayoria de las fases. Se puede considerar el

modelo con una cascada con interacción o preferiblemente, creo yo, como un

espiral. El proceso es controlado por riesgos, tal como sucede con la mayoría

de los modelos espirales.