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 ]
Although OOAD could be employed in a waterfall methodology where the life cycle stages as sequential with rigid boundaries between them, OOAD often involves more iterative approaches. Iterative methodologies were devised to add flexibility to the development process. Instead of working on each life cycle stage at a time, with an iterative approach, work can progress on analysis, design and coding at the same time. And unlike a waterfall mentality that a change to an earlier life cycle stage is a failure, an iterative approach admits that such changes are normal in the course of a knowledge-intensive process – that things like analysis can't really be completely understood without understanding design issues, that coding issues can affect design, that testing can yield information about how the code or even the design should be modified, etc.[2] Although it is possible to do object-oriented development in a waterfall methodology, most OOAD follows an iterative approach.
The object-oriented paradigm emphasizes modularity and re-usability. The goal of an object-oriented approach is to satisfy the "open–closed principle". A module is open if it supports extension, or if the module provides standardized ways to add new behaviors or describe new states. In the object-oriented paradigm this is often accomplished by creating a new subclass of an existing class. A module is closed if it has a well defined stable interface that all other modules must use and that limits the interaction and potential errors that can be introduced into one module by changes in another. In the object-oriented paradigm this is accomplished by defining methods that invoke services on objects. Methods can be either public or private, i.e., certain behaviors that are unique to the object are not exposed to other objects. This reduces a source of many common errors in computer programming.[3]
Object-oriented analysis
Common models used in OOA are the use case and the object model. A use case describes a scenario for standard domain functions that the system must accomplish. An object model describes the names, class relations, operations, and properties of the main objects. User-interface mockups or prototypes can also be created to help understanding.[4]
Unlike with OOA that organizes requirements around objects that integrate processes and data, with other analysis methods, processes and data are considered separately. For example, data may be modeled by entity–relationship diagrams, and behaviors by flowcharts or structure charts.
Artifacts
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). Building Web Applications with UML . Addison Wesley. p. 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
