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:
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:
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:
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]
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 traslativo 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 común", 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]
