stringtranslate.com

Análisis y diseño orientado a objetos.

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 modelado visual durante todo el proceso de desarrollo de software para guiar la comunicación de las partes interesadas y la calidad del producto.

OOAD en la ingeniería de software moderna generalmente se lleva a cabo 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

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 diferentes en competencia 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). Las principales preocupaciones en ese momento eran no notaciones estándar, términos consistentes y guías de procesos, 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 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 Unificado de Modelado (UML). Más tarde, junto con Philippe Kruchten y Walker Royce (hijo mayor de Winston Royce ), lideraron una misión exitosa para fusionar sus propias metodologías, OMT , OOSE y el método Booch , con diversos conocimientos y experiencias de otros líderes de la industria en el Proceso Unificado Racional. (RUP), una guía y un marco de procesos integrales, iterativos e incrementales, para aprender las mejores prácticas de la industria en materia de desarrollo de software y gestión de proyectos. [1] Desde entonces, la familia de Procesos Unificados se ha convertido probablemente en la metodología y modelo de referencia más popular para el análisis y diseño orientado a objetos.

Descripción general

Un objeto contiene datos encapsulados y procedimientos agrupados para representar una entidad. La 'interfaz de 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 de definir los objetos y sus interacciones para resolver un problema que fue identificado y documentado 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 enfoques basados ​​en prototipos de objetos donde los objetos normalmente no se obtienen creando instancias de clases sino clonando 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 bajo diseño.

El ciclo de vida del software generalmente se divide en etapas, que van desde descripciones abstractas del problema hasta diseños, luego código y pruebas y, finalmente, 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".

El modelo de cascada .
OOAD se lleva a cabo de manera iterativa e incremental, según lo formulado por el Proceso Unificado .

En algunos enfoques del 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" fue acuñado para que tales metodologías significaran que el progreso iba secuencialmente en una sola dirección, es decir, una vez que se completaba el análisis, entonces y sólo entonces se comenzaba el diseño y era raro (y se consideraba una fuente de error) que 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 los modelos iterativos es posible trabajar en varias etapas del modelo en paralelo. Así, por ejemplo, es posible (y no verse como 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 problemas 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 pueden entenderse completamente sin comprender los problemas de diseño, que los problemas de codificación pueden afectar el diseño, que las pruebas pueden arrojar información sobre cómo funciona 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 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 suele lograrse creando una nueva subclase de una clase existente. Un módulo está 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 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 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 diseños, luego código y pruebas y finalmente 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 a menudo se describe como "qué versus cómo". En el análisis, los desarrolladores trabajan con usuarios y expertos en el dominio para definir qué se supone que debe hacer el sistema. Se supone que los detalles de implementación se ignoran total o parcialmente (dependiendo del método particular) en esta fase. El objetivo de la fase de análisis es crear un modelo funcional del sistema independientemente de limitaciones como la tecnología apropiada. En el análisis orientado a objetos, esto normalmente se hace mediante 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 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

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 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 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 realizar. Los modelos de objetos describen los nombres, relaciones de clase (por ejemplo, Círculo es una subclase de Forma), operaciones y 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

El diseño orientado a objetos (OOD) es el proceso de planificar 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 OOD, un desarrollador aplica restricciones de implementación al modelo conceptual producido en el análisis orientado a objetos. Dichas limitaciones podrían 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 el presupuesto 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. [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.

Entradas (fuentes) para diseño orientado a objetos

El insumo para el diseño orientado a objetos lo proporciona el resultado del análisis orientado a objetos. Tenga en cuenta que no es necesario desarrollar completamente un artefacto de salida para que sirva como entrada de un 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 corto de retroalimentación 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 continuamente en lugar de desarrollarse completamente de una sola vez.

Algunos artefactos de entrada típicos para el diseño orientado a objetos son:

Conceptos orientados a objetos

Los cinco conceptos básicos del diseño orientado a objetos son las características a nivel de implementación integradas en el lenguaje de programación. A menudo se hace referencia a estas características con estos nombres comunes:

Conceptos de diseño

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 sobre cómo resolver un problema que se puede utilizar en muchas situaciones y/o aplicaciones diferentes. Los patrones de diseño orientado a objetos suelen mostrar relaciones e interacciones entre clases u objetos, sin especificar las clases u objetos de aplicación finales involucrados.

Salida (entregables) del diseño orientado a objetos

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

Algunos principios y estrategias de diseño.

Modelado orientado a objetos

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 durante todo el ciclo de vida del desarrollo . OOM es una técnica principal muy utilizada por las actividades OOD y OOA en la ingeniería de software moderna.

El modelado orientado a objetos normalmente se divide en dos aspectos del trabajo: el modelado de comportamientos dinámicos como procesos de negocio 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 Unificado de Modelado (UML) y SysML son los dos lenguajes estándar internacionales más populares utilizados para el modelado orientado a objetos. [9]

Los beneficios de OOM son:

Comunicación eficiente y efectiva.

Los usuarios suelen tener dificultades para comprender bien documentos completos y códigos de lenguajes de programación. Los diagramas de modelos visuales pueden ser más comprensibles y permitir a los usuarios y partes interesadas brindar 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 la 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 debe proporcionar el sistema sin considerar las restricciones de implementación, y luego considerar cómo crear soluciones específicas a estas cuestiones abstractas. requisitos y refinarlos en diseños y códigos detallados según 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 como de los 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 que el código fuente concreto y complejo. .

Ver también

Referencias

  1. ^ "Mejores prácticas de procesos unificados racionales para equipos de desarrollo de software" (PDF) . Documento técnico de Rational Software (TP026B). 1998 . Consultado el 12 de diciembre de 2013 .
  2. ^ Boehm B, "Un modelo en espiral de desarrollo y mejora de software", IEEE Computer, IEEE, 21(5):61-72, mayo de 1988
  3. ^ Meyer, Bertrand (1988). Construcción de software orientado a objetos . Cambridge: Serie Internacional Prentise Hall sobre Ciencias de la Computación. pag. 23.ISBN 0-13-629049-3.
  4. ^ 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.
  5. ^ 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.
  6. ^ Conallen, Jim (2000). Creación de aplicaciones web con UML. Addison Wesley. pag. 147.ISBN 0201615770.
  7. ^ ab Erich Gamma ; Richard Helm ; Ralph Johnson ; John Vlissides (2 de enero de 1995). Patrones de diseño: elementos de software reutilizable orientado a objetos. Addison-Wesley . ISBN 978-0-201-63361-0.
  8. ^ "¿Qué es el diseño orientado a objetos?". Mentor de objetos. Archivado desde el original el 30 de junio de 2007 . Consultado el 3 de julio de 2007 .
  9. ^ 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.

Otras lecturas

enlaces externos