De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

El diseño orientado a objetos es el proceso de planificación de un sistema de objetos que interactúan con el propósito de resolver un problema de software. Es un enfoque para el diseño de software .

Resumen [ editar ]

Un objeto contiene datos y procedimientos encapsulados 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 no se obtienen típicamente instanciando 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 en diseño.

Temas de diseño orientado a objetos [ editar ]

Entrada (fuentes) para diseño orientado a objetos [ editar ]

La entrada para el diseño orientado a objetos es proporcionada por la salida del análisis orientado a objetos . Tenga en cuenta que un artefacto de salida no necesita estar completamente desarrollado para que sirva 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 breve ciclo 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 pueden crecer continuamente 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 : una 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 una función o objetivo comercial específico. Los actores del caso de uso pueden ser usuarios finales u otros sistemas. En muchas circunstancias, los casos de uso se elaboran con más detalle 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 realizan.
  • 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 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 tener esto, pero ayuda a visualizar el producto final y, por lo tanto, ayuda al diseñador.
  • Modelo de datos relacionales (si corresponde): un modelo de datos es un modelo abstracto que describe cómo se representan y se utilizan los datos. Si no se utiliza una base de datos de objetos , el modelo de datos relacionales generalmente debe crearse antes del diseño, ya que la estrategia elegida para el mapeo relacional de objetos es una salida del proceso de diseño OO. Sin embargo, es posible desarrollar el modelo de datos relacionales y los artefactos de diseño orientados a objetos en paralelo, y el crecimiento de un artefacto puede estimular el refinamiento de otros artefactos.

Conceptos orientados a objetos [ editar ]

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

  • Objeto / Clase : Un acoplamiento o asociación estrecho de estructuras de datos con los métodos o funciones que actúan sobre los datos. Esto se llama clase u objeto (un objeto se crea en base a una clase). Cada objeto tiene una función separada. Se define por sus propiedades, qué es y qué puede hacer. Un objeto puede ser parte de una clase, que es un conjunto de objetos que son similares.
  • Ocultación de información : la capacidad de proteger algunos componentes del objeto de entidades externas. Esto se realiza mediante palabras clave de idioma para permitir que una variable se declare como privada o protegida para la clase propietaria .
  • Herencia : la capacidad de una clase para extender o anular la funcionalidad de otra clase . La llamada subclase tiene una sección completa que se deriva (hereda) de la superclase y luego 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 implementarlas.
  • Polimorfismo (específicamente, subtipificación ): la capacidad de reemplazar un objeto con sus subobjetos . La capacidad de una variable de objeto para contener, no solo ese objeto , sino también todos sus subobjetos .

Diseñar conceptos [ editar ]

  • Definición de objetos madres, creación de un diagrama de clases a partir de un diagrama conceptual : por lo general, se asigna una entidad a una clase.
  • Identificación de atributos .
  • 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. [1] 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 orientados a objetos suelen mostrar relaciones e interacciones entre clases u objetos, sin especificar las clases u objetos finales de la aplicación que están involucrados.
  • Definir el marco de la aplicación (si corresponde): el marco de la 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 empaquetar una gran cantidad de código reutilizable en un marco, se ahorra mucho tiempo al desarrollador, ya que se le ahorra la tarea de reescribir grandes cantidades de código estándar para cada nueva aplicación que se desarrolla.
  • Identificar objetos / datos persistentes (si corresponde): Identificar objetos que tienen que durar más que un solo tiempo de ejecución de la aplicación. Si se utiliza una base de datos relacional , diseñe el mapeo de relaciones de objetos.
  • Identificar y definir objetos remotos (si corresponde).

Salida (entregables) del diseño orientado a objetos [ editar ]

  • 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 clases identificados a través del desarrollo de los diagramas de secuencia pueden servir como entrada para la generación automática del diagrama de clases global del sistema.

Algunos principios y estrategias de diseño [ editar ]

  • 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, pasar 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 dependencia 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 . [2] Por ejemplo, el paquete C depende del paquete B, que depende del paquete A. Si el paquete A también dependiera del paquete C, entonces tendría un ciclo.
  • Principio de reutilización compuesta : favorece la composición polimórfica de objetos sobre la herencia. [1]

Ver también [ editar ]

  • Tarjeta de colaboración de clase-responsabilidad
  • GRASP (diseño orientado a objetos)
  • SÓLIDO
  • IDEF4
  • Análisis orientado a objetos
  • Programación orientada a objetos

Referencias [ editar ]

  1. ^ a b Patrones de diseño: elementos de software orientado a objetos reutilizable . Addison-Wesley. 1995. ISBN 0-201-63361-2.
  2. ^ "¿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 .

Enlaces externos [ editar ]

  • Análisis y diseño orientado a objetos : descripción general con UML
  • Larman, Craig. Aplicación de patrones y UML - Tercera edición
  • Análisis y diseño orientado a objetos
  • LePUS3 y Class-Z : lenguajes de modelado formales para diseño orientado a objetos