[Revisión general de ingeniería de software] Capítulo 9 Metodología orientada a objetos (20 %~25 %)

1. Definición orientada a objetos

Orientado a objetos es descomponer cosas en objetos individuales, y luego dividir y cooperar entre objetos Orientado a objetos es dividir problemas por funciones de objetos, no por pasos. En la idea de desarrollo de programas orientados a objetos, cada objeto es un centro funcional con una clara división del trabajo.

2. Definición de metodología orientada a objetos

La metodología orientada a objetos es un método que toma datos o información como línea principal y combina datos y procesamiento, es decir, trata los objetos como una unidad compuesta por datos y operaciones que se pueden aplicar a estos datos.

El enfoque orientado a objetos se puede resumir mediante la siguiente ecuación:

OO = object（对象）+classes（类）+inheritance（继承）+communication with messages

3. Puntos clave de la metodología orientada a objetos

objeto

1. Un sistema de software orientado a objetos se compone de objetos, cualquier elemento del software es un objeto y los objetos de software complejos se componen de objetos relativamente simples.
2. El método tradicional de descomposición funcional se reemplaza por la descomposición del objeto, el objeto se abstrae de la entidad del mundo objetivo y no es fijo.

amable

1. Divida todos los objetos en varias clases de objetos, y cada clase de objeto define un conjunto de datos y un conjunto de métodos.
2. Los datos se utilizan para representar las propiedades estáticas del objeto, que es la información de estado del objeto.
3. El método definido en la clase es la operación que se permite aplicar al objeto de la clase, y es compartido por todos los objetos de la clase, y no necesita copiar el código de la operación para cada objeto.

Herencia

De acuerdo con la relación entre la subclase y la clase principal, varias clases de objetos se forman en un sistema jerárquico. Las subclases tienen automáticamente los mismos datos y métodos que la clase principal de nivel superior, y las características de nivel inferior protegerán las características de nivel superior con el mismo nombre.

1. En C++, las subclases pueden heredar clases principales y hay tres formas de herencia: pública, privada y protegida.
2. Los miembros de la subclase protegerán a los miembros de la clase principal con el mismo nombre. En este caso, lo llamamos ocultar o redefinir.

encapsulación

1. Los objetos pueden comunicarse entre sí solo pasando mensajes.
2. El objeto es objeto de procesamiento y debe enviar un mensaje para solicitarle que realice alguna operación y procese sus datos privados, pero no puede operar directamente con sus datos privados del mundo exterior.
3. Toda la información privada local del objeto se encapsula en la definición de la clase de objeto, como si estuviera contenida en una caja negra opaca, que es invisible para el mundo exterior y no se puede usar directamente.

①Se cree que el mundo objetivo se compone de varios objetos, todo es un objeto y los objetos complejos se pueden formar combinando objetos más simples de cierta manera. El enfoque orientado a objetos reemplaza la descomposición funcional del enfoque tradicional con la descomposición de objetos.
② Divida todos los objetos en varias clases de objetos, y cada clase define un conjunto de datos y un conjunto de métodos.
③Según la relación entre la subclase (o llamada clase de origen) y la clase principal (o llamada clase base), varias clases de objetos se forman en un sistema jerárquico (también llamado jerarquía de clases).
④ Los objetos solo pueden comunicarse entre sí pasando mensajes.

4. Ventajas de la metodología orientada a objetos

1. De acuerdo con la forma habitual de pensar del ser humano.

1.1 La tecnología de software orientada a objetos toma el objeto como núcleo, y el sistema de software desarrollado con esta tecnología está compuesto por objetos.
1.2 Un objeto es una unidad formada al encapsular los datos que describen el estado interno y representan las propiedades estáticas y las operaciones que se pueden aplicar a estos datos (el comportamiento dinámico del objeto).
1.3 El principio básico del método de diseño orientado a objetos es utilizar los conceptos del mundo real para pensar en los problemas de manera abstracta a fin de resolverlos de forma natural.
1.4 El principio básico de la metodología orientada a objetos es establecer un modelo del dominio del problema de acuerdo con el método de pensamiento de los hábitos humanos y desarrollar un sistema de software que exprese el método de solución de la manera más intuitiva y natural posible.
1.5 Los objetos utilizados en los sistemas de software orientados a objetos son abstracciones de entidades en el mundo objetivo.

2. buena estabilidad

2.1 La estructura del sistema de software orientado a objetos se establece con base en el modelo del dominio del problema, en lugar de basarse en la descomposición funcional del sistema. Por lo tanto, cuando los requisitos funcionales del sistema cambien, no causarán el cambio general. de la estructura del software, a menudo solo se requieren algunas modificaciones locales.
2.2 Dado que las entidades en el mundo real son relativamente estables, el sistema de software construido centrado en objetos también es relativamente estable.

3. buena reutilización

3.1 El mecanismo inherente de encapsulación y ocultación de información del objeto hace que la implementación interna del objeto esté aislada del mundo exterior y tenga una fuerte independencia.
3.2 Los objetos son módulos ideales y componentes de software reutilizables.
3.3 La tecnología de software orientada a objetos tiene una gran flexibilidad cuando se utilizan componentes de software reutilizables para construir nuevos sistemas de software.
3.4 Hay dos formas de reutilizar una clase de objeto: una es crear una instancia de la clase y usarla directamente; la otra es derivar una nueva clase que satisfaga las necesidades actuales.

4. Mayor facilidad para desarrollar grandes productos de software

Al desarrollar software con metodología orientada a objetos, cada objeto que construye el sistema de software es como un microprograma, con sus propios datos, operaciones, funciones y usos, por lo tanto, un producto de software a gran escala se puede descomponer en una serie de pequeño, esencialmente independiente No solo reduce la dificultad técnica del desarrollo, sino que también facilita la gestión del trabajo de desarrollo.

5. Buena mantenibilidad

El software orientado a objetos es más estable. El software orientado a objetos es más fácil de entender. Fácil de probar y depurar.

5. Análisis orientado a objetos

En el análisis orientado a objetos, se compone principalmente de modelo de objeto, modelo dinámico y modelo de función. El modelo de objetos es el más básico, el más importante y el central.

proceso de análisis orientado a objetos	Proceso de diseño orientado a objetos	es la etapa actual
Construya un modelo de dominio de aplicación que sea completamente independiente de la implementación	Agregue gradualmente la estructura del dominio de la solución al modelo	Compile la estructura del dominio de la aplicación y el dominio de la solución en el código del programa y realice una verificación de prueba estricta

5.1 Modelo de objetos

Describir varias relaciones entre las clases de estructura de datos del sistema : generalización, implementación, asociación (también dividida en asociación general, agregación, combinación y dependencia)

5.1.1 Método de diagrama de clases

5.1.1.1 Concepto de diagrama de clases

1. Muestra las clases, las interfaces y la estructura estática y las relaciones entre ellas.
2. Se utiliza para describir el diseño estructural del sistema.

5.1.1.2 Elementos de los diagramas de clases

1. Los diagramas de clases también pueden contener anotaciones y restricciones.
2. Los diagramas de clases también pueden contener paquetes y subsistemas, que se utilizan para agrupar elementos.
3. A veces, las instancias de una clase se pueden colocar en un diagrama de clase.

5.1.1.3 Clases

Una clase es una abstracción de un grupo de objetos con los mismos atributos, operaciones, relaciones y semántica. Es el núcleo de la estructura organizativa de un sistema orientado a objetos, que incluye una parte de nombre, una parte de atributo y una parte de operación. .

nombre	alumno
Atributos	+ nombre: cadena
funcionar	+aprender()

Sintaxis para atributos de clase

[visibilidad] nombre de atributo[:tipo] [=valor inicial] [{cadena de atributo}]
visibilidad: público (Público) "+", privado (Privado) "-", protegido (Protegido) "#"

La sintaxis para las operaciones de clase es

[visibilidad] nombre de la operación [(:lista de parámetros)] [:tipo de retorno] [{cadena de propiedad}]
visibilidad

Público (Público) "+", privado (Privado) "-", protegido (Protegido) "#", paquete público (Paquete) "~"

Tabla de parámetros

Definición

nombre: tipo

Si hay varios parámetros, separe cada parámetro con una coma;
el parámetro puede tener un valor predeterminado;

cadena de atributos

Agregue alguna información además de los elementos predefinidos en la definición de la operación.

5.1.1.4 Interfaz

Una clase puede implementar una o más interfaces.

La diferencia con el diagrama de clases es principalmente que hay una pantalla <> en la parte superior:

《interfaz》Persona
+ comer()

También se puede representar con un círculo hueco:

5.1.1.5 Colaboración

La colaboración significa que algunas clases, interfaces y otros elementos trabajan juntos para proporcionar algún comportamiento cooperativo, que no se obtiene simplemente agregando elementos.

5.1.1.6 Relaciones

5.1.2 Relaciones de clase

5.1.2.1 Relación de generalización

Semántica

La relación entre clases y subclases, la relación entre interfaces y subinterfaces;
una clase (llamada subclase, subinterfaz) hereda las funciones de otra clase (llamada clase padre, interfaz padre), y puede agregar sus propias funciones nuevas;

gramática

extiende

símbolo

Una implementación con una flecha triangular hueca, que apunta desde la subclase a la clase principal, o desde la subinterfaz a la interfaz principal;

5.1.2.2 Implementación de relaciones

Semántica

La relación entre clases e interfaces;
una clase puede implementar múltiples interfaces y realizar las funciones de todas las interfaces;
encarna el principio de separación de especificación e implementación;

gramática

implementos

símbolo

Una implementación se representa mediante una línea discontinua con una flecha triangular hueca que apunta desde la clase hasta la interfaz implementada;

5.1.2.3 Dependencias

Semántica

Una clase A usa otra clase B, pero esta relación es accidental, temporal y muy débil, pero los cambios en la clase B afectarán a la clase A;

gramática

La clase B existe como parámetro (o variable local) de un método de clase A;

símbolo

Una implementación se representa mediante una línea discontinua con una flecha triangular hueca que apunta desde la clase hasta la interfaz implementada;

5.1.2.4 Relación

Semántica

Más fuerte que la dependencia, inevitable, a largo plazo y fuerte;
dividido en asociación unidireccional (solo agregar estudiantes a la clase), asociación bidireccional (agregar atributos de clase a los estudiantes)
dividida en uno a uno (estudiantes y estudiantes). tarjetas de identificación), uno a muchos (clases y estudiantes), asociaciones de muchos a muchos (estudiantes y cursos)
tienen dos clases de asociaciones (clientes y pedidos, pedidos y mercancías), y una clase y sí mismo (los líderes también son empleados)

gramática

La clase B se forma en la clase A como una variable miembro;

símbolo

Está representado por una línea de puntos con una flecha que apunta de la clase A a la clase B,
la asociación bidireccional puede cancelar las dos flechas;

5.1.2.5 Relación de agregación

Semántica

Un caso especial de relación de asociación;
la relación entre el todo y la parte;
la parte completa se puede separar, y el ciclo de vida del todo es diferente al de la parte; la
relación entre has-a, la relación entre la computadora y la CPU , la relación empresa-empleado, la relación clase-estudiantes;

gramática

misma relación;

símbolo

Rombo hueco más flecha continua;

5.1.2.6 Relación de composición

Semántica

Un caso especial de relación de asociación;
la relación del todo y la parte, la parte del todo es inseparable, más fuerte que la agregación;
la relación de contiene-a;
el ciclo de vida del todo es el mismo que el ciclo de vida de la parte;
la relación entre personas y extremidades;

gramática

misma relación;

símbolo

Rombo sólido más flecha sólida;

El modelo de objetos de problemas complejos (sistemas a gran escala) generalmente consta de cinco capas subordinadas: capa de sujeto, capa de clase y objeto, capa de estructura, capa de atributos y capa de servicio.

5.2 Modelo dinámico

Describir la estructura de control del sistema.

5.2.1 Concepto de modelo dinámico

El modelo dinámico representa las propiedades de control del sistema instantáneo y de comportamiento, que estipula la secuencia de cambio legal de los objetos en el modelo de objeto.

5.2.2 Modelado de modelos dinámicos

Utilice el diagrama de estado proporcionado por UML para describir el estado del objeto, los eventos que desencadenan la transición de estado y el comportamiento del objeto. El comportamiento dinámico de cada clase se describe mediante un diagrama de estado, y los diagramas de estado de cada clase se combinan compartiendo eventos para formar un modelo dinámico del sistema, es decir, un modelo dinámico es una colección de un grupo de diagramas de estado que están relacionados entre sí en función del uso compartido de eventos.

5.2.2.1 Diagrama de secuencia/Diagrama de tiempo

cuatro elementos

Objeto Objeto
Lifeline Lifeline
Mensaje Mensaje
Activación Activación

5.2.2.2 Diagrama de colaboración

1. Describir la relación de colaboración organizacional entre objetos, que también puede reflejar el comportamiento de los casos de uso del sistema.
2. Un diagrama de colaboración consta de elementos básicos como actores, objetos, conexiones y mensajes.

5.2.2.3 Diagrama de estado

1. El diagrama de estado se usa principalmente para describir el comportamiento dinámico de un objeto durante su existencia, para representar la secuencia de estado experimentada por un objeto, los eventos que causan la transición de estado y las acciones que lo acompañan debido a la transición de estado.
2. En general, una máquina de estado se puede utilizar para modelar el ciclo de vida de un objeto.
3. El diagrama de estado se utiliza para mostrar la máquina de estado, centrándose en describir el flujo de control entre estados.

5.2.2.3.1 Comparación de diagramas de estado y diagramas de actividad

El enfoque de la descripción es diferente.

1. Un diagrama de estado describe el estado de un objeto y las transiciones entre estados
2. Los diagramas de actividad describen el flujo de control de una actividad a otra

Diferentes ocasiones

1. Si se trata de mostrar el comportamiento de un objeto durante su ciclo de vida, es mejor utilizar un diagrama de estado
2. Si el propósito es analizar casos de uso, comprender el flujo de trabajo que involucra múltiples casos de uso, o usar aplicaciones de subprocesos múltiples, etc., es mejor usar diagramas de actividad.

5.3 Modelo funcional

Describir la funcionalidad del sistema.

5.3.1 Concepto de modelo funcional

5.3.1.1 Definición de modelo funcional

El modelo funcional representa las propiedades funcionales del sistema cambiante, que especifica lo que debe hacer el sistema y, por lo tanto, refleja más directamente las necesidades del usuario para el sistema de destino.

5.3.1.2 Composición del modelo funcional

Un modelo funcional consta de un conjunto de diagramas de flujo de datos

5.3.2 Diagrama de casos de uso (énfasis)

El diagrama de casos de uso proporcionado por UML también es una herramienta poderosa para el análisis de requisitos y la construcción de modelos funcionales. En UML, el modelo de sistema construido con el diagrama de casos de uso se denomina modelo de casos de uso.

5.3.2.1 Definición de diagrama de casos de uso

El modelo de caso de uso describe la funcionalidad del sistema tal como lo entienden los actores externos. El establecimiento del modelo de caso de uso es el resultado de discusiones repetidas entre el desarrollador del sistema y el usuario, y describe el consenso alcanzado por el desarrollador y el usuario sobre la especificación de requisitos.

5.3.2.2 Representación de diagramas de casos de uso

5.3.2.2.1 Sistema

definición

El sistema se ve como una caja negra que proporciona casos de uso, cómo funciona internamente y cómo se implementan los casos de uso no son importantes para construir un modelo de diagrama de casos de uso.

expresar

El sistema está representado por un cuadro y su borde representa el límite del sistema, que se utiliza para delinear el alcance funcional del sistema y definir las funciones del sistema. Los casos de uso que describen la funcionalidad del sistema se colocan dentro de la caja, los actores que representan entidades externas se colocan fuera de la caja.

5.3.2.2.2 Casos de uso

definición

Un caso de uso es percibido por los actores (participantes) y es una función completa de un sistema. Defina un caso de uso en UML como una serie de acciones completadas por el sistema

expresar

En UML, una elipse representa un caso de uso. Los casos de uso están conectados a los actores (participantes) a través de asociaciones, que indican con qué actores (participantes) interactúa un caso de uso, y esta interacción es bidireccional.

característica

1. Un caso de uso representa alguna funcionalidad visible para el usuario que logra un objetivo específico del usuario
2. Un caso de uso siempre lo inicia un actor (actor) y proporciona un valor identificable al actor (actor)
3. El caso de uso debe estar completo

Aviso

Un caso de uso es una clase que representa una clase de funcionalidad en lugar de una instancia específica que usa esa funcionalidad. Un ejemplo de un caso de uso es un método de uso real del sistema, y ​​el caso de uso generalmente se denomina script. Un script es un proceso de ejecución específico del sistema.

5.3.2.2.3 Actores (participantes)

definición

Los actores (participantes) son personas u otros sistemas que interactúan con el sistema, representando entidades externas. Cualquiera o cualquier cosa que use un caso de uso e interactúe con el sistema es un actor (participante). Un actor (participante) representa un papel en lugar de una persona o cosa específica.

expresar

En UML, un liniero representa a un actor. En el diagrama de casos de uso, el actor (participante) y el caso de uso están conectados por una línea recta, lo que significa que se intercambia información entre los dos, lo que se denomina enlace de comunicación. Los actores desencadenan casos de uso e intercambian información con casos de uso. Un solo actor se puede asociar con múltiples casos de uso, y un caso de uso se puede asociar con múltiples actores.

5.3.2.2.4 Relaciones de casos de uso

relación extendida

Agregar algunas acciones a un caso de uso constituye otro caso de uso. La relación entre estos dos casos de uso es la relación de extensión. El último hereda algunos comportamientos del primero, y el último generalmente se denomina caso de uso extendido.

relación de uso (relación contiene)

Cuando un caso de uso utiliza otro caso de uso, se forma una relación de uso (relación de contención) entre los dos casos de uso.

5.3.2.2.4.1 Similitudes y diferencias en las relaciones de casos de uso

1. Ambos extraen esos comportamientos comunes de varios casos de uso y los colocan en un solo caso de uso, que es usado (incluido) o extendido por otros casos de uso
2. Los propósitos de usar (contener) y extender son diferentes. Las relaciones extendidas se utilizan cuando se describen cambios en el comportamiento general.
3. Cuando existan descripciones duplicadas en dos o más casos de uso y se quiera evitar esta duplicidad, utilice la relación de uso (relación de contención)

5.3.2.2.5 Ejemplos

Ejemplo 1 Registro del sistema de gestión de estudiantes

Ejemplo 2 Sistema de enseñanza en red (similar al uso de Learning Pass)

Ejemplo 3 Préstamo de libros

Los prestatarios del sistema son estudiantes y profesores, y el sistema proporciona a los prestatarios los servicios de consulta de libros, préstamo de libros y devolución de libros. Los estudiantes pueden tomar prestados hasta 5 libros y los maestros pueden tomar prestados hasta 20 libros. Al tomar prestados y devolver libros, primero debe "verificar la identidad del prestatario". Al devolver los libros, si vencidos, para pagar una multa. Si el libro que el profesor quiere tomar prestado ha sido prestado, el profesor también puede reservar el libro a través del servicio de reserva de libros. Después de la reserva, el libro puede ser prestado primero.

Ejemplo 4 Sistema de pedido de billetes de tren

En el sistema de reserva de billetes de tren, los clientes pueden realizar cuatro operaciones: comprar billetes, dar de baja billetes, consultar billetes restantes y consultar horarios de trenes. No importa comprar un boleto o darse de baja de un boleto, el usuario primero debe iniciar sesión en el sistema. La consulta de tiempo de tren incluye principalmente dos formas: consulta por estación y consulta por número de tren. Si olvida su contraseña durante el proceso de inicio de sesión en el sistema, también puede utilizar la función de recuperación de su contraseña.

Ejemplo 5 Compra de bienes

El sistema tiene una función de registro. Los clientes solo pueden comprar productos en el sistema iniciando sesión después del registro; los
clientes pueden buscar productos a través del sistema, ver información detallada de los productos y comprar los productos que les gustan;
los clientes deben pagar de varias maneras, ya sea a través del banco en línea La función de pago también se puede pagar mediante remesa;
el sistema tiene una función de promoción de productos, y para algunos productos especificados por el sistema o cuando la cantidad del producto comprado por el usuario supera una cierta cantidad, el cliente recibir un descuento al pagar; después de que el cliente inicie sesión, el usuario
puede usar la función de mensajes para comentar sobre productos o servicios; los
administradores del sistema pueden usar la función de mensajes para responder preguntas planteadas por los clientes y administrar usuarios registrados; el
personal de entrada puede actualizar información de productos, incluida la adición de nuevos productos y la actualización de productos existentes Actualización de información;
el sistema permite que varias personas estén en línea al mismo tiempo para buscar y comprar productos.

Ejemplo 6 Selección de cursos en línea

En el "módulo de selección de cursos en línea" del sistema de gestión de información del estudiante, los estudiantes pueden realizar tres operaciones: "ver información del curso", "seleccionar curso" y "eliminar curso seleccionado". "Ver información del curso" incluye principalmente dos formas: "ver por número de curso" y "ver por nombre de curso".
Los administradores pueden realizar la operación "mantener información del curso".
Todas las operaciones de estudiantes y administradores deben "iniciar sesión en el sistema" antes de que puedan completarse. Si olvida su contraseña durante el proceso de "iniciar sesión en el sistema", también puede utilizar la función "recuperar contraseña".

Ejemplo 7 Sistema de gestión de salas de ajedrez y naipes

En el sistema de gestión de la sala de ajedrez y naipes, los clientes deben verificar la información de los asientos a través de la operación de reserva de asientos a través de la red. Seleccione Procesar cola de espera si no hay asientos libres o satisfechos.
Cuando el cliente llega a la sala de ajedrez y cartas, el mesero en la recepción organiza el asiento y se debe verificar la información del asiento.
Cuando el cliente quiere salir de la sala de ajedrez y naipes, el empleado de la recepción debe manejar el pago, que admite el pago en efectivo y el pago con tarjeta bancaria a través del sistema POS de UnionPay.

6. Comparación de tres modelos

1. Un modelo dinámico establecido para cada clase que describe el ciclo de vida o tiempo de ejecución de una instancia de clase
2. Las transiciones de estado impulsan comportamientos que se asignan a procesos en diagramas de flujo de datos y casos de uso en diagramas de casos de uso, que también corresponden a servicios en diagramas de clase.
3. El procesamiento en el modelo funcional debe corresponder a los servicios provistos por las clases en el modelo de objetos
4. Los almacenes de datos en el diagrama de flujo de datos y los puntos de origen/destino de los datos suelen ser objetos en el modelo de objetos.
5. El flujo de datos en el diagrama de flujo de datos suele ser el valor de atributo del objeto en el modelo de objetos, o puede ser el objeto completo
6. Actores en un diagrama de casos de uso, posiblemente objetos en un modelo de objetos
7. El procesamiento en el modelo funcional puede generar eventos en el modelo dinámico
8. El modelo de objetos describe el flujo de datos, el almacenamiento de datos y la estructura de origen/destino de datos en el diagrama de flujo de datos.

Método orientado a objetos para desarrollar software, generalmente necesita establecer tres tipos de modelos:
modelo de objeto ---- describe la estructura de datos del sistema.
Modelo dinámico ---- describe la estructura de control del sistema.
Modelo funcional----Descripción de las funciones del sistema.
Estos tres modelos involucran conceptos como datos, control y operación, pero el énfasis de cada modelo es diferente.
Un sistema de software típico combina estos tres aspectos, ya que utiliza estructuras de datos (modelo de objetos), realiza operaciones (modelo dinámico) y logra cambios en los valores de los datos (modelo funcional).