Análisis y diseño orientado a objetos

Este artículo necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Análisis y diseño orientado a objetos» – noticias  · periódicos  · libros  · académico  · JSTOR ( noviembre de 2019 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Partes de este artículo (las relacionadas con el artículo) necesitan ser actualizadas . Por favor, ayude a actualizar este artículo para reflejar eventos recientes o nueva información disponible. ( Julio de 2023 )

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.

This section may require cleanup to meet Wikipedia's quality standards. The specific problem is: remove duplications, shorten the waterfall descriptions, and make the statements more concise. Please help improve this section if you can. (January 2014) (Learn how and when to remove this message)

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:

• Modelo conceptual : el resultado del análisis orientado a objetos captura conceptos en el dominio del problema . El modelo conceptual se elige explícitamente para que sea independiente de los detalles de implementación, como la concurrencia o el almacenamiento de datos.
• Caso de uso : descripción de secuencias de eventos que, en conjunto, llevan a que un sistema haga algo útil. Cada caso de uso proporciona uno o más escenarios que transmiten cómo el sistema debe interactuar con los usuarios llamados actores para lograr un objetivo o función empresarial específica. Los actores del caso de uso pueden ser usuarios finales u otros sistemas. En muchas circunstancias, los casos de uso se elaboran más en diagramas de casos de uso . Los diagramas de casos de uso se utilizan para identificar al actor (usuarios u otros sistemas) y los procesos que realiza.
• Diagrama de secuencia del sistema : Un diagrama de secuencia del sistema (SSD) es una imagen que muestra, para un escenario particular de un caso de uso, los eventos que generan los actores externos, su orden y los posibles eventos entre sistemas.
• Documentación de la interfaz de usuario (si corresponde): documento que muestra y describe la apariencia de la interfaz de usuario del producto final. No es obligatorio tenerlo, pero ayuda a visualizar el producto final y, por lo tanto, ayuda al diseñador.
• Modelo de datos relacional (si corresponde): un modelo de datos es un modelo abstracto que describe cómo se representan y utilizan los datos. Si no se utiliza una base de datos de objetos , el modelo de datos relacional normalmente se debe crear antes del diseño, ya que la estrategia elegida para el mapeo relacional de objetos es un resultado del proceso de diseño orientado a objetos. Sin embargo, es posible desarrollar el modelo de datos relacional y los artefactos de diseño orientado a objetos en paralelo, y el crecimiento de un artefacto puede estimular el refinamiento de otros artefactos.

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:

• Objeto/Clase : Un acoplamiento o asociación estrecha de estructuras de datos con los métodos o funciones que actúan sobre los datos. Esto se denomina clase u objeto (un objeto se crea en función de una clase). Cada objeto cumple una función independiente. Se define por sus propiedades, lo que es y lo que puede hacer. Un objeto puede ser parte de una clase, que es un conjunto de objetos similares.
• Ocultación de información : la capacidad de proteger algunos componentes de un objeto de entidades externas. Esto se logra mediante palabras clave del lenguaje que permiten declarar una variable como privada o protegida para la clase propietaria .
• Herencia : La capacidad de una clase de extender o anular la funcionalidad de otra clase . La denominada subclase tiene una sección completa derivada (heredada) de la superclase y tiene su propio conjunto de funciones y datos.
• Interfaz (programación orientada a objetos) : La capacidad de diferir la implementación de un método . La capacidad de definir las firmas de funciones o métodos sin implementarlos.
• Polimorfismo (específicamente, subtipificación ): la capacidad de reemplazar un objeto con sus subobjetos . La capacidad de una variable de objeto de contener no solo ese objeto sino también todos sus subobjetos .

• Definición de objetos, creación de diagramas de clases a partir de diagramas conceptuales : generalmente, asignamos entidades a clases.
• Identificar atributos y sus modelos.
• Utilice patrones de diseño (si corresponde): un patrón de diseño no es un diseño terminado, es una descripción de una solución a un problema común, en un contexto. ^[7]

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.

• Definir el marco de aplicación (si corresponde): un marco de aplicación suele ser un conjunto de bibliotecas o clases que se utilizan para implementar la estructura estándar de una aplicación para un sistema operativo específico. Al agrupar una gran cantidad de código reutilizable en un marco, el desarrollador ahorra mucho tiempo, ya que no tiene que reescribir grandes cantidades de código estándar para cada nueva aplicación que desarrolle.
• Identificar objetos/datos persistentes (si corresponde): identificar objetos que deben durar más que un único tiempo de ejecución de la aplicación. Diseñar la asignación de relaciones entre objetos si se utiliza una base de datos relacional .
• Identificar y definir objetos remotos (si corresponde) y sus variaciones.

• Diagrama de secuencia : amplíe el diagrama de secuencia del sistema para agregar objetos específicos que manejen los eventos del sistema.

Un diagrama de secuencia muestra, como líneas verticales paralelas, diferentes procesos u objetos que viven simultáneamente y, como flechas horizontales, los mensajes intercambiados entre ellos, en el orden en que ocurren.

• Diagrama de clases : un diagrama de clases es un tipo de diagrama UML de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos y las relaciones entre las clases. Los mensajes y las clases identificados mediante el desarrollo de los diagramas de secuencia pueden servir como entrada para la generación automática del diagrama de clases global del sistema.

• Inyección de dependencia : la idea básica es que si un objeto depende de tener una instancia de algún otro objeto, entonces el objeto necesario se "inyecta" en el objeto dependiente; por ejemplo, se pasa una conexión de base de datos como argumento al constructor en lugar de crear una internamente.
• Principio de dependencias acíclicas : el gráfico de dependencias de paquetes o componentes (la granularidad depende del alcance del trabajo de un desarrollador) no debe tener ciclos. Esto también se conoce como tener un gráfico acíclico dirigido . ^[8] Por ejemplo, el paquete C depende del paquete B, que depende del paquete A. Si el paquete A dependiera del paquete C, tendría un ciclo.
• Principio de reutilización compuesta : favorecer la composición polimórfica de objetos sobre la herencia. ^[7]

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 permitir que los usuarios y las partes interesadas brinden comentarios 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.

• Grady Booch . "Análisis y diseño orientado a objetos con aplicaciones, 3.ª edición": http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
• Rebecca Wirfs-Brock , Brian Wilkerson, Lauren Wiener. Diseño de software orientado a objetos . Prentice Hall, 1990. [ Una introducción práctica a la programación y el diseño orientados a objetos ] .
• Una teoría del diseño orientado a objetos: los componentes básicos del diseño orientado a objetos y las notaciones para representarlos (con especial atención a los patrones de diseño).
• Martin Fowler . Patrones de análisis: modelos de objetos reutilizables . Addison-Wesley, 1997. [ Una introducción al análisis orientado a objetos con modelos conceptuales ]
• Bertrand Meyer . Construcción de software orientado a objetos . Prentice Hall, 1997
• Craig Larman . Aplicación de UML y patrones: introducción a OOA/D y desarrollo iterativo . Prentice Hall PTR, 3.ª ed., 2005.
• Setrag Khoshafian. Orientación a objetos .
• Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Modelado basado en historias . Amazon Createspace. pág. 333., 2013. ISBN 9781483949253 . 

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

• Artículo Análisis y diseño orientado a objetos con UML y RUP: una visión general (también sobre tarjetas CRC).
• Aplicación de UML: tutorial de análisis y diseño orientado a objetos
• Sitio web y foros de recursos OOAD y UML: análisis y diseño orientado a objetos con UML.
• Artículo sobre análisis de requisitos de software mediante UML de Dhiraj Shetty.
• Artículo Análisis orientado a objetos en el mundo real
• Análisis y diseño orientado a objetos: descripción general mediante UML
• Larman, Craig. Aplicación de UML y patrones - Tercera edición
• Análisis y diseño orientado a objetos
• LePUS3 y Class-Z: lenguajes de modelado formal para diseño orientado a objetos