El análisis y diseño orientado a objetos ( OOAD ) es un enfoque técnico para analizar y diseñar una aplicación, sistema o negocio mediante la aplicación de programación orientada a objetos , así como el uso de modelado visual durante todo el proceso de desarrollo de software para guiar la comunicación de las partes interesadas y la calidad del producto.
OOAD en la ingeniería de software moderna generalmente se lleva a cabo de forma iterativa e incremental. Los resultados de las actividades de OOAD son modelos de análisis (para OOA) y modelos de diseño (para OOD), respectivamente. La intención es que estos se perfeccionen y evolucionen continuamente, impulsados por factores clave como los riesgos y el valor comercial.
En los primeros días de la tecnología orientada a objetos, antes de mediados de la década de 1990, había muchas metodologías diferentes en competencia para el desarrollo de software y el modelado orientado a objetos , a menudo vinculadas a proveedores específicos de herramientas de ingeniería de software asistida por computadora (CASE). Las principales preocupaciones en ese momento eran la falta de notaciones estándar, términos consistentes y guías de procesos, lo que degradaba la eficiencia de la comunicación y alargaba las curvas de aprendizaje.
Algunas de las primeras metodologías orientadas a objetos más conocidas fueron inspiradas por gurús como Grady Booch , James Rumbaugh , Ivar Jacobson (los Tres Amigos ), Robert Martin , Peter Coad , Sally Shlaer , Stephen Mellor y Rebecca Wirfs-Brock. .
En 1994, los Tres Amigos de Rational Software comenzaron a trabajar juntos para desarrollar el Lenguaje Unificado de Modelado (UML). Más tarde, junto con Philippe Kruchten y Walker Royce (hijo mayor de Winston Royce ), lideraron una misión exitosa para fusionar sus propias metodologías, OMT , OOSE y el método Booch , con diversos conocimientos y experiencias de otros líderes de la industria en el Proceso Unificado Racional. (RUP), un marco y una guía integral de procesos iterativos e incrementales para aprender las mejores prácticas de la industria en materia de desarrollo de software y gestión de proyectos. [1] Desde entonces, la familia de Procesos Unificados se ha convertido probablemente en la metodología y modelo de referencia más popular para el análisis y diseño orientado a objetos.
El ciclo de vida del software generalmente se divide en etapas, que van desde descripciones abstractas del problema hasta diseños, luego código y pruebas y, finalmente, implementación. Las primeras etapas de este proceso son el análisis y el diseño. La fase de análisis también suele denominarse "adquisición de requisitos".
En algunos enfoques del desarrollo de software, conocidos colectivamente como modelos en cascada, los límites entre cada etapa deben ser bastante rígidos y secuenciales. El término "cascada" fue acuñado para que tales metodologías significaran que el progreso iba secuencialmente en una sola dirección, es decir, una vez que se completaba el análisis, entonces y sólo entonces se comenzaba el diseño y era raro (y se consideraba una fuente de error) que un problema de diseño requirió un cambio en el modelo de análisis o cuando un problema de codificación requirió un cambio en el diseño.
La alternativa a los modelos en cascada son los modelos iterativos. Esta distinción fue popularizada por Barry Boehm en un artículo muy influyente sobre su Modelo en espiral para el desarrollo de software iterativo. Con los modelos iterativos es posible trabajar en varias etapas del modelo en paralelo. Así, por ejemplo, es posible (y no verse como una fuente de error) trabajar en análisis, diseño e incluso código todo el mismo día y que los problemas de una etapa afecten a los problemas de otra. El énfasis en los modelos iterativos es que el desarrollo de software es un proceso que requiere mucho conocimiento y que cosas como el análisis no pueden entenderse completamente sin comprender los problemas de diseño, que los problemas de codificación pueden afectar el diseño, que las pruebas pueden arrojar información sobre cómo funciona el código o incluso el diseño debe modificarse, etc. [2]
Aunque es posible realizar un desarrollo orientado a objetos utilizando un modelo en cascada, en la práctica la mayoría de los sistemas orientados a objetos se desarrollan con un enfoque iterativo. Como resultado, en los procesos orientados a objetos el "análisis y el diseño" a menudo se consideran al mismo tiempo.
El paradigma orientado a objetos enfatiza la modularidad y la reutilización. El objetivo de un enfoque orientado a objetos es satisfacer el "principio abierto-cerrado" . Un módulo está abierto si admite extensión o si el módulo proporciona formas estandarizadas de agregar nuevos comportamientos o describir nuevos estados. En el paradigma orientado a objetos, esto a menudo se logra creando una nueva subclase de una clase existente. Un módulo está cerrado si tiene una interfaz estable bien definida que todos los demás módulos deben usar y que limita la interacción y los posibles errores que pueden introducirse en un módulo por cambios en otro. En el paradigma orientado a objetos esto se logra definiendo métodos que invocan servicios en objetos. Los métodos pueden ser públicos o privados, es decir, ciertos comportamientos que son exclusivos del objeto no están expuestos a otros objetos. Esto reduce una fuente de muchos errores comunes en la programación de computadoras. [3]
El ciclo de vida del software generalmente se divide en etapas que van desde descripciones abstractas del problema hasta diseños, luego código y pruebas y finalmente implementación. Las primeras etapas de este proceso son el análisis y el diseño. La distinción entre análisis y diseño a menudo se describe como "qué versus cómo". En el análisis, los desarrolladores trabajan con usuarios y expertos en el dominio para definir qué se supone que debe hacer el sistema. Se supone que los detalles de implementación se ignoran total o parcialmente (dependiendo del método particular) en esta fase. El objetivo de la fase de análisis es crear un modelo funcional del sistema independientemente de limitaciones como la tecnología apropiada. En el análisis orientado a objetos, esto normalmente se hace mediante casos de uso y definiciones abstractas de los objetos más importantes. La fase de diseño posterior refina el modelo de análisis y toma la tecnología necesaria y otras opciones de implementación. En el diseño orientado a objetos el énfasis está en describir los diversos objetos, sus datos, comportamiento e interacciones. El modelo de diseño debe tener todos los detalles necesarios para que los programadores puedan implementar el diseño en código. [4]
El propósito de cualquier actividad de análisis en el ciclo de vida del software es crear un modelo de los requisitos funcionales del sistema que sea independiente de las restricciones de implementación.
La principal diferencia entre el análisis orientado a objetos y otras formas de análisis es que mediante el enfoque orientado a objetos organizamos los requisitos en torno a objetos, que integran tanto comportamientos (procesos) como estados (datos) modelados a partir de objetos del mundo real con los que interactúa el sistema. En otras metodologías de análisis o tradicionales, los dos aspectos: procesos y datos se consideran por separado. Por ejemplo, los datos pueden modelarse mediante diagramas ER y los comportamientos mediante diagramas de flujo o diagramas de estructura .
Los modelos comunes utilizados en OOA son los casos de uso y los modelos de objetos . Los casos de uso describen escenarios para funciones de dominio estándar que el sistema debe realizar. Los modelos de objetos describen los nombres, relaciones de clase (por ejemplo, Círculo es una subclase de Forma), operaciones y propiedades de los objetos principales. También se pueden crear maquetas o prototipos de interfaz de usuario para ayudar a comprender. [5]
Durante el diseño orientado a objetos (OOD), un desarrollador aplica restricciones de implementación al modelo conceptual producido en el análisis orientado a objetos. Tales limitaciones podrían incluir las plataformas de hardware y software , los requisitos de rendimiento, el almacenamiento y las transacciones persistentes, la usabilidad del sistema y las limitaciones impuestas por el presupuesto y el tiempo. Los conceptos en el modelo de análisis, que es independiente de la tecnología, se asignan a clases e interfaces de implementación, lo que da como resultado un modelo del dominio de la solución, es decir, una descripción detallada de cómo se construirá el sistema sobre tecnologías concretas. [6]
Los temas importantes durante OOD también incluyen el diseño de arquitecturas de software mediante la aplicación de patrones arquitectónicos y patrones de diseño con los principios de diseño orientado a objetos.
El modelado orientado a objetos (OOM) es un enfoque común para modelar aplicaciones, sistemas y dominios comerciales mediante el uso del paradigma orientado a objetos durante todo el ciclo de vida del desarrollo . OOM es una técnica principal muy utilizada por las actividades OOD y OOA en la ingeniería de software moderna.
El modelado orientado a objetos normalmente se divide en dos aspectos del trabajo: el modelado de comportamientos dinámicos como procesos de negocio y casos de uso , y el modelado de estructuras estáticas como clases y componentes. OOA y OOD son los dos niveles abstractos distintos (es decir, el nivel de análisis y el nivel de diseño) durante OOM. El Lenguaje Unificado de Modelado (UML) y SysML son los dos lenguajes estándar internacionales más populares utilizados para el modelado orientado a objetos. [7]
Los beneficios de OOM son:
Comunicación eficiente y efectiva.
Los usuarios suelen tener dificultades para comprender bien documentos completos y códigos de lenguajes de programación. Los diagramas de modelos visuales pueden ser más comprensibles y permitir a los usuarios y partes interesadas brindar comentarios a los desarrolladores sobre los requisitos y la estructura adecuados del sistema. Un objetivo clave del enfoque orientado a objetos es disminuir la "brecha semántica" entre el sistema y el mundo real, y hacer que el sistema se construya utilizando una terminología que sea casi la misma que la que utilizan las partes interesadas en los negocios cotidianos. El modelado orientado a objetos es una herramienta esencial para facilitar esto.
Abstracción útil y estable.
El modelado ayuda a codificar. Un objetivo de la mayoría de las metodologías de software modernas es abordar primero las preguntas de "qué" y luego abordar las preguntas de "cómo", es decir, primero determinar la funcionalidad que debe proporcionar el sistema sin considerar las restricciones de implementación, y luego considerar cómo crear soluciones específicas a estas cuestiones abstractas. requisitos y refinarlos en diseños y códigos detallados según limitaciones como la tecnología y el presupuesto. El modelado orientado a objetos permite esto al producir descripciones abstractas y accesibles tanto de los requisitos como de los diseños del sistema, es decir, modelos que definen sus estructuras y comportamientos esenciales como procesos y objetos, que son activos de desarrollo importantes y valiosos con niveles de abstracción más altos que el código fuente concreto y complejo. .
