BON: una metodologia de Ingenieria de Software orientada al objeto

BON es una metodologia que se inscribe en la categoria de metodologias

puramente orientadas al objeto. Tiene su origen en la metafora de la
programacion por contrato [2] junto con algunas caracteristicas del modelo de
objetos que propone Eiffel [1] y diversas influencias del proyecto europeo ESPRIT
II (Research and Development Program).
BON es un acronimo que significa Business Object Notation. Como metodologia,
aunque generalmente aparece ligada a Eiffel, su concepcion es independiente del
lenguaje pero indiscutiblemente muchas de sus tecnicas encuentran un
equivalente inmediato en Eiffel en el proceso de implementacion. Esto hace que
se facilite la construccion de herramientas CASE orientadas a este lenguaje en
particular. ISE Eiffel, por ejemplo, soporta BON con la herramienta EiffelCASE.
BON es un metodo y una notacion para analisis y diseno orientados al objeto de
sistemas de alto nivel
4
que hace enfasis en permitir un desarrollo sin transiciones , en hacer posible la
reusabilidad a gran
escala y en reflejar la confiabilidad necesaria para hacer que los componentes
reusables se acepten y utilicen por la industria del software.
Sus principios fundamentales son:
Simplicidad
Desarrollo sin costuras (sin transicion)
Software contractual
Reversibilidad y
Escalabilidad
El desarrollo sin costuras es el principio de utilizar un conjunto consistente de
conceptos y notaciones a traves del ciclo de vida del software, evitando los
problemas de impedancia de los metodos tradicionales. Una ventaja de mantener
este principio viene del hecho de que los principales esfuerzos en el desarrollo del
software se emplean, no en nuevos desarrollos sino, en mantener el software.
Una metodologia en la que no se encuentre un salto entre las diferentes etapas
esta preparada para reflejar con mayor facilidad y claridad el proceso de cambio.
Otra ventaja muy importante de mantener este principio es que facilita los
procesos de traduccion automatica. Las metodologias que promueven un proceso
de desarrollo sin costuras se ven mas como el soporte intelectual necesario a
traves del proceso completo de construccion del software que como la
especificacion de cada una de las etapas separadas del ciclo de vida del software.
Unido a esto, esta la presencia del principio de simplicidad. Este principio indica
que hay que minimizar el numero de conceptos utilizados.
El principio de reversibilidad complementa el proceso sin costuras, garantizando
que los cambios realizados en cualquier paso del proceso, incluso en la
implementacion o el mantenimiento, puedan reflejarse hacia atras, a los primeros
pasos, incluyendo el analisis. De esta manera, se garantiza el estado consistente
del proyecto. Esto significa que la continuidad debe funcionar en ambas
direcciones. Si esto no fuera posible o demasiado dificil de realizar en la practica,

los primeros niveles de modelado pasan a ser obsoletos dejando solamente el

codigo fuente de la implementacion como especificacion del sistema, con todos
los inconvenientes que esto supone.
Desde la perspectiva del software contractual, se observa la construccion de
sistemas como una sucesion de contratos precisos entre sus modulos para
garantizar confiabilidad y consistencia. La relacion de una clase y sus clientes
pasa a verse como un acuerdo formal donde cada parte expresa sus derechos y
obligaciones. Con este principio, la especificacion de un gran sistema esta
distribuida entre todas sus partes componentes. Las responsabilidades de cada
abstraccion (clase) estan especificadas por contratos expresados en funcion de
otras abstracciones. Esto garantiza que el sistema y su especificacion se moveran
acorde cuando el sistema evoluciona, en lugar de divergir gradualmente.
El principio de escalabilidad se manifiesta en terminos de la capacidad de
soportar un formalismo para representar grupos de clases progresivos y soportar
la division del problema basado en capas de abstraccion como manejo de la
complejidad estructural.
En un metodo sin costuras de analisis y diseno orientado al objeto, la continuidad
entre los pasos conduce a la conclusion de que no existe una clara distincion
entre que es lo que realmente pertenece al analisis y que pertenece al diseno. En
realidad, la idea de BON es caracterizar los objetivos y procesos especificos del
analisis y del diseno pero asegurando que el paso de uno a otro no este regido
por ninguna condicion, que las notaciones y conceptos que se emplean en cada
una de las etapas sean consistentes en el sentido de que el mismo concepto
solamente evoluciona en la medida que se avanza, y que apoyandose en la
reversibilidad, se garantice la iteratividad en el ciclo de vida del software.
El objetivo del analisis es poner un cierto orden en nuestra concepcion del mundo
real. El proposito es simplificar, dominar la complejidad mediante la reformulacion
del problema. En el analisis deben eliminarse redundancias en las
especificaciones, ruidos; encontrar inconsistencias, posponer decisiones de
implementacion, dividir el espacio del problema, tomar un cierto punto de vista y
documentarlo. El metodo BON considera que el analisis se convierte en diseno
cuando se toman decisiones de implementacion, cuando se introducen grados de
proteccion para la informacion o cuando se introducen clases que no estan
relacionadas con el espacio de objetos del problema. El diseno es un proceso que
toma por entrada una representacion del problema y la transforma en una
representacion de la solucion, regresando al analisis si es necesario. En el diseno,
las clases obtenidas en el analisis se extienden, generalizan y se transforma su
representacion en un esquema facilmente traducible a un lenguaje de
programacion orientado al objeto. Se anade la especificacion de nuevas clases
que aparecen como interfaz con el exterior del sistema, otras que son de utilidad
basica para la construccion del sistema (p.e. clases contenedoras, etc.) y otras
que son consideradas como clases de aplicacion que tratan con informacion
dependiente de la maquina o del sistema, con persistencia de objetos, manejo y
recuperacion de errores, etc.
En BON se modelan tanto el espacio del problema como el espacio de la solucion
como abstracciones de datos que encapsulan servicios. En el modelado, aunque

lo primero en que se piense sea en un servicio, debe buscarse la abstraccion

(clase) subyacente que representa a aquellos individuos que ofrecen tal servicio.
El primer principio es considerar las clases como una representacion de tipos de
datos abstractos que tienen un estado interno y ofrecen servicios, opuesto al
criterio las cosas que hacen que esta mas cerca de las tecnicas procedurales.
Las clases no se ubican aisladamente sino que se agrupan en clusters. Durante el
analisis, los clusters ayudan en cuanto agrupan clases de acuerdo con un criterio
de proximidad basado en funcionalidad de subsistema, en nivel de abstraccion o
en el punto de vista del usuario final. En el diseno, son utilizados frecuentemente
como una tecnica estructurada para visualizar selectivamente las conexiones
entre las clases. Es muy comun comenzar por un cluster general y luego ir
determinando otros despues de haber hecho ciertos agrupamientos de clases. Es
importante ubicar el lugar de una clase dentro de la estructura completa. Esto
implica que encontrar clases relacionadas es mas significativo que encontrar una
clase aislada. El uso de los clusters es una tecnica para dotar de escalabilidad al
metodo.
Cada etapa, analisis y diseno, en BON aporta al modelo general desde dos puntos
de vista: arquitectura y comportamiento. El resultado es un modelo subdividido,
dependiendo de lo que se describe, en modelo estatico y modelo dinamico. Las
actividades globales que describe el metodo para ir creando dichos modelos se
describen en la tabla 1 mientras que en las tablas 2 y en la figura 1 se describen
los elementos graficos mas generales que se utilizan en la descripcion del
modelo.
Como una tarea fundamental en el metodo aparece que antes de considerar
completo el analisis y diseno y pasar a la fase de implementacion, se debe
comenzar un proceso de generalizacion. En este proceso debe analizarse si la
arquitectura del sistema es suficientemente general para maximizar futuras
reutilizaciones. De esta manera, del conjunto de clases obtenidas se factorizan
recursos comunes en clases de alto nivel (por herencia o por genericidad) y las
clases existentes se convierten en versiones especializadas de estas ultimas.

http://www.infor.uva.es/~yania/eiffel.pdf

BON: Una metodologia de Ingenieria de Software

Orientada a Objeto
BON es una metodologia que se inscribe en la categoria de metodologias
puramente orientadas al objeto. Tiene su origen en la filosofia de diseno y
programacion por contrato [2], junto con algunas caracteristicas del modelo de
objetos propuesto por Eiffel [1] y diversas influencias del proyecto europeo
ESPRIT II (Research and Development Program).

BON es un acronimo que significa Business Object Notation. Como metodologia,

aunque generalmente aparece ligada a Eiffel, su concepcion es independiente de
este lenguaje pero indiscutiblemente muchas de sus tecnicas encuentran un
equivalente inmediato en Eiffel en el proceso de implementacion. Esto hace que
se facilite la construccion de herramientas CASE orientadas a este lenguaje en
particular ISE Eiffel, por ejemplo, soporta BON con la herramienta EiffelCASE.
BON es un metodo y una notacion para analisis y diseno orientados a objeto de
sistemas de alto nivel, que hace enfasis en permitir un desarrollo sin
transiciones6, en hacer posible la reutilizacion del software a gran escala y en

reflejar la confianza necesaria para hacer que los componentes reutilizables se

acepten y utilicen por la industria del software.
Sus principios fundamentales son:
Simplicidad
Desarrollo sin costuras
Software contractual Reversibilidad
Escalabilidad
El desarrollo sin costuras es el principio de utilizar un conjunto consistente de
conceptos y notaciones a traves del ciclo de vida del software, evitando los
problemas de impedancia de los metodos tradicionales7. Una ventaja de
mantener este principio viene del hecho de que los principales esfuerzos en el
desarrollo del software se emplean, no en nuevos desarrollos sino, en mantener
el software. Una metodologia en la que no se encuentre un salto entre las
diferentes etapas esta preparada para reflejar con mayor facilidad y claridad el
proceso de cambio. Otra ventaja muy importante del seamless es que facilita los
procesos de traduccion automatica. Las metodologias que promueven un proceso
de desarrollo sin costuras se ven mas como el soporte intelectual necesario a
traves del proceso completo de construccion del software que como la
especificacion de cada una de las etapas separadas del ciclo de vida del software.
Unido a esto, esta la presencia del principio de simplicidad, esto es, este principio
indica que hay que minimizar el numero de conceptos utilizados.
En cuanto al principio de software contractual ya ha quedado explicado en el
apartado anterior.
El principio de reversibilidad complementa el proceso sin costuras, garantizando
que los cambios realizados en cualquier paso del proceso, incluso en la
implementacion o el mantenimiento, puedan reflejarse hacia atras en los
primeros pasos. De esta manera, se garantiza el estado consistente del proyecto,
lo que significa que la continuidad debe funcionar en ambas direcciones. Si esto
no fuera posible, o demasiado dificil de realizar en la practica, los primeros
niveles de modelado pasan a ser obsoletos dejando solamente el codigo fuente
de la implementacion como especificacion del sistema, con todos los
inconvenientes que esto supone.
El principio de escalabilidad se manifiesta en terminos de la capacidad de
soportar un formalismo para representar grupos de clases progresivos y soportar
la division del problema basado en capas de abstraccion como manejo de la
complejidad estructural.
En un metodo de analisis y diseno orientado al objeto sin costuras, la continuidad
entre los pasos conduce a la conclusion de que no existe una clara distincion
entre que es lo que realmente pertenece al analisis y que pertenece al diseno. En
realidad, la idea de BON es caracterizar los objetivos y procesos especificos del
analisis y del diseno pero asegurando que el paso de uno a otro no este regido
por ninguna condicion, que las notaciones y conceptos que se emplean en cada
una de las etapas sean consistentes en el sentido de que el mismo concepto
solamente evoluciona en la medida que se avanza, y que apoyandose en la
reversibilidad, se garantice la iteratividad en el ciclo de vida del software.

El objetivo del analisis es poner un cierto orden en nuestra concepcion del mundo
real. El proposito es simplificar, dominar la complejidad mediante la reformulacion
del problema. En el analisis deben eliminarse redundancias en las
especificaciones, ruidos; encontrar inconsistencias, posponer decisiones de
implementacion, dividir el espacio del problema, tomar un cierto punto de vista y
documentarlo. El metodo BON considera que el analisis se convierte en diseno
cuando se toman decisiones de implementacion, cuando se introducen grados de
proteccion para la informacion o cuando se introducen clases que no estan
relacionadas con el espacio de objetos del problema. El diseno es un proceso que
toma por entrada una representacion del problema y la transforma en una
representacion de la solucion, regresando al analisis si es necesario. En el diseno,
las clases obtenidas en el analisis se extienden, generalizan y se transforma su
representacion en un esquema facilmente traducible a un lenguaje de
programacion orientado al objeto. Se anade la especificacion de nuevas clases
que aparecen como interfaz con el exterior del sistema, otras que son de utilidad
basica para la construccion del sistema (clases contenedoras...) y aquellas que
son consideradas como clases de aplicacion que tratan con informacion
dependiente de la maquina o del sistema, con persistencia de objetos, manejo y
recuperacion de errores.
En BON se modelan tanto el espacio del problema como el espacio de la solucion
como abstracciones de datos que encapsulan servicios. En el modelado, aunque
lo primero en que se piense sea en un servicio, debe buscarse la abstraccion
(clase) subyacente que representa a aquellos individuos que ofrecen tal servicio.
El primer principio es considerar las clases como una representacion de tipos de
datos abstractos que tienen un estado interno y ofrecen servicios, opuesto al
criterio las cosas que hacen que esta mas cerca de las tecnicas procedurales.
Las clases no se ubican aisladamente sino que se agrupan en clusters. Durante el
analisis, los clusters ayudan en cuanto agrupan clases de acuerdo con un criterio
de proximidad basado en funcionalidad de subsistema, en nivel de abstraccion o
en el punto de vista del usuario final. En el diseno, son utilizados frecuentemente
como una tecnica estructurada para visualizar selectivamente las conexiones
entre las clases. Es muy comun comenzar por un cluster general y luego ir
determinando otros despues de haber hecho ciertos agrupamientos de clases. Es
importante ubicar el lugar de una clase dentro de la estructura completa. Esto
implica que encontrar clases relacionadas es mas significativo que encontrar una
clase aislada. El uso de los clusters es una tecnica para dotar de escalabilidad al
metodo.
Cada etapa, analisis y diseno, en BON aporta al modelo general desde dos puntos
de vista distintos: arquitectura y comportamiento. El resultado es un modelo
subdividido en modelo estatico y modelo dinamico. Las actividades globales que
describe el metodo para ir creando dichos modelos se describen en la Tabla B
mientras que en la Tabla C y en la Figura A se describen los elementos graficos
mas generales que se utilizan en la descripcion del modelo.
Es de destacar, que como una tarea fundamental en el metodo, de considerar
completo el analisis y diseno y pasar a la fase de implementacion, se propone
comenzar un proceso de generalizacion. En este proceso debe analizarse si la

arquitectura del sistema es suficientemente general para maximizar futuras

reutilizaciones. De esta manera, del conjunto de clases obtenidas se factorizan
recursos comunes en clases de alto nivel (por herencia o por genericidad) y las
clases existentes se convierten en versiones especializadas de estas ultimas.
http://gredos.usal.es/jspui/bitstream/10366/121990/1/DIA_GarciPenalvo_CrespoGo
nzalez_Implicaciones_Eiffel_DOO.pdf

2. Introduccion a BON
BON (Business Object Notation)[3, 7] es un lenguaje de modelado para
especificar y describir sistemas bajo el paradigma de orientacion a objetos. Una
de sus caracteristicas es que no solo provee un lenguaje grafico para la
descripcion de sistemas, sino que tambien posee un proceso recomendado para
el desarrollo de software. Otra caracteristica importante es que todo modelo
grafico BON tiene una forma textual equivalente. BON es extremadamente simple
en comparacion a otros lenguajes: solo posee 2 diagramas de modelado, y no
permite diferentes vistas de un diseno, lo cual evita las in- consistencias que
puedan ser introducidas al existir distintas descripciones de un mismo
componente.
BON fue disenado para soportar tres tecnicas principales: Seamlessness,
Reversibilidad y Diseno por Contratos.
Seamlessness: se refiere al principio de utilizar un conjunto consistente de
conceptos y nota- ciones a traves del ciclo de vida del software, desde el analisis
a la implementacion y manten- imiento. Por lo que el paso siguiente en cada
etapa del desarrollo es directo. Los beneficios de seamlessness son numerosos.
Reversibilidad: los cambios producidos en una etapa del desarrollo pueden ser
automatica- mente reflejados en las etapas anteriores. Por ejemplo, un cambio en
una clase de Eiffel es directamente reflejada en cambios sobre la clase de diseno.
Diseno por Contratos: es una metodologia de desarrollo de software orientado a
objetos que se basa en el concepto de contrato. Un contrato es una
especificacion de las responsabilidades y caracteristicas de una componente de
software. Esta nocion esta basada en la idea de pre- postcondicion, introducida
por Hoare y Floyd en los anos 70 - lo que permite producir software de alta
calidad y facilmente mantenible.
Al igual que otros lenguajes orientados a objetos, el principal mecanismo de
especificaciones en un modelo BON es el concepto de clase. Una clase en BON
introduce un nuevo tipo y se la considera un modulo. Las clases BON estan
compuestas de: un nombre, un conjunto de features, y un contrato compuesto de
precondicion, postcondicion e invariante de clase. El invariante es una asercion
que todas las instancias de la clase deben satisfacer. El contrato especifica las
funcionalidades de la clase, y es expresado utilizando el lenguaje de aserciones
que posee BON, el cual esta basado en la logica de primer orden tipada.
Los features (o caracteristicas) de una clase pueden ser queries o commands:

Queries: Dentro de esta categoria entran las funciones y atributos de los

lenguajes tradicionales.
Es importante destacar que las queries no producen cambios en el estado del
sistema.
Commands: Corresponden a los procedimientos de los lenguajes Orientados a
Objetos tradi- cionales. Se ejecutan para producir cambios de estado.
Cada feature tiene asociada una restriccion de visibilidad, y puede tener
diferentes modos de imple- mentacion, puede ser abstracta, efectiva o redifinida.
Es interesante destacar que BON solo soporta dos tipos de relaciones dentro de
un diagrama de clases:
Relacion Cliente-Proveedor: indica que una clase (el cliente), utiliza algun servicio
brindado por otra clase (el proveedor). Hay tres tipos de relaciones clienteproveedor en BON: asociacion, agregacion y asociacion compartida (shared
association).
Relacion de Herencia: una clase hereda comportamiento de una o mas clases
padres. La heren- cia introduce una relacion de refinamiento sobre los contratos
de las clases asociadas. Ademas, en BON, una clase hijo es considerada un
subtipo de sus clases padres.
http://sedici.unlp.edu.ar/bitstream/handle/10915/23067/Documento_completo.pdf
?sequence=1
Revisar
http://biblo.una.edu.ve/docu.7/bases/marc/texto/t35548.pdf
Paginas 38 - 55 y Paginas 144 145

TCNICAS DE ANLISIS DE ORIENTADO A OBJETOS

LAS PERSPECTIVAS DEL ANLISIS ORIENTADO A OBJETOS AOO
En el contexto del desarrollo de sistemas de software con orientacion a objetos,
se entiendepor Analisis Orientado a Objetos al proceso de construccion de
modelos del dominio delproblema, identificando y especificando un conjunto de
objetos semanticos que interactuan yse comportan de acuerdo a los
requerimientos del sistema. Los objetos semanticos sonaquellos que poseen un
significado especifico en el dominio del problema.De acuerdo a esta definicion, el
AOO es esencialmente basada en modelado. Es razonableesperar entonces, que
la especificacion resultante de la aplicacion de tecnicas de AOO resulteen
multiples modelos y multiples notaciones. En esta perspectiva, el proceso de
construccionde los modelos del dominio del problema debe considerar diferentes
aspectos o puntos devista. Estos aspectos constituyen las dimensiones del
modelado orientado a objetos.El modelado orientado a objetos comprende, como
minimo, dos aspectos relativamenteortogonales o dimensiones para describir un
sistema complejo: la dimension estructural delos objetos y la dimension dinamica
del comportamiento. Puede ser considerada tambien unadimension adicional: la

dimension funcional de los requerimientos.La dimension estructural de los objetos

se centra en el aspecto estatico o pasivo. Estarelacionada con la estructura
estatica de los objetos que forman parte del sistema. Laestructura incluye la
identidad de cada objeto, su clasificacion, su encapsulamiento (susatributos y sus
operaciones) y sus relacionamientos estaticos (jerarquias de herencia,agregacion,
composicion y asociaciones especificas).La dimension dinamica del
comportamiento tiene que ver con el aspecto dinamico o activo,por esto describe
el comportamiento y la colaboracion de los objetos que constituyen elsistema. El
comportamiento es reflejado por medio de estados (pasos dentro del ciclo de
vidadel objeto que caracterizan comportamientos diferentes del mismo),
transiciones entre estosestados, eventos (hechos que ocurren y que producen las
transiciones) y acciones(representadas por los metodos de los objetos, pudiendo
ocurrir durante las transiciones odurante la permanencia en los estados). La
colaboracion es representada por modelos que
muestran el flujo de eventos o mensajes entre los objetos. Asi algunas acciones
generadas enun objeto pueden gatillar transiciones, bajo la forma de eventos, en
otros objetos.
UNA CLASIFICACIN PARA LAS TCNICAS DE AOO
La clasificacion propuesta utiliza como criterio basico el origen de la tecnica, es
decir, elconjunto de conceptos a partir del cual se origino la tecnica. Ademas, es
considerado elenfasis que las tecnicas de AOO otorgan a los conceptos, aspectos,
procedimientos orepresentaciones en cada una de las dimensiones del
modelado.Las categorias usadas para clasificar las tecnicas son: textuales,
evolutivas, integracionistas,reversas y comportamentales. La figura 1 muestra la
estructura de esta clasificacion.
Las Tecnicas Textuales:
Las tecnicas denominadas textuales son aquellas que se basan endescripciones
informales, pero precisas, escritas en lenguaje natural para identificar
objetos,atributos y operaciones tanto del dominio del problema como del dominio
de la solucion, atraves de un analisis sintactico de sustantivos, adjetivos, verbos y
adverbios.Las tecnicas de esta categoria tienen su origen fuera del paradigma de
la orientacion aobjetos, especificamente en el trabajo de Abbott, que propone
disenar programa en Ada apartir de descripciones informales en ingles. Sin
embargo, estas tecnicas son insuficientespara abordar problemas mas complejos
y pueden ser consideradas como sobrepasadas. Seconsideran aqui solo por su
relevancia historica.
Las Tecnicas Evolutivas:
Las tecnicas evolutivas son aquellas producto de la extension oevolucion de
tecnicas dirigidas por alguna de las dimensiones del modelado
(estructural,dinamica y/o funcional) y su complementacion con otros aspectos del
modelado. Estacategoria de tecnicas
puede ser subdividida segun la dimension dominante en dirigidas por
datos, dirigidas por procesos y dirigidas por dinamica.Sin duda esta es la
categoria mas poblada por razones obvias, las tecnicas originales sontodas

ampliamente conocidas y probadas en el desarrollo de sistema de software.

Entoncesparece natural intentar extenderlas para la orientacion a objetos.
Las Tecnicas Integracionistas:
Esta categoria representa a aquellas tecnicas que integranmodelos separados de
las diferentes dimensiones.Como tecnica representativa de esta categoria se
encuentra la de Rumbaugh91. Los autoresproponen una tecnica de desarrollo de
software orientado a objetos denominada OMT(Object Modeling Technique), que
incluye explicitamente el AOO como la construccion detres modelos, uno para
cada dimension, que especifiquen el dominio del problemaconsiderando los
requerimientos. El procedimiento del AOO esta intimamente ligado a
laconstruccion de modelos de estos tres aspectos: modelado estructural,
modelado dinamico ymodelado funcional. El orden en que debe ser realizado el
modelado es: 1) objetos, 2)dinamica y 3) funcionalidad.Para el modelado de
objetos se utiliza una extension del modelo entidad-relacionamiento. Enel
modelado dinamico es utilizada una variante de los statecharts. En el modelado
funcionalson usados DFD extendidos con flujos de control. La integracion final de
estos modelos, porejemplo la asociacion de las funciones (del modelo funcional) y
las acciones (del modelodinamico) a los objetos, es hecha en una fase posterior
denominada diseno de objetos.La tecnica OMT se ha transformado en una de las
tecnicas mas divulgadas, existiendo porejemplo diferentes herramientas CASE
(Computer-Aided Software Engineering) queincluyen su notacion.
Las Tecnicas Reversas:
son aquellas originadas a partir de necesidades de implementacion,como por
ejemplo el soporte a conceptos de lenguajes de programacion orientados a
objetosespecificos (por ejemplo Smalltalk, C++, Eiffel o Ada2). Esta categoria
puede serfacilmente confundida con otras, pues al soportar conceptos de un
lenguaje de programacionorientado a objetos puede ser apropiado utilizar
enfoques, notaciones y procedimientos deotra naturaleza.La tecnica escogida
como mas representativa es la propuesta por Nerson, que define unatecnica de
analisis y diseno orientados a objetos para el lenguaje Eiffel, usando la notacion
deobjetos mejorada (Better Object Notation o BON). Esta tecnica consiste en tres
pasos:1) identificacion, designacion y clustering de clases;2) identificacion de
eventos y protocolos de comunicacion entre objetos; y 3) definicion de clases y
diseno preliminar de la arquitectura basica.La tecnica se basa en conceptos de
lenguaje Eiffel (cluster, relacionamientocliente/proveedor, clases diferidas y
modelos estatico/dinamico), la tecnica OBA (presentadaen la proxima
seccion).Otra tecnica que puede ser clasificada en esta categoria es la tecnica
mas reciente de Boochque ha evolucionado desde un metodo especifico de
diseno para el lenguaje Ada hasta unapropuesta mas general. Tambien en la linea
del lenguaje Ada se encuentran las propuestasde analisis de requerimientos
orientados a objetos.
PRINCIPAL FORTALEZA DE LAS TCNICAS DE AOO
El aspecto mas consolidado en la mayoria de las tecnicas y que constituye su
principalfortaleza es el modelado de la dimension estructural de los objetos.
Como fue indicadoanteriormente la causa de esto es que la mayoria de las

propuestas utilizan los conceptos delmodelado semantico en base a modelos

extendidos entidad-relacionamiento. Estas tecnicasposeen un desarrollo de mas
de 20 anos a partir del trabajo original de Chen.En este sentido la identificacion y
especificacion de objetos, clases, metodos, atributos,asociaciones dependientes
del dominio y jerarquias de herencia es la principal fortaleza de lastecnicas de
AOO.
https://es.scribd.com/doc/60898750/Analisis-Orientado-a-Objetos