¿Cuál es la idea OO en Java?
La orientación a objetos (OO) es un tema candente en la industria informática actual y en la corriente principal de los métodos de desarrollo de software en la década de 1990. Los conceptos y aplicaciones orientados a objetos han trascendido el alcance de la programación y el desarrollo de software y se han expandido a una amplia gama de campos. Como sistemas de bases de datos, interfaces interactivas, estructuras de aplicaciones, plataformas de aplicaciones, sistemas distribuidos, estructuras de gestión de redes, tecnología CAD, inteligencia artificial y otros campos.
Cuando se trata de orientación a objetos, hay muchos artículos en esta área. Sin embargo, hay muy pocas definiciones de objetos claramente dadas o explicadas; al menos yo no las he encontrado todavía. Originalmente, "orientado a objetos" se refería a métodos de diseño como la encapsulación, la herencia y la abstracción utilizados en la programación. Sin embargo, es evidente que esta definición ya no es adecuada a la situación actual. El pensamiento orientado a objetos ha estado involucrado en todos los aspectos del desarrollo de software. Por ejemplo, a menudo hablamos de OOA (análisis orientado a objetos), OOD (diseño orientado a objetos) y OOP (programación orientada a objetos). Muchos artículos sobre el desarrollo orientado a objetos tratan simplemente sobre cuestiones que se deben tener en cuenta o sobre mejores métodos de diseño que se pueden adoptar en el desarrollo orientado a objetos. Solo leyendo estos artículos podrá comprender realmente qué son los objetos y qué es la orientación a objetos, y podrá beneficiarse al máximo. Me temo que para los principiantes o incluso para las personas que han trabajado en trabajos relacionados durante muchos años, el concepto será relativamente vago.
La orientación a objetos es el foco de la industria informática actual y la corriente principal de los métodos de desarrollo de software en la década de 1990. Los conceptos y aplicaciones orientados a objetos han trascendido el alcance de la programación y el desarrollo de software y se han expandido a una amplia gama de campos. Como sistemas de bases de datos, interfaces interactivas, estructuras de aplicaciones, plataformas de aplicaciones, sistemas distribuidos, estructuras de gestión de redes, tecnología CAD, inteligencia artificial y otros campos.
Primero, problemas con los métodos de desarrollo tradicionales
1. Mala reutilización del software
Reusabilidad significa que no es necesario modificar o modificar ligeramente lo mismo. se puede reutilizar varias veces. La reutilización del software es uno de los objetivos que persigue la ingeniería de software.
2. Mala mantenibilidad del software
La ingeniería de software enfatiza la mantenibilidad del software y la importancia de la documentación, y estipula que el producto de software final debe estar compuesto por componentes de configuración completos y consistentes. En el proceso de desarrollo de software, siempre se enfatiza que la legibilidad, modificabilidad y capacidad de prueba del software son indicadores de calidad importantes del software. La práctica ha demostrado que el costo y el gasto del software desarrollado por métodos tradicionales siguen siendo altos, lo que se debe a la escasa modificabilidad y dificultad de mantenimiento, lo que resulta en una mala mantenibilidad.
3. El software desarrollado no puede satisfacer las necesidades de los usuarios.
Desarrollar sistemas de software a gran escala utilizando métodos estructurados tradicionales implica conocimientos en diversos campos. Cuando se desarrollan sistemas con requisitos difusos o dinámicos, los sistemas de software desarrollados a menudo no pueden satisfacer realmente las necesidades de los usuarios.
La estabilidad, modificabilidad y reutilización del software desarrollado mediante métodos estructurados son deficientes porque la esencia de los métodos estructurados es la descomposición funcional. A partir de un proceso único que representa la función general del sistema objetivo, el proceso complejo se descompone continuamente en subprocesos de arriba a abajo, capa por capa hasta que solo quedan unos pocos subprocesos, y luego se utilizan las herramientas correspondientes para describir el proceso de nivel más bajo. Por lo tanto, los enfoques estructurados construyen sistemas en torno a los "procesos" que implementan funciones de procesamiento. Sin embargo, la mayoría de los cambios en los requisitos del usuario son funcionales, por lo que dichos cambios pueden ser desastrosos para el diseño basado en procesos. La estructura del sistema diseñada mediante este método suele ser inestable y los cambios en las necesidades del usuario a menudo provocan grandes cambios en la estructura del sistema, por lo que se requiere una gran cantidad de dinero para implementar dichos cambios.
2. Conceptos básicos de la orientación a objetos
(1) Objeto.
Un objeto es cualquier cosa que uno quiera estudiar, desde los números enteros más simples hasta aviones complejos. Puede representar no sólo cosas concretas, sino también reglas, planes o eventos abstractos.
(2) El estado y comportamiento del objeto.
Los objetos tienen estado y los objetos utilizan valores de datos para describir su estado.
Los objetos también tienen operaciones que cambian el estado del objeto. El objeto y sus operaciones son el comportamiento del objeto.
Los objetos realizan la combinación de datos y operaciones, de modo que los datos y las operaciones quedan encapsulados en la unidad de los objetos.
(3) Clase.
Una abstracción de objetos con propiedades iguales o similares es una clase. Entonces la abstracción de un objeto es una clase y la concretización de una clase es un objeto. También se puede decir que una instancia de una clase es un objeto.
Las clases tienen atributos, que son abstracciones de los estados de los objetos. Las estructuras de datos se utilizan para describir las propiedades de una clase.
Una clase tiene una operación, que es una abstracción del comportamiento del objeto y se describe mediante el nombre de la operación y el método para implementar la operación.
(4) Estructura de clases.
El mundo objetivo tiene varias categorías, y existen ciertas relaciones estructurales entre estas categorías. Generalmente existen dos relaciones estructurales principales, a saber, relaciones estructurales generales específicas y relaciones estructurales de parte completa.
①La estructura específica general se denomina estructura de clasificación, y también se puede decir que es una relación "o" o una relación "es".
②La estructura de partes enteras se llama estructura de ensamblaje, y la relación entre ellas es la relación y o a tiene una relación.
(5) Información y métodos.
La estructura de comunicación entre objetos se llama mensaje. En las operaciones de un objeto, cuando se envía un mensaje a un objeto, el mensaje contiene información de que el objeto receptor realizará alguna acción. El envío de un mensaje debe incluir al menos el nombre del objeto que recibe el mensaje y el nombre del mensaje enviado al objeto (es decir, el nombre del objeto y el nombre del método). A menudo, es necesario interpretar parámetros, que pueden ser nombres de variables conocidos por el objeto que conoce el mensaje o nombres de variables globales conocidos por todos los objetos.
El proceso de implementación de operaciones en una clase se llama método. Un método tiene un nombre de método, parámetros y cuerpo de método. La transmisión de mensajes se muestra en la Figura 10-1.
2. Características orientadas a objetos
(1) Unicidad del objeto.
Cada objeto tiene su identificador único, a través del cual se puede encontrar el objeto correspondiente. Durante todo el ciclo de vida de un objeto, su bandera no cambiará y diferentes objetos no pueden tener la misma bandera.
②Clasificación.
La clasificación se refiere a abstraer objetos con estructuras de datos (atributos) y comportamientos (operaciones) consistentes en clases. Una clase es una abstracción que refleja propiedades importantes relevantes para una aplicación e ignora otro contenido irrelevante. La delimitación de cualquier categoría es subjetiva, pero debe ser relevante para la aplicación específica.
③Herencia.
La herencia es un mecanismo mediante el cual las subclases comparten automáticamente las estructuras de datos y los métodos de su clase principal. Esta es la relación entre clases. Al definir e implementar una clase, puede hacerlo sobre la base de una clase existente, tomar el contenido definido por la clase existente como propio y agregar contenido nuevo.
La herencia es la característica más importante que distingue a los lenguajes de programación orientados a objetos de otros lenguajes. Esto es algo que otros lenguajes no tienen.
En una jerarquía de clases, las subclases solo heredan las estructuras de datos y los métodos de la clase principal, lo que se denomina herencia única.
En una jerarquía de clases, las subclases heredan las estructuras de datos y los métodos de múltiples clases principales, lo que se denomina herencia múltiple.
En el desarrollo de software, la herencia de clases hace que el software creado sea abierto y extensible. Este es un método eficaz para organizar y clasificar información. Simplifica el esfuerzo de crear objetos y clases y aumenta la reproducibilidad del código.
Al utilizar la herencia, se proporciona una jerarquía de especificaciones de clases. A través de la relación de herencia de clases, se pueden compartir características comunes y se puede mejorar la reutilización del software.
(4) Polimorfismo
Polimorfismo significa que una misma operación, función o proceso puede actuar sobre múltiples tipos de objetos y obtener diferentes resultados. Diferentes objetos producirán resultados diferentes al recibir el mismo mensaje. Este fenómeno se llama polimorfismo.
El polimorfismo permite que cada objeto responda al mismo mensaje a su manera.
El polimorfismo mejora la flexibilidad y la reutilización del software.
Tercero, elementos orientados a objetos
(1) Abstracción.
Abstracto significa enfatizar la esencia y las propiedades inherentes de las entidades. En el desarrollo de sistemas, la abstracción se refiere al significado y comportamiento de un objeto antes de que se tomen decisiones sobre cómo implementarlo. El uso de abstracciones le impide pensar en los detalles demasiado pronto.
Las clases implementan la abstracción de los datos (es decir, el estado) y el comportamiento de un objeto.
(2) Encapsulación (ocultación de información).
La encapsulación es la base para garantizar una excelente modularidad de los componentes de software.
Una clase orientada a objetos es un módulo bien empaquetado. Una definición de clase separa explícitamente su descripción (la interfaz externa visible para el usuario) de su implementación (la implementación interna no visible para el usuario), y su implementación interna está protegida de acuerdo con su alcance específico de definición.
El objeto es la unidad más básica de encapsulación. La encapsulación previene los efectos de los cambios causados por las interdependencias del programa. El empaquetado orientado a objetos es más claro y potente que el empaquetado de lenguaje tradicional.
⑶* *Disfrute
La tecnología orientada a objetos promueve * * * disfrute en diferentes niveles.
* * *Misma categoría. Los objetos de la misma clase tienen la misma estructura de datos. Estos objetos comparten características estructurales y de comportamiento.
Disfruta de la misma aplicación. En la jerarquía de clases de la misma aplicación, existe herencia de estructuras de datos y comportamientos entre subclases similares que tienen una relación de herencia, de modo que todas las subclases similares * * * comparten la misma estructura y comportamiento. Usar la herencia para disfrutar del código es también una de las principales ventajas de la orientación a objetos.
Disfruta de diferentes aplicaciones. La orientación a objetos no sólo permite compartir información dentro de la misma aplicación, sino que también prepara el terreno para diseños reutilizables para objetivos futuros. A través del mecanismo y la estructura de la biblioteca de clases, se puede lograr el intercambio de información en diferentes aplicaciones.
4. Enfatizar la estructura del objeto más que la estructura del programa.
Cuarto, métodos de desarrollo orientados a objetos
En la actualidad, la investigación sobre métodos de desarrollo orientado a objetos se ha vuelto cada vez más madura y han aparecido en el mundo muchos productos orientados a objetos. Los métodos de desarrollo orientado a objetos incluyen el método Coad, el método Booch y el método OMT.
1. Método Booch
Booch describió por primera vez los problemas básicos del método de desarrollo de software orientado a objetos, señalando que el desarrollo orientado a objetos es un método de diseño que es fundamentalmente diferente del funcional tradicional. descomposición. La descomposición del software orientada a objetos está más cerca de la comprensión de los asuntos objetivos por parte de las personas, mientras que la descomposición funcional solo se puede obtener mediante la transformación del espacio del problema.
2.Método Coad
El método Coad es un método de desarrollo orientado a objetos propuesto por Coad y Yourdon en 1989. La principal ventaja de este método es que a través de la combinación orgánica de muchos años de experiencia en desarrollo de sistemas a gran escala y conceptos orientados a objetos, propone un conjunto de principios sistemáticos en la identificación de objetos, estructuras, atributos y operaciones. Este método completa la identificación adicional de clases y jerarquías de clases desde una perspectiva de requisitos. Aunque el método Coad no introduce la terminología de clases y jerarquías de clases, en realidad incorpora las características de clases y jerarquías de clases en conceptos como estructuras de clasificación, atributos, operaciones y asociaciones de mensajes.
3. Método OMT
El método OMT fue propuesto por James Rumbaugh y otros en 1991, y su trabajo clásico es "Modelado y diseño orientado a objetos".
Este método es un nuevo método de desarrollo orientado a objetos. El trabajo de desarrollo se basa en modelar objetos del mundo real y luego utilizar modelos analíticos para diseñar el lenguaje de forma independiente en torno a estos objetos. El modelado y diseño orientado a objetos promueve la comprensión de los requisitos y ayuda a desarrollar sistemas de software que sean más claros y fáciles de mantener. Este método proporciona una garantía práctica y eficiente para el desarrollo de software en la mayoría de los campos de aplicación y se esfuerza por encontrar métodos prácticos para resolver problemas.
4. Lenguaje de modelado unificado
De 1995 a 1997, el campo de la ingeniería de software ha logrado avances sin precedentes y sus logros superan la suma de los logros en el campo de la ingeniería de software en los últimos 15 años. Uno de los logros más importantes es la aparición del Lenguaje Unificado de Modelado (UML). UML se convertirá en el lenguaje de modelado estándar dominante en el campo de la tecnología orientada a objetos.
UML no solo unifica los métodos de representación del método Booch, el método OMT y el método OOSE, sino que también los desarrolla aún más y finalmente los unifica en un lenguaje de modelado estándar aceptado por el público. UML es un lenguaje de modelado bien definido, fácil de expresar, potente y de aplicación universal. Incorpora nuevas ideas, nuevos métodos y nuevas tecnologías en el campo de la ingeniería de software. Su alcance no se limita a respaldar el análisis y el diseño orientado a objetos, sino que también respalda todo el proceso, desde el análisis de requisitos hasta el desarrollo de software.
Modelo orientado a objetos de verbo (abreviatura de verbo)
Modelo de objetos
El modelo de objetos representa los atributos de datos estáticos y estructurados del sistema y describe los datos estáticos. estructura del sistema. Se describe desde la perspectiva de las relaciones objetales de entidades en el mundo objetivo, mostrando las relaciones mutuas entre objetos. Este modelo se centra en la estructura, propiedades y operaciones de los objetos del sistema. Es el núcleo de los tres modelos en fase de análisis y el marco de los otros dos modelos.
65438+
(1) Objeto.
El objetivo del modelado de objetos es describir objetos.
(2) Clase.
Al abstraer objetos en clases, podemos abstraer el problema y la abstracción mejora la capacidad de inducción del modelo.
③Atributos.
Los atributos se refieren a las propiedades (valores de datos) de los objetos de una clase.
(4) Operaciones y métodos.
Las operaciones son funciones o transformaciones utilizadas por los objetos de una clase. Cada objeto de esta clase puede disfrutar de operaciones y cada operación tiene un objeto de destino como parámetro implícito.
Los métodos son los pasos de implementación de las operaciones de clase.
2. Asociación y cadena
La asociación es un medio para establecer relaciones entre clases, mientras que las cadenas son un medio para establecer relaciones entre objetos.
(1) El significado de asociación y cadena.
La cadena representa la conexión física y conceptual entre objetos, la asociación representa la relación entre clases, la cadena es una instancia de asociación y la asociación es la abstracción de la cadena.
②Rol.
El rol describe el rol de la clase en la asociación y está ubicado en el punto final de la asociación.
(3) Limitar asociaciones.
Una asociación restringida consta de dos clases y un clasificador. Un calificador es un atributo específico que se utiliza para reducir eficazmente las asociaciones duplicadas. Los calificadores se describen en el conjunto de objetos de terminal asociado.
La calificación mejora la precisión semántica y las capacidades de consulta. En el mundo real, los calificativos aparecen con frecuencia.
④Multiplicidad de correlaciones.
La multiplicidad de asociación se refiere a cuántos objetos de una clase están relacionados con un objeto de la clase asociada. La multiplicidad se describe a menudo como "uno" o "muchos".
La Figura 10-8 muestra la diversidad de diversas asociaciones. Los pequeños círculos rellenos representan "muchos", de cero a muchos. Los pequeños círculos abiertos representan cero o uno. No hay ningún símbolo que indique una asociación uno a uno.
3. Jerarquía
(1) Relación de agregación.
La agregación es una relación de "parte entera". En esta relación hay clases enteras y clases parciales. Las propiedades más importantes de la agregación son la transitividad y la antisimetría.
La agregación puede tener diferentes niveles y se pueden agregar diferentes categorías para obtener un árbol de agregación simple. Los árboles de agregación son una representación simple que es mucho más simple que dibujar muchas líneas para conectar algunas clases. El modelo de objetos debería reflejar fácilmente todos los niveles. La Figura 10-10 muestra una agregación multipolar de microcomputadoras.
(2) Relación generalizada.
Las relaciones generalizadas son un método muy abstracto que permite disfrutar de la similitud de los objetos conservando sus diferencias. Ésta es una relación "generalmente específica". La clase generalizada se llama clase y la clase específica también se puede llamar subclase. Cada subclase hereda las propiedades de la clase cruzada y algunas de las *mismas* propiedades y operaciones de cada subclase se resumen en su clase. Por tanto, coexisten relaciones de generalización y herencia. La representación simbólica de una relación generalizada consiste en agregar un pequeño triángulo en la línea de conexión de la asociación de clase, como se muestra en la Figura 10-11.
4. Modelo de objetos
(1) Plantilla. Las plantillas son combinaciones lógicas de clases, asociaciones y estructuras generales.
(2) Modelo de objetos.
El modelo de objetos consta de una o varias plantillas. Las plantillas dividen el modelo en subpartes manejables y proporcionan una unidad intermedia integrada entre el modelo de objetos general y las clases y bloques de construcción asociados. Los nombres de clases y de asociaciones en las plantillas son únicos.
Modelos dinámicos
Los modelos dinámicos son propiedades del sistema que están relacionadas con el tiempo y el cambio. El modelo describe la estructura de control del sistema, que representa el control del sistema tanto transitorio como conductual.
La naturaleza está relacionada con el control del sistema y la secuencia de ejecución de las operaciones. Representa el comportamiento mutuo de los objetos desde la perspectiva de eventos y estados de los objetos.
Las propiedades del sistema descritas en este modelo son eventos desencadenantes, secuencias de eventos, estados y la organización de eventos y estados. Utilice diagramas de estado como herramienta de descripción. Implica conceptos importantes como eventos, estados y operaciones.
1. Evento
Un evento es algo que sucede en un momento específico.
2. Estado
El estado es la abstracción de los valores de los atributos del objeto. Los valores de los atributos de un objeto se combinan en un estado basado en las propiedades que afectan el comportamiento significativo del objeto. El estado representa la respuesta de un objeto a los eventos de entrada.
3. Gráfico de estados
Un gráfico de estados es un concepto informático estándar y una representación gráfica de un autómata finito. Aquí, los diagramas de estado se utilizan como herramienta gráfica para construir modelos dinámicos.
El diagrama de estados refleja la relación entre estados y eventos. Cuando se recibe un evento, el siguiente estado depende del estado actual y del evento recibido. El cambio de estado causado por el evento se denomina transición.
Un diagrama de estados es un diagrama en el que los nodos representan estados y los nodos están representados por círculos. Hay un nombre de estado en el círculo, conectado por una flecha para representar la transición de estado, el nombre del evento está marcado en él y la dirección de la flecha representa la dirección de la transición.
Modelo Funcional
El modelo funcional describe todos los cálculos del sistema. El modelo funcional dicta lo que sucede, el modelo dinámico determina cuándo sucede y el modelo de objetos determina lo que sucede. Los modelos funcionales muestran cómo un cálculo obtiene un valor de salida a partir de valores de entrada, independientemente del orden de los cálculos. El modelo funcional consta de varios diagramas de flujo de datos. Los diagramas de flujo de datos se utilizan para representar el flujo de valores de datos desde los objetos de origen a los objetos de destino. No contiene la información de control expresada en el modelo dinámico. Al mismo tiempo, el diagrama de flujo de datos no representa la organización de valores en el objeto, pero la organización de valores está representada en el modelo de objetos. La Figura 10-15 muestra el diagrama de flujo de datos mostrado por el icono del sistema de ventana.
El diagrama de flujo de datos incluye procesamiento, flujo de datos, objetos de acción y objetos de almacenamiento de datos.
1. Procesamiento
El procesamiento en un diagrama de flujo de datos se utiliza para cambiar los valores de los datos. El nivel más bajo de procesamiento es pura funcionalidad, mientras que el diagrama de flujo de datos completo es procesamiento de alto nivel.
2. Flujo de datos
El flujo de datos en el diagrama de flujo de datos vincula la salida y el procesamiento de objetos, el procesamiento y la entrada de objetos, y el procesamiento y el procesamiento. En las computadoras, los valores de datos intermedios están representados por flujos de datos que no pueden cambiar los valores de los datos.
3. Objeto de acción
Un objeto de acción es un objeto activo que impulsa el diagrama de flujo de datos generando o utilizando valores de datos.
4. Objeto de almacenamiento de datos
El almacenamiento de datos en el diagrama de flujo de datos es un objeto pasivo que se utiliza para almacenar datos. Es diferente de un objeto de acción. El almacén de datos en sí no genera ninguna operación, solo responde a necesidades de almacenamiento y acceso.
Análisis orientado a objetos de verbos intransitivos
El propósito del análisis orientado a objetos es modelar el sistema en el mundo objetivo. Con base en el concepto de modelo presentado anteriormente, esta sección combina el ejemplo específico del "sistema de red bancaria" para construir un modelo de análisis de problemas mundiales objetivo, preciso y riguroso.
El modelo de análisis tiene tres propósitos: aclarar los requisitos del problema; proporcionar requisitos claros para los usuarios y desarrolladores; proporciona una base para las negociaciones entre usuarios y desarrolladores y sirve como marco para el diseño y la implementación posteriores.
Análisis orientado a objetos
El primer paso en el análisis de un sistema es establecer los requisitos. El analista debe trabajar con el usuario para refinar los requisitos, ya que esto revela la verdadera intención del usuario, lo que implica analizar los requisitos y encontrar la información faltante. Tomamos como ejemplo el "sistema de red bancaria" y lo desarrollamos utilizando un método orientado a objetos.
Declaración del problema del sistema de red bancaria: diseñar software para respaldar la red bancaria, incluidas las estaciones de cajeros manuales y los cajeros automáticos que disfrutan las sucursales. Cada sucursal utiliza una computadora de sucursal para mantener sus propias cuentas y procesar sus propias transacciones; el cajero de cada sucursal se comunica con la computadora de la sucursal, y el cajero ingresa datos de cuentas y transacciones, el cajero automático se comunica con la computadora de la sucursal y la computadora de la sucursal; se comunica con la sucursal de apropiaciones Para la liquidación, el cajero automático acepta tarjetas de efectivo a través de la interfaz de usuario y se comunica con la computadora de la sucursal para completar transacciones, dispensar efectivo e imprimir recibos; el sistema requiere mantenimiento de registros y medidas de seguridad; el sistema debe manejar adecuadamente la concurrencia; el acceso a la misma cuenta; cada sucursal tiene su propio software de preparación informática, las tarifas de la red bancaria se asignan a cada sucursal en función del número de clientes y tarjetas de efectivo.
La Figura 10-18 es un diagrama esquemático del sistema de red bancaria.
②Establecer un modelo de objetos
Primero, identificar y asociar, porque afectan la estructura general y los métodos de resolución de problemas. En segundo lugar, agregue propiedades para describir con más detalle la red básica de clases y asociaciones, fusionando y organizando clases mediante herencia. Finalmente, las operaciones se agregan a la clase como subproducto de la construcción de modelos dinámicos y funcionales.
1. Determinar categorías
El primer paso en la construcción de un modelo de objetos es etiquetar las clases de objetos relevantes del dominio del problema, incluidas las entidades físicas y los conceptos. Todas las clases deben tener sentido en la aplicación, no todas las clases se dan explícitamente en el planteamiento del problema. Algunas están implícitas en el dominio del problema o en el sentido común.
Determine la categoría según el proceso que se muestra en la Figura 10-19.
Encuentra todos los sustantivos en el enunciado del problema y genera las siguientes clases tentativas.
Software Red bancaria Cajero Cajero automático Sucursal
Procesamiento separado y procesamiento separado Computadora Cuenta Transacción Cajero
Datos de transacción Sucursal Computadora Efectivo Tarjeta Usuario Efectivo
Sistema de recibos Datos de la cuenta de gastos del cliente
Obtener medidas de seguridad Mantenimiento de registros
Eliminar clases innecesarias e incorrectas según los siguientes criterios.
(1) Clase redundante: si dos clases expresan la misma información, se retiene la clase con mayor capacidad descriptiva. Por ejemplo, "Usuario" y "Cliente" son descripciones duplicadas, ya que "Cliente" es la más descriptiva, consérvela.
(2) Clases irrelevantes: Elimina las clases que son irrelevantes para el problema o que no son relevantes para el problema. Por ejemplo, las comisiones se extienden más allá de la red del banco.
(3) Clase difusa: la clase debe ser definida. Los límites de algunas clases tentativas son difusos o demasiado amplios, como el "mantenimiento de registros", que es parte de la "transacción".
(4) Atributos: Algunos sustantivos describen los atributos de otros objetos, por lo que se eliminan de la categoría tentativa. Si la independencia de un atributo es importante, entonces debería clasificarse como una clase, no como un atributo.
(5) Operación: si el sustantivo en el enunciado de la pregunta tiene un significado de acción, la operación descrita no es una clase. Pero las operaciones que tienen sus propias propiedades y necesitan existir de forma independiente deberían describirse como clases. Si solo construimos el modelo de teléfono, "Marcar" es parte del modelo dinámico y no una clase, pero en el sistema de marcación telefónica, "Marcar" es una clase importante con atributos como fecha, hora y ubicación de recepción.
En los sistemas de redes bancarias, las categorías difusas son "sistemas", "medidas de seguridad", "mantenimiento de registros" y "red bancaria". Estos atributos son: "Datos de cuenta", "Recibos", "Efectivo" y "Datos de transacciones". Perteneciente a la implementación, como "acceso" y "software". Estos deberían eliminarse.
2. Preparar diccionario de datos
Preparar un diccionario de datos para todas las entidades de modelado. Describa exactamente qué es cada clase y describa el alcance de la clase en el problema actual, incluidas las suposiciones o limitaciones sobre los miembros y el uso de la clase.
Determinar conexiones
La interdependencia entre dos o más clases es una asociación. Una dependencia representa una asociación que se puede implementar de diversas maneras, pero las consideraciones de implementación deben eliminarse del modelo de análisis para permitir una mayor flexibilidad en el diseño. Las asociaciones suelen estar representadas por verbos descriptivos o frases verbales e incluyen representaciones de ubicación física, acción conductora, comunicación, relaciones de propiedad, cumplimiento de condiciones, etc. Extraiga todas las posibles afirmaciones relevantes del planteamiento del problema y escríbalas, pero no refine estas afirmaciones prematuramente.
Las siguientes son todas las asociaciones posibles en el sistema de red bancaria, la mayoría de las cuales se obtienen extrayendo directamente las frases verbales de la pregunta. En los enunciados, la relevancia de algunas frases verbales no es obvia. Finalmente, hay algunas conexiones con el mundo objetivo o las suposiciones de las personas que deben verificarse con los usuarios porque estas conexiones no se pueden encontrar en el planteamiento del problema.
Relevancia en el planteamiento del problema de la red bancaria;
La red bancaria incluye cajeros y cajeros automáticos;
Sucursales * * * disfrutan de cajero automático
La sucursal proporciona una computadora para la sucursal;
La computadora de la sucursal realiza las cuentas;
La computadora de la sucursal maneja los pagos de la cuenta;
La sucursal tiene un cajero;
p>Comunicación por computadora entre el cajero y la sucursal;
El cajero ingresa transacciones para la cuenta;
El cajero automático acepta tarjetas de efectivo;
Cajeros automáticos automáticos e interfaz de usuario;
Los cajeros automáticos emiten efectivo;
Los cajeros automáticos imprimen recibos;
El sistema maneja el acceso simultáneo;
Las sucursales proporcionan software;
Compartir costos con sucursales.
Frase verbal implícita:
Una sucursal se compone de sucursales
Una sucursal tiene una cuenta
Una sucursal tiene sucursales Empresa; computadoras;
El sistema proporciona mantenimiento de registros;
El sistema proporciona seguridad;
El cliente tiene una tarjeta de efectivo.
Asociaciones basadas en el conocimiento del dominio problemático;
Las sucursales emplean cajeros;
Cuentas de acceso a tarjetas de efectivo.
Utilice los siguientes criterios para eliminar asociaciones innecesarias e incorrectas:
(1) Si se ha eliminado una categoría, las asociaciones relacionadas con ella también deben eliminarse o relacionarse con otra reasociación de categoría. . En el ejemplo que hemos eliminado "Red bancaria", las asociaciones relacionadas también deberían eliminarse.
(2) Asociaciones irrelevantes o asociaciones en la fase de implementación: Eliminar todas las asociaciones fuera del dominio del problema o involucradas en la estructura de implementación. Por ejemplo, "el sistema maneja el acceso concurrente" es un concepto de implementación.
(3) Acción: La asociación debe describir la naturaleza estructural del dominio de la aplicación en lugar de eventos transitorios, por lo que se deben eliminar "ATM acepta tarjetas de efectivo" y "ATM e interfaz de usuario".
(4) Asociación derivada: Omitir aquellas asociaciones que puedan ser definidas por otras asociaciones. Porque esta asociación es redundante. El diagrama de objetos preliminar del sistema de red bancaria se muestra en la Figura 10-20. Contiene conexiones.
4. Determinar los atributos
Los atributos son propiedades de un solo objeto y generalmente se representan mediante frases nominales decorativas. Los adjetivos a menudo representan valores de atributos específicos y enumerables que no se pueden expresar completamente en el enunciado de la pregunta. Sólo pueden descubrirse mediante el conocimiento del dominio aplicado y del mundo objetivo. Considere únicamente las propiedades que sean directamente relevantes para la aplicación específica y no considere aquellas que estén fuera del alcance del problema. Primero, identifique las propiedades importantes, evite aquellas que son solo para implementación y asigne a cada propiedad un nombre significativo. Elimine los atributos innecesarios e incorrectos según los siguientes criterios:
(1) Objeto: si la existencia independiente de una entidad es más importante que su valor, entonces la entidad no es un atributo sino un objeto. Por ejemplo, en el directorio postal, "ciudad" es un atributo, pero en el censo, "ciudad" se trata como un objeto. En determinadas aplicaciones, las entidades con propiedades propias deben ser objetos.
(2) Atributo: Si el valor del atributo depende de un contexto específico, podemos considerar reformular el atributo como un calificador.
(3) Nombre: El nombre se utiliza a menudo como un determinante más que como un atributo de objeto. Cuando un nombre no depende del contexto, es una propiedad de objeto, especialmente cuando no es único.
(4) Identificadores: al considerar la ambigüedad de los objetos, se introducen identificadores de objetos. Estos identificadores no figuran en el modelo de objetos, pero están implícitos en el modelo de objetos y solo se enumeran los atributos que existen en. el dominio de la aplicación.
(5) Valor interno: Si una propiedad describe el estado interno de un objeto opaco, debe eliminarse del modelo de objetos.
(6) Refinamiento: ignora los atributos que probablemente no afecten a la mayoría de las operaciones.
5. Utilice la herencia para refinar las clases
Usar la herencia * * * Hay dos formas de disfrutar de las instituciones públicas y turnarse para impartir clases.
(1) De abajo hacia arriba, generalizamos el * * * homomorfismo de la clase existente a la clase principal y buscamos clases con atributos, relaciones u operaciones similares para descubrir la herencia. Por ejemplo, "transacción remota" es similar a "transacción de cajero" y puede resumirse como "transacción". Algunas estructuras generales a menudo se basan en clasificaciones existentes de fronteras mundiales objetivas. Siempre que sea posible, intente utilizar conceptos existentes. La simetría a menudo ayuda a encontrar algunas clases faltantes.
(2) Refinar las clases existentes en subclases más específicas de arriba a abajo. La cosificación suele ser clara desde el área de aplicación. La aplicación de enumeradores en un dominio es la fuente más común de cosificación. Por ejemplo, los menús pueden incluir menús fijos, menús superiores, menús emergentes, menús desplegables, etc. , que puede subdividir las categorías del menú en varias subcategorías específicas del menú. Cuando el mismo nombre de asociación aparece varias veces y tiene el mismo significado, se debe especificar como una clase relacionada tanto como sea posible. Por ejemplo, si las "transacciones" ingresan desde "contador de efectivo" y "ATM", entonces "estación de entrada" es una generalización de "contador de efectivo" y "ATM". En una jerarquía de clases, puede asignar propiedades y asociaciones a clases específicas. Todos los atributos y deben asignarse a la clase más genérica y apropiada, a veces con algunas modificaciones.
Las enumeraciones en el dominio de la aplicación son la fuente de materialización más común.
6. Mejorar el modelo de objetos
El modelado de objetos no puede garantizar que el modelo sea completamente correcto la primera vez. Todo el proceso de desarrollo de software es un proceso de mejora continua. La mayoría de los diferentes componentes del modelo se completan en diferentes etapas. Si se encuentran fallas en el modelo, debemos volver a la etapa anterior para modificarlo y comenzar algunos trabajos de refinamiento después de que se completen el modelo dinámico y el modelo funcional.
(1) Varias situaciones posibles de objetos faltantes y sus soluciones:
Si hay atributos y operaciones irrelevantes en la misma clase, descomponga la clase para que cada parte esté interrelacionada;
Si el sistema de generalización no está claro, las clases que desempeñan dos roles se pueden separar.
Si hay una operación sin una clase objetivo, busca y agrega la clase sin objetivo.
Si hay una asociación redundante con el mismo nombre y propósito, crea la que falta; a través de la generalización Clase de padres para organizar asociaciones juntas.
(2) Encuentra clases redundantes.
Si faltan atributos, operaciones y asociaciones en una clase, se pueden eliminar.