 | Este artículo necesita citas adicionales para su verificación . ( noviembre de 2019 ) ( Aprenda cómo y cuándo eliminar este mensaje de plantilla ) |
| Desarrollo de software |
|---|
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 modelos visuales en todo el proceso de desarrollo de software para guiar la comunicación con las partes interesadas y la calidad del producto.
La OOAD en la ingeniería de software moderna se lleva a cabo normalmente 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.
Historia [ editar ]
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 competitivas diferentes para el desarrollo de software y el modelado orientado a objetos , a menudo vinculados a proveedores de herramientas de ingeniería de software asistida por computadora (CASE) específicos . La ausencia de notaciones estándar, términos consistentes y guías de proceso fueron las principales preocupaciones en ese momento, lo que degradó la eficiencia de la comunicación y alargó las curvas de aprendizaje.
Algunas de las primeras y conocidas metodologías orientadas a objetos 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 de modelado unificado (UML). Más tarde, junto con Philippe Kruchten y Walker Royce (hijo mayor de Winston Royce ), han liderado una misión exitosa para fusionar sus propias metodologías, el método OMT , OOSE y Booch , con varios conocimientos y experiencias de otros líderes de la industria en el Proceso Unificado Racional. (RUP), una guía y un marco de procesos iterativos e incrementales integrales para aprender las mejores prácticas de la industria de desarrollo de software y gestión de proyectos. [1] Desde entonces, el Proceso Unificado family 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.
Resumen [ editar ]
 | Esta sección puede requerir una limpieza para cumplir con los estándares de calidad de Wikipedia . El problema específico es: elimine las duplicaciones, acorte las descripciones de la cascada y haga las declaraciones más concisas. ( Enero de 2014 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla ) |
El ciclo de vida del software generalmente se divide en etapas que van desde 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 fase de análisis también se denomina a menudo "adquisición de requisitos".
En algunos enfoques para el 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" se acuñó para que tales metodologías significaran que el progreso avanzaba secuencialmente en una sola dirección, es decir, una vez que se completaba el análisis, y solo entonces se iniciaba el diseño y era raro (y se consideraba una fuente de error) cuando 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 modelos iterativos es posible trabajar en varias etapas del modelo en paralelo. Entonces, por ejemplo, es posible —y no se ve como una fuente de error— trabajar en análisis, diseño e incluso codificar todo el mismo día y tener problemas de una etapa que afecten a problemas de otra. El énfasis en los modelos iterativos es que el desarrollo de software es un proceso intensivo en 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 el diseño, que las pruebas pueden producir información sobre cómo 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 la 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 deben usar todos los demás módulos 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 mediante la definición de 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 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 usuarios y expertos en el 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 en 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 adecuada. En el análisis orientado a objetos, esto se suele realizar mediante casos de uso y definiciones abstractas de los objetos más importantes.La siguiente fase de diseño 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]
Análisis orientado a objetos [ editar ]
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 comportamientos (procesos) y 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 casos de uso y 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, 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 interfaz de usuario para ayudar a comprender. [5]
Diseño orientado a objetos [ editar ]
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. Dichas restricciones podrían incluir las plataformas de hardware y software , los requisitos de rendimiento, el almacenamiento y las transacciones persistentes, la facilidad de uso del sistema y las limitaciones impuestas por el presupuesto 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 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 principios de diseño orientados a objetos.
Modelado orientado a objetos [ editar ]
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 todos los ciclos de vida del desarrollo . OOM es una técnica principal muy utilizada por las actividades de OOD y OOA en la ingeniería de software moderna.
El modelado orientado a objetos generalmente se divide en dos aspectos del trabajo: el modelado de comportamientos dinámicos como procesos comerciales 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 más populares utilizados para el modelado orientado a objetos. [7]
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 que los usuarios y las partes interesadas proporcionen 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 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 el sistema debe proporcionar sin tener en cuenta las restricciones de implementación, y luego considerar cómo hacer soluciones específicas para estos resúmenes requisitos y refinarlos en diseños y códigos detallados mediante restricciones como la tecnología y el presupuesto. El modelado orientado a objetos permite esto al producir descripciones abstractas y accesibles de los requisitos y 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 por encima del código fuente concreto y complejo. .
Ver también [ editar ]
- Lenguaje de transformación ATLAS (ATL)
- Tarjeta Class-Responsibility-Collaboration (tarjetas CRC)
- Lenguaje específico de dominio (DSL)
- Diseño impulsado por dominios
- Modelado específico de dominio (DSM)
- Facilidad de metaobjetos (MOF)
- Metamodelado
- Ingeniería basada en modelos (MDE)
- Pruebas basadas en modelos (MBT)
- Lenguaje de modelado de objetos
- Modelado orientado a objetos
- Programación orientada a objetos
- Interfaz de usuario orientada a objetos
- QVT
- Shlaer-Mellor
- Patrón de análisis de software
- Modelado basado en historias
- Lenguaje de modelado unificado (UML)
- Intercambio de metadatos XML (XMI)
Referencias [ editar ]
- ^ "Mejores prácticas de proceso unificado racional para equipos de desarrollo de software" (PDF) . Informe técnico de Rational Software (TP026B). 1998 . Consultado el 12 de diciembre de 2013 .
- ^ Boehm B, "Un modelo en espiral de desarrollo y mejora de software ", Computadora IEEE, IEEE, 21 (5): 61-72, mayo de 1988
- ^ Meyer, Bertrand (1988). Construcción de software orientado a objetos . Cambridge: Prentise Hall International Series en Ciencias de la Computación. pag. 23. ISBN 0-13-629049-3.
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Ingeniería de Software Orientada a Objetos . Addison-Wesley ACM Press. págs. 15, 199 . ISBN 0-201-54435-0.
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Ingeniería de Software Orientada a Objetos . Addison-Wesley ACM Press. págs. 77–79 . ISBN 0-201-54435-0.
- ^ Conallen, Jim (2000). Creación de aplicaciones web con UML . Addison Wesley. pag. 147 . ISBN 0201615770.
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Ingeniería de Software Orientada a Objetos . Addison-Wesley ACM Press. págs. 15, 199 . ISBN 0-201-54435-0.
Lectura adicional [ editar ]
- Grady Booch . "Análisis y diseño orientado a objetos con aplicaciones, tercera 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 realista a la programación y el diseño orientados a objetos. ]
- Una teoría del diseño orientado a objetos : los componentes básicos de OOD 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 patrones y UML - Introducción a OOA / D y desarrollo iterativo . Prentice Hall PTR, 3ª ed. 2005., mnnm, n, nnn
- Setrag Khoshafian. Orientación a objetos .
- Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Modelado basado en historias . Amazon Createspace. pag. 333., 2013. ISBN 9781483949253 .
Enlaces externos [ editar ]
 | Wikiversity 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 descripción general (también sobre tarjetas CRC).
- Aplicación de UML: tutorial de diseño y análisis orientado a objetos
- Sitio web y foros de recursos OOAD y UML - Análisis y diseño orientado a objetos con UML .
- Análisis de requisitos de software mediante el artículo UML de Dhiraj Shetty.
- Artículo Análisis orientado a objetos en el mundo real
