El análisis y diseño orientado a objetos ( OOAD ) es un enfoque técnico para analizar y diseñar una aplicación, un sistema o un negocio mediante la aplicación de la programación orientada a objetos , además de utilizar el modelado visual durante todo el proceso de desarrollo de software para guiar la comunicación con las partes interesadas y la calidad del producto.
En la ingeniería de software moderna, el desarrollo orientado al usuario se lleva a cabo de forma iterativa e incremental. Los resultados de las actividades de desarrollo orientado al usuario son modelos de análisis (para el desarrollo orientado al usuario) y modelos de diseño (para el desarrollo orientado al usuario), respectivamente. La intención es que estos se perfeccionen y evolucionen continuamente, en función de 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 los años 1990, existían muchas metodologías diferentes que competían entre sí 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). La falta de notaciones estándar, términos uniformes y guías de procesos eran las principales preocupaciones en ese momento, 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 surgieron de gurús como Grady Booch , James Rumbaugh , Ivar Jacobson (los Tres Amigos ), Robert Martin , Peter Coad , Sally Shlaer , Stephen Mellor y Rebecca Wirfs-Brock , y fueron inspiradas por ellos.
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 exitosa misión para fusionar sus propias metodologías, OMT , OOSE y el método Booch , con varios conocimientos y experiencias de otros líderes de la industria en el Proceso Unificado Racional (RUP), una guía y marco de trabajo integral de procesos iterativos e incrementales para aprender las mejores prácticas de la industria del desarrollo de software y la gestión de proyectos. [1] Desde entonces, la familia de Procesos Unificados se ha convertido probablemente en la metodología y el modelo de referencia más popular para el análisis y el diseño orientados a objetos.
Un objeto contiene datos encapsulados y procedimientos agrupados para representar una entidad. La "interfaz del objeto" define cómo se puede interactuar con el objeto . Un programa orientado a objetos se describe mediante la interacción de estos objetos. El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema que se identificó y documentó durante el análisis orientado a objetos.
Lo que sigue es una descripción del subconjunto basado en clases del diseño orientado a objetos, que no incluye los enfoques basados en prototipos de objetos , donde los objetos no se obtienen normalmente mediante la instanciación de clases, sino mediante la clonación de otros objetos (prototipos). El diseño orientado a objetos es un método de diseño que abarca el proceso de descomposición orientada a objetos y una notación para representar modelos tanto lógicos y físicos como de estado y dinámicos del sistema en diseño.
El ciclo de vida del software se divide generalmente en etapas, que van desde las descripciones abstractas del problema hasta los diseños, pasando por el código y las pruebas, y finalmente hasta la 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 están pensados para ser bastante rígidos y secuenciales. El término "cascada" se acuñó para estas metodologías con el fin de significar que el progreso se realizaba secuencialmente en una sola dirección, es decir, una vez que se completaba el análisis, entonces y sólo entonces se comenzaba con el diseño y era poco frecuente (y se consideraba una fuente de error) que un problema de diseño requiriera un cambio en el modelo de análisis o cuando un problema de codificación requiriera 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 espiral para el desarrollo iterativo de software. Con los modelos iterativos es posible trabajar en varias etapas del modelo en paralelo. Por ejemplo, es posible (y no se considera 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 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 se pueden entender completamente sin comprender los problemas de diseño, que los problemas de codificación pueden afectar al diseño, que las pruebas pueden brindar información sobre cómo se debe modificar el código o incluso el diseño, 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" suelen considerarse 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 es abierto si admite extensiones o si proporciona formas estandarizadas de agregar nuevos comportamientos o describir nuevos estados. En el paradigma orientado a objetos, esto se logra a menudo creando una nueva subclase de una clase existente. Un módulo es 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 errores potenciales 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 los 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 informática. [3]
El ciclo de vida del software se divide generalmente en etapas que van desde las descripciones abstractas del problema hasta los diseños, luego el código y las pruebas y, finalmente, la 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 se describe a menudo como "qué versus cómo". En el análisis, los desarrolladores trabajan con los usuarios y los expertos del dominio para definir lo que se supone que debe hacer el sistema. Se supone que los detalles de implementación se ignoran en su mayor parte o totalmente (según el método particular) en esta fase. El objetivo de la fase de análisis es crear un modelo funcional del sistema independientemente de las limitaciones, como la tecnología apropiada. En el análisis orientado a objetos, esto se hace típicamente a través de 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 las decisiones tecnológicas necesarias 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 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 llevar a cabo. Los modelos de objetos describen los nombres, las relaciones de clase (por ejemplo, Circle es una subclase de Shape), las operaciones y las propiedades de los objetos principales. También se pueden crear maquetas o prototipos de la interfaz de usuario para ayudar a la comprensión. [5]
El diseño orientado a objetos (OOD) es el proceso de planificación de un sistema de objetos que interactúan para resolver un problema de software. Es un método para el diseño de software . Al definir clases y su funcionalidad para sus hijos (objetos instanciados), cada objeto puede ejecutar la misma implementación de la clase con su estado.
Durante el desarrollo orientado a objetos, un desarrollador aplica restricciones de implementación al modelo conceptual producido en el análisis orientado a objetos. Dichas restricciones pueden 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 los presupuestos y el tiempo. Los conceptos del 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 debe 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.
La entrada para el diseño orientado a objetos la proporciona la salida del análisis orientado a objetos. Tenga en cuenta que un artefacto de salida no necesita estar completamente desarrollado para servir como entrada del diseño orientado a objetos; el análisis y el diseño pueden ocurrir en paralelo y, en la práctica, los resultados de una actividad pueden alimentar a la otra en un ciclo de retroalimentación corto a través de un proceso iterativo. Tanto el análisis como el diseño se pueden realizar de forma incremental y los artefactos se pueden desarrollar de forma continua en lugar de desarrollarse completamente de una sola vez.
Algunos artefactos de entrada típicos para el diseño orientado a objetos son:
Los cinco conceptos básicos del diseño orientado a objetos son las características de nivel de implementación incorporadas en el lenguaje de programación. Estas características suelen denominarse con estos nombres comunes:
La principal ventaja de utilizar un patrón de diseño es que se puede reutilizar en múltiples aplicaciones. También se puede considerar como una plantilla para resolver un problema que se puede utilizar en muchas situaciones o aplicaciones diferentes. Los patrones de diseño orientados a objetos suelen mostrar relaciones e interacciones entre clases u objetos, sin especificar las clases u objetos de la aplicación final involucrados.
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 a lo largo de todo el ciclo de vida del desarrollo . OOM es una técnica principal muy utilizada tanto por las actividades OOD como OOA en la ingeniería de software moderna.
El modelado orientado a objetos se divide típicamente en dos aspectos de trabajo: el modelado de comportamientos dinámicos como procesos de negocios 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 de Modelado Unificado (UML) y SysML son los dos lenguajes estándar internacionales populares utilizados para el modelado orientado a objetos. [9]
Los beneficios de OOM son:
Comunicación eficiente y eficaz
Los usuarios suelen tener dificultades para comprender bien los documentos completos y los códigos de los lenguajes de programación. Los diagramas de modelos visuales pueden ser más comprensibles y pueden permitir a los usuarios y a las partes interesadas dar retroalimentación a los desarrolladores sobre los requisitos y la estructura adecuados del sistema. Un objetivo clave del enfoque orientado a objetos es reducir la "brecha semántica" entre el sistema y el mundo real, y lograr que el sistema se construya utilizando una terminología que sea casi la misma 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 la codificación. Un objetivo de la mayoría de las metodologías de software modernas es abordar primero las preguntas "qué" y luego las preguntas "cómo", es decir, primero determinar la funcionalidad que el sistema debe proporcionar sin tener en cuenta las limitaciones de implementación y luego considerar cómo crear soluciones específicas para estos requisitos abstractos y refinarlas en diseños y códigos detallados según las 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 del sistema como de los diseños, 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.
