Método Shlaer-Mellor

El método Shlaer–Mellor , también conocido como análisis de sistemas orientado a objetos ( OOSA ) o análisis orientado a objetos ( OOA ) es una metodología de desarrollo de software orientada a objetos introducida por Sally Shlaer y Stephen Mellor en 1988. El método hace que el análisis documentado sea tan preciso que es posible implementar el modelo de análisis directamente por traducción a la arquitectura de destino, en lugar de elaborar cambios de modelo a través de una serie de modelos más específicos de la plataforma. En el nuevo milenio, el método Shlaer–Mellor ha migrado a la notación UML, convirtiéndose en UML ejecutable . ^[1]

El método Shlaer-Mellor es una de varias metodologías de desarrollo de software que llegaron a fines de la década de 1980. Las más conocidas fueron el análisis y diseño orientado a objetos (OOAD) de Grady Booch , la técnica de modelado de objetos (OMT) de James Rumbaugh , la ingeniería de software orientada a objetos de Ivar Jacobson y el análisis orientado a objetos (OOA) de Shlaer y Mellor. ^{[2] [3]} Estos métodos habían adoptado un nuevo paradigma orientado a objetos para superar las debilidades establecidas en los métodos de análisis estructurado y diseño estructurado (SASD) existentes de las décadas de 1960 y 1970. ^[4] De estos problemas bien conocidos, Shlaer y Mellor eligieron abordar:

• La complejidad de los diseños generados mediante el uso de métodos de análisis estructurado y diseño estructurado (SASD).
• El problema de mantener la documentación del análisis y el diseño a lo largo del tiempo.

Antes de la publicación de su segundo libro en 1991, Shlaer y Mellor habían dejado de denominar a su método "Análisis de sistemas orientados a objetos" en favor de simplemente "Análisis orientado a objetos". El método comenzó a centrarse en el concepto de diseño recursivo (DR), que posibilitó el aspecto de traducción automática del método.

Lo que hace que Shlaer-Mellor sea único entre los métodos orientados a objetos es:

• el grado en que se lleva a cabo la descomposición semántica orientada a objetos,
• la precisión de la notación Shlaer-Mellor utilizada para expresar el análisis, y
• el comportamiento definido de ese modelo de análisis en tiempo de ejecución.

La solución general adoptada por los métodos de análisis y diseño orientados a objetos a estos problemas particulares con el análisis y diseño estructurado fue pasar de la descomposición funcional a la descomposición semántica. ^[5] Por ejemplo, se puede describir el control de un tren de pasajeros como:

cargar pasajeros, cerrar puertas, arrancar el tren, detener el tren, abrir puertas, descargar pasajeros .

Luego, el diseño se centra en el comportamiento de las puertas, los frenos y los pasajeros, y en cómo esos objetos (puertas, frenos, etc.) se relacionan y se comportan dentro del dominio del tren de pasajeros. Otros objetos, que proporcionan servicios utilizados por el dominio del tren de pasajeros, se modelan en otros dominios conectados con el dominio del tren de pasajeros.

El objetivo del método Shlaer-Mellor es lograr que el análisis documentado sea tan preciso que sea posible implementar el modelo de análisis directamente mediante traducción en lugar de mediante elaboración. En la terminología de Shlaer-Mellor, esto se denomina diseño recursivo. En la terminología actual (2011), diríamos que el método Shlaer-Mellor utiliza una forma de arquitectura basada en modelos (MDA) normalmente asociada con el lenguaje de modelado unificado (UML).

Al adoptar este enfoque translativo, la implementación siempre se genera (manualmente o, más habitualmente, automáticamente) directamente a partir del análisis. Esto no quiere decir que no exista diseño en Shlaer-Mellor, sino que se considera que existe una máquina virtual que puede ejecutar cualquier modelo de análisis de Shlaer-Mellor para cualquier combinación particular de plataforma de hardware/software.

Este concepto es similar al de las máquinas virtuales que se encuentran en el corazón del lenguaje de programación Java y del lenguaje de programación Ada , pero existen en el nivel de análisis en lugar del nivel de programación. Una vez diseñadas e implementadas, estas máquinas virtuales se pueden reutilizar en una amplia gama de aplicaciones. Las máquinas virtuales Shlaer-Mellor están disponibles comercialmente a través de varios proveedores de herramientas, en particular Abstract Solutions, Mentor Graphics y Pathfinder Solutions.

Shlaer–Mellor propone una descomposición semántica en múltiples dominios (problemáticos). ^[6]

• La división entre los modelos de análisis y diseño : el dominio de análisis expresa con precisión lo que debe hacer el sistema, el dominio de diseño es un modelo de cómo funciona la máquina virtual Shlaer-Mellor para una plataforma de hardware y software en particular. Estos modelos son disjuntos, la única conexión es la notación utilizada para expresar los modelos.
• Descomposición dentro del dominio de análisis donde los requisitos del sistema se modelan y agrupan en torno a temas específicos y disjuntos. Para volver al ejemplo anterior del tren de pasajeros, se pueden crear modelos semánticos individuales basados ​​en actuadores de puertas, controles de motores y sistemas de frenado. Cada agrupación se considera y modela de forma independiente. La única relación definida entre las agrupaciones son las dependencias; por ejemplo, una aplicación de tren de pasajeros puede depender tanto de la actuación de las puertas como del control de motores. Los sistemas de frenado pueden depender del control de motores.

Los modelos de dominio de actuadores de puertas, controles de motores y sistemas de frenado normalmente se considerarían como dominios de servicio genéricos reutilizables, mientras que el dominio del controlador de trenes de pasajeros probablemente sea un dominio de aplicación muy específico del producto.

Un sistema particular se compone de dominios y de puentes definidos entre los dominios. Un puente se describe en términos de los supuestos mantenidos por el dominio que actúa como cliente conectado a un dominio que actúa como servidor. ^[7]

Uno de los requisitos para la generación automatizada de código es modelar con precisión las acciones dentro de las máquinas de estados finitos utilizadas para expresar el comportamiento dinámico de los objetos Shlaer-Mellor.

Shlaer-Mellor es único entre los métodos de análisis orientados a objetos en cuanto a la expresión gráfica de este tipo de comportamiento secuencial, como los diagramas de flujo de datos de acción (ADFD). En la práctica, las herramientas que respaldaban a Shlaer-Mellor proporcionaban un lenguaje de acción preciso. Los lenguajes de acción reemplazaron al enfoque ADFD, por lo que todas las acciones se escriben en forma de texto.

El enfoque traslacional del método Shlaer-Mellor se presta a entornos de simulación y prueba automatizados ^[8] (al cambiar la plataforma de destino durante la generación de código), y esto puede explicar en parte la popularidad de Shlaer-Mellor y otros métodos basados ​​en MDA al desarrollar sistemas integrados , donde las pruebas en sistemas de destino, por ejemplo, teléfonos móviles o sistemas de gestión de motores, son particularmente difíciles.

Lo que hace que estas pruebas sean útiles y productivas es el concepto de la máquina virtual Shlaer-Mellor. Como ocurre con la mayoría de los métodos OOA/OOD, Shlaer-Mellor es un entorno de transmisión de mensajes impulsado por eventos. En esta visión genérica, la máquina virtual Shlaer-Mellor exige un mecanismo de eventos priorizados construido en torno a los modelos de estado , lo que permite la ejecución simultánea de acciones en diferentes máquinas de estado.

Dado que cualquier implementación de Shlaer–Mellor requiere que este modelo sea totalmente compatible, las pruebas bajo simulación pueden ser un modelo muy parecido a las pruebas en la plataforma de destino. Si bien la funcionalidad que depende en gran medida de las restricciones de tiempo puede ser difícil de probar, la mayor parte del comportamiento del sistema es altamente predecible debido al modelo de ejecución priorizada.

Nunca ha existido un lenguaje textual universalmente aceptado para expresar acciones dentro de la comunidad Shlaer-Mellor. Los proveedores de herramientas han definido sus propios lenguajes de acción controlados y protegidos por derechos de autor.

Graham (1994) describió el método Shlaer-Mellor como un ejemplo temprano de análisis orientado a objetos, que en realidad no podía considerarse orientado a objetos . Según Graham, el método carece de "noción de herencia. Como se describe en su libro, era poco más que una extensión basada en objetos del modelado de datos ". ^[9] En línea con el comentario de Capretz (1996) sostiene que el método Shlaer-Mellor "no tiene en cuenta la gran mayoría de las ideas orientadas a objetos y se prescribe una notación gráfica ordinaria", que se toma principalmente "de diagramas de entidad-relación y diagramas de flujo de datos que se encuentran en otros métodos estructurados". ^[10]

• Sistema embebido
• UML ejecutable
• Máquina de estados finitos (MSF)
• Descomposición funcional
• Yo-OOA
• Paralelismo masivo
• Arquitectura basada en modelos (MDA)
• Análisis estructurado
• Lenguaje de modelado unificado (UML)

• Stephen Mellor (2002) Make Models Be Assets, Comunicaciones de la ACM Volumen 45 , 11:76-87 (noviembre de 2002), 2002
• Rodney C. Montrose (2001) Desarrollo orientado a objetos utilizando el método Shlaer-Mellor . Project Technology, Inc.
• Sally Shlaer , Stephen Mellor (1988) Análisis de sistemas orientados a objetos: modelado del mundo en datos , Yourdon Press. ISBN  0-13-629023-X
• Sally Shlaer , Stephen Mellor (1991) Ciclos de vida de los objetos: modelado del mundo en estados , Yourdon Press. ISBN 0-13-629940-7 
• Leon Starr (1996) Cómo construir modelos de objetos de Shlaer-Mellor . Prentice Hall. ISBN 0-13-207663-2 

Wikiversidad tiene recursos de aprendizaje sobre diseño de software orientado a objetos

• Shlaer–Mellor y el portal UML ejecutable, blog 2008-2011
• Referencias de Shlaer-Mellor y UML ejecutable, 2008
• Blog del metamodelo Shlaer-Mellor, 2011