Hispanopedia WikiEl análisis y diseño orientado a objetos ( OOAD ) es un enfoque para analizar y diseñar sistemas informáticos mediante la aplicación de una mentalidad orientada a objetos y el uso de modelos visuales a lo largo del proceso de desarrollo de software . Consta de análisis orientado a objetos (OOA) y diseño orientado a objetos (OOD) , cada uno de los cuales genera un modelo del sistema mediante modelado orientado a objetos (OOM). Sus defensores sostienen que los modelos deben refinarse y evolucionar continuamente, en un proceso iterativo, impulsado por factores clave como el riesgo y el valor para el negocio.
OOAD es un método de análisis y diseño que aprovecha los principios de descomposición y notaciones de la programación orientada a objetos para representar modelos lógicos, físicos, basados en estados y dinámicos de un sistema. Como parte del ciclo de vida del desarrollo de software , OOAD se relaciona con dos etapas iniciales: a menudo denominadas análisis de requisitos y diseño. [ 1 ]
Aunque el OOAD podría emplearse en una metodología en cascada donde las etapas del ciclo de vida son secuenciales con límites rígidos entre ellas, el OOAD a menudo implica enfoques más iterativos. Las metodologías iterativas se idearon para agregar flexibilidad al proceso de desarrollo. En lugar de trabajar en cada etapa del ciclo de vida a la vez, con un enfoque iterativo, el trabajo puede avanzar en el análisis, el diseño y la codificación al mismo tiempo. Y a diferencia de una mentalidad en cascada que un cambio a una etapa anterior del ciclo de vida es un fracaso, un enfoque iterativo admite que tales cambios son normales en el curso de un proceso intensivo en conocimiento : que cosas como el análisis realmente no pueden realmente no pueden realmente comprenderse completamente sin comprender los problemas de diseño, que los problemas de codificación pueden afectar el diseño, que las pruebas pueden proporcionar información sobre cómo se debe modificar el código o incluso el diseño, etc. [ 2 ] Aunque es posible hacer desarrollo orientado a objetos en una metodología en cascada, la mayoría del OOAD sigue un enfoque iterativo.
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 métodos estandarizados para 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 y 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 los objetos. Los métodos pueden ser públicos o privados; es decir, ciertos comportamientos que son únicos para el objeto no se exponen a otros objetos. Esto reduce una fuente de muchos errores comunes en la programación informática. [ 3 ]
Análisis orientado a objetos
Los modelos comunes utilizados en OOA son el caso de uso y el modelo de objeto . Un caso de uso describe un escenario para las funciones estándar del dominio que el sistema debe realizar. Un modelo de objeto describe los nombres, las relaciones de clase, las operaciones y las propiedades de los objetos principales. También se pueden crear maquetas o prototipos de la interfaz de usuario para facilitar la comprensión. [ 4 ]
A diferencia del análisis orientado a objetos (OOA), que organiza los requisitos en torno a objetos que integran procesos y datos, en otros métodos de análisis, los procesos y los datos se consideran por separado. Por ejemplo, los datos pueden modelarse mediante diagramas de entidad-relación y los comportamientos mediante diagramas de flujo o diagramas de estructura .
Artefactos
Los resultados de OOA son entradas para OOD. En un enfoque iterativo, un artefacto de salida no necesita estar completamente desarrollado para servir como entrada para OOD. Tanto OOA como OOD pueden realizarse de forma incremental, y los artefactos pueden crecer continuamente en lugar de desarrollarse por completo de una sola vez. Los artefactos de OOA incluyen:
- Modelo conceptual
- Un modelo conceptual captura los conceptos del 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
- Un caso de uso describe una secuencia de eventos que llevan a un sistema a realizar una acción útil. Cada caso de uso presenta uno o más escenarios que describen cómo el sistema debe interactuar con los usuarios, denominados actores, para lograr un objetivo o función empresarial específica. Los actores de un caso de uso pueden ser usuarios finales u otros sistemas. En muchos casos, los casos de uso se detallan en diagramas de casos de uso . Estos diagramas se utilizan para identificar a los actores (usuarios u otros sistemas) y los procesos que realizan.
- Diagrama de secuencia del sistema
- Un diagrama de secuencia del sistema (SSD, por sus siglas en inglés) es una representación gráfica que muestra, para un escenario particular de un caso de uso, los eventos que generan los agentes externos, su orden y los posibles eventos entre sistemas.
- Documentación de la interfaz de usuario
- Documentación opcional que muestra y describe el aspecto y la sensación de la interfaz de usuario .
- Modelo de datos relacional
- Si no se utiliza una base de datos orientada a objetos , generalmente se debe crear un modelo de datos relacional antes del diseño, ya que la estrategia elegida para el mapeo objeto-relacional 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 desarrollo de un artefacto puede impulsar el perfeccionamiento de otros.
Diseño orientado a objetos
El diseño orientado a objetos (OOD), una forma de diseño de software , es el proceso de planificar un sistema de objetos que interactúan para resolver un problema de software. Un diseñador aplica restricciones de implementación al modelo conceptual producido en el análisis orientado a objetos (OOA). Dichas restricciones pueden incluir las plataformas de hardware y software , los requisitos de rendimiento, el almacenamiento persistente y las transacciones, la usabilidad del sistema y las limitaciones impuestas por los presupuestos 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. [ 5 ]
Las actividades de OOD incluyen:
- Definición de objetos y sus atributos
- Creación de diagramas de clases a partir de modelos conceptuales
- Utilizando patrones de diseño [ 6 ]
- Definición de marcos de aplicación
- Identificación de objetos/datos persistentes
- Diseño del mapeo objeto-relación si se utiliza una base de datos relacional.
- Identificación de objetos remotos
Los principios y estrategias de OOD incluyen:
- Inyección de dependencias
- La inyección de dependencias significa que si un objeto depende de tener una instancia de otro objeto, entonces el objeto necesario se "inyecta" en el objeto dependiente (por ejemplo, se le pasa una conexión a la base de datos como argumento al constructor en lugar de crearla internamente).
- principio de dependencias acíclicas
- El principio de dependencias acíclicas establece que el grafo de dependencias de paquetes o componentes (cuya granularidad depende del alcance del trabajo de cada desarrollador) no debe contener ciclos. Esto también se conoce como tener un grafo acíclico dirigido . [ 7 ] Por ejemplo, el paquete C depende del paquete B, que a su vez depende del paquete A. Si el paquete A dependiera del paquete C, existiría un ciclo.
- Principio de reutilización de materiales compuestos
- El principio de reutilización compuesta consiste en favorecer la composición polimórfica de objetos sobre la herencia. [ 6 ]
Artefactos
- Diagrama de secuencia
- Amplíe el diagrama de secuencia para agregar objetos específicos que gestionen los eventos del sistema. Un diagrama de secuencia muestra, mediante líneas verticales paralelas, diferentes procesos u objetos que coexisten, y, mediante flechas horizontales, los mensajes que se intercambian 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 sus clases, sus atributos y las relaciones entre ellas. 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.
Véase también
- Lenguaje de transformación ATLAS
- Tarjeta de colaboración y responsabilidad de clase
- lenguaje específico de dominio
- Diseño orientado al dominio
- Modelado específico del dominio
- GRASP (diseño orientado a objetos)
- IDEF4
- Instalación de metaobjetos
- Metamodelado
- Ingeniería basada en modelos
- Pruebas basadas en modelos
- Modelado orientado a objetos
- Interfaz de usuario orientada a objetos
- QVT
- Método de Shlaer-Mellor
- Patrón de análisis de software
- SÓLIDO
- Modelado basado en historias
- Proceso unificado
Referencias
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Ingeniería de Software Orientada a Objetos . Prensa Addison-Wesley ACM. págs.15 , 199 . ISBN 0-201-54435-0.
- ↑ Boehm B, "Un modelo espiral de desarrollo y mejora de software. Archivado el 28 de mayo de 2015 en Wayback Machine ", IEEE Computer, IEEE, 21(5):61-72, mayo de 1988.
- ↑ Meyer, Bertrand (1988). Construcción de software orientado a objetos . Cambridge: Prentice Hall International Series in Computer Science. pág. 23. ISBN 0-13-629049-3.
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Ingeniería de Software Orientada a Objetos . Prensa Addison-Wesley ACM. págs. 77–79 . ISBN 0-201-54435-0.
- ↑ Conallen, Jim (2000). Creación de aplicaciones web con UML . Addison Wesley. pág . 147. ISBN 0201615770.
- 1 2 Erich Gamma ; Richard Helm ; Ralph Johnson ; John Vlissides (2 de enero de 1995). Patrones de diseño: Elementos de software orientado a objetos reutilizable . Addison-Wesley . ISBN 978-0-201-63361-0.
- ↑ "¿Qué es el diseño orientado a objetos?" . Object Mentor. Archivado del original el 30-06-2007 . Consultado el 03-07-2007 .
Lecturas adicionales
- 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 al diseño orientado a objetos y al desarrollo iterativo . Prentice Hall PTR, 3.ª ed., 2005.
- Setrag Khoshafian. Orientación a objetos .
- Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Story Driven Modeling . Amazon Createspace. pág. 333, 2013. ISBN 9781483949253.
Enlaces externos
- 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: Análisis y diseño orientado a objetos. Archivado el 15/09/2009 en el tutorial de Wayback Machine .
- Sitio web y foros de recursos sobre OOAD y UML: Análisis y diseño orientado a objetos con UML.
- Análisis de requisitos de software mediante UML, artículo de Dhiraj Shetty
- Artículo : Análisis orientado a objetos en el mundo real.
- Análisis y diseño orientado a objetos. Archivado el 15 de septiembre de 2009 en Wayback Machine : descripción general mediante UML.
- Larman, Craig. Aplicación de UML y patrones – Tercera edición. Archivado el 25/10/2016 en Wayback Machine.
- Análisis y diseño orientado a objetos
- LePUS3 y Class-Z : lenguajes de modelado formal para el diseño orientado a objetos
- La jerarquía de objetos
- Programación orientada a objetos
- Diseño de software
