Guia de Estudio de Ingenieria del Software IIfiles.rfernandez.webnode.es/200000012-5265353606/Guia...

CAPÍTULO

20 CONCEPTOS Y PRINCIPIOS ORIENTADOS A

OBJETOS

20.1 El paradigma orientado a objetos

Durante muchos años el término orientado a objetos (00) se usó para referirse a un enfoque de desarrollo de software que usaba uno de los lenguajes orientados a objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). Hoy en día el paradigma O0 encierra una completa visión de la ingeniería del software. Edward Berard hace notar esto cuando declara: Los beneficios de la tecnología orientada a objetos se fortalecen si se usa antes y durante el proceso de ingeniería del software. Esta tecnología orientada a objetos considerada debe hacer sentir su impacto en todo el proceso de ingeniería del software. Un simple uso de programación orientada a objetos (POO) no brindará los mejores resultados. Los ingenieros del software y sus directores deben considerar tales elementos el análisis de requisitos orientado a objetos (AROO), el diseño orientado a objetos (DOO), el análisis del dominio orientado a objetos (ADOO), sistemas de gestión de bases de dalos orientadas a objetos (SGBDOO) y la ingeniería del software orientada a objetos asistida por computadora (ISOOAC).

Con los objetos es realmente más fácil construir modelo para sistemas complejos que dedicarse o la programación secuencial. 20.2 Conceptos de orientación a objetos

La programación orientada a objetos no es tanto una técnica de codificación de paquetes como una manera de que los constructores de software encapsulen funcionalidades para proporcionárselas a sus clientes.

El encapsulamiento significa que toda esta información se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificación o componente de programa. 20.2.1. Clases y objetos Los conceptos fundamentales que llevan a un diseño de alta calidad son igualmente aplicables a sistemas desarrollados usando métodos convencionales y orientados a objetos. Por esta razón, un modelo O0 de software de computadora debe exhibir abstracciones de datos y procedimientos que conducen a una modularidad eficaz. Una clase es un concepto O0 que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real. 20.3 Identificación de los Elementos de un Modelo de Objetos Los objetos se manifiestan de alguna de las formas:

1. Entidades externas (por ejemplo: otros sistemas, dispositivos, personas) que producen o consumen información a usar por un sistemas computacional.

2. Cosas (por ejemplo: informes, presentaciones, cartas, señales) que son parte del dominio de información del problema.

3. Ocurrencias o sucesos5 (por ejemplo: una transferencia de propiedad o la terminación de una serie de movimientos en un robot) que ocurren dentro del contexto de una operación del sistema.

4. Papeles o roles (por ejemplo: director, ingeniero, vendedor) desempeñados por personas que interactúan con el sistema.

5. Unidades organizacionales (por ejemplo: división, grupo, equipo) que son relevantes en una aplicación.

6. Lugares (por ejemplo: planta de producción o muelle de carga) que establecen el contexto del problema y la función general del sistema.

7. Estructuras (por ejemplo: sensores, vehículos de cuatro ruedas o computadoras) que definen una clase de objetos o, en casos extremos, clases relacionadas de objetos.

Coad y Yourdon sugieren seis características de selección a usar cada vez que un analista considera si incluye o no un objeto potencial en el modelo de análisis:

1. Información retenida: el objeto potencial será de utilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funcione.

2. Servicios necesarios: el objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de sus atributos.

3. Atributos múltiples: durante el análisis de requisitos, se debe centrar la atención en la información principal (un objeto con un solo atributo puede, en efecto, ser Útil durante el diseño, pero seguramente será mejor presentado como un atributo de otro objeto durante la actividad de análisis);

4. Atributos comunes: puede definirse un conjunto de atributos para el objeto potencial, los cuales son aplicables a todas las ocurrencias del objeto.

5. Operaciones comunes: puede definirse un conjunto de operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto;

6. Requisitos esenciales: entidades externas que aparecen en el espacio del problema y producen o consumen información esencial para la producción de cualquier solución para el sistema, serán casi siempre definidas como objetos en el modelo de requisitos.

20.4 Gestión de proyectos de software orientado a objetos Ed Berard y Grady Booch, entre otros, sugieren el uso de un «modelo recursivo/paralelo>> p ara el desarrollo de software orientado a objetos. En esencia, el modelo recursivo/paralelo funciona de la siguiente manera:

• Realizar los análisis suficientes para aislar las clases del problema y las conexiones más importantes.

• Realizar un pequeño diseño para determinar si las clases y conexiones pueden ser implementadas de manera práctica.

• Extraer objetos reutilizables de una biblioteca para construir un prototipo previo.

• Conducir algunas pruebas para descubrir errores en el prototipo. • Obtener realimentación del cliente sobre el prototipo. • Modificar el modelo de análisis basándose en lo que se ha aprendido del

prototipo, de la realización del diseño y de la realimentación obtenida del cliente.

• Refinar el diseño para acomodar sus cambios. • Construir objetos especiales (no disponibles en la biblioteca).

CAPÍTULO

21 ANÁLISIS ORIENTADO A OBJETOS

El propósito del A00 es definir todas las clases que son relevantes al problema que se va a resolver, las operaciones y atributos asociados, las relaciones y comportamientos asociadas con ellas. Para cumplirlo se deben ejecutar las siguientes tareas:

1. Los requisitos básicos del usuario deben comunicarse entre el cliente y el ingeniero del

2. Identificar las clases (es decir, definir atributos y métodos). 3. Se debe especificar una jerarquía de clases. 4. Representan las relaciones objeto a objeto (conexiones de objetos). 5. Modelar el comportamiento del objeto. 6. Repetir iterativamente las tareas de la 1 a la 5 hasta completar el modelo.

21.1.2. El panorama del A00 El método de Booch. El método de Booch abarca un «microproceso de desarrollo» y un «macroproceso de desarrollo». El nivel micro define un conjunto de tareas de análisis que se reaplican en cada etapa en el macro proceso. Por esto se mantienen un enfoque evolutivo. El micro proceso de desarrollo identifica clases y objetos y la semántica de dichas clases y objetos, define las relaciones entre clases y objetos y realiza una serie de refinamientos para elaborar el modelo del análisis. El método de Rumbaugh. Rumbaugh y sus colegas desarrollaron la Técnica de Modelado de Objetos (OMT) para el análisis, diseño del sistema y diseño a nivel de objetos. La actividad de análisis crea tres modelos: el modelo de objetos (una representación de objetos, clases, jerarquías y relaciones), el modelo dinámico (una representación del comportamiento del sistema y los objetos) y el modelo funcional (una representación a alto nivel del flujo de información a través del sistema similar al DFD). El método de Jacobson. También llamado OOSE (en español Ingeniería del Software Orientada a Objetos), el método de Jacobson es una versión simplificada de Objectory, un método patentado, también desarrollado por Jacobson. Este método se diferencia de los otros por la importancia que da al caso de uso – una descripción o escenario que describe cómo el usuario interactúa con el producto o sistema. El método de Coad y Yourdon. El método de Coad y Yourdon [COA911 se considera, con frecuencia, como uno de los métodos del A00 más sencillos de aprender.

La notación del modelado es relativamente simple y las reglas para desarrollar el modelo de análisis son evidentes. A continuación sigue una descripción resumida del proceso de A00 de Coad y Yourdon:

• Identificar objetos, usando el criterio de «qué buscar». • Definir una estructura de generalización-‐especificación. • Definir una estructura de todo-‐parte. • Identificar temas (representaciones de componentes de subsistemas). • Definir atributos. • Definir servicios.

El método de Wirfs-‐Brock. El método de Wirfs-‐ Brock no hace una distinción clara entre las tareas de análisis y diseño. En su lugar, propone un proceso continuo que comienza con la valoración de una especificación del cliente y termina con el diseño. A continuación se esbozan brevemente las tareas relacionadas con el análisis de Wirfs-‐Brock:

• Evaluar la especificación del cliente. • Usar un análisis gramatical para extraer clases candidatas de la especificación. • Agrupar las clases en un intento de determinar superclases. • Definir responsabilidades para cada clase. • Asignar responsabilidades a cada clase. • Identificar relaciones entre clases. • Definir colaboraciones entre clases basándose en sus responsabilidades. • Construir representaciones jerárquicas de clases para mostrar relaciones de

herencia. • Construir un gafo de colaboraciones para el sistema.

21.2 Análisis del dominio El objetivo del análisis del dominio es definir el conjunto de clases (objetos) que se encuentran en el dominio de lo aplicación. Dichas clases podrán reutilizarse muchas veces. 21.2.2. El proceso de análisis del dominio El análisis del dominio del software es la identificación, análisis y especificación de requisitos comunes de un dominio de aplicación específico, normalmente para su reutilización en múltiples proyectos dentro del mismo dominio de aplicación (el análisis orientado a objetos del dominio es la identificación, análisis y especificación de capacidades comunes y reutilizables dentro de un dominio de aplicación específico, en términos de objetos, clases, submontajes y marcos de trabajo comunes.

FIGURA 21.1. Entrada y salida para análisis del dominio. 21.4.2. Modelado de clases-‐responsabilidades-‐colaboraciones Una vez que se han desarrollado los escenarios de uso básicos para el sistema, es el momento de identificar las clases candidatas e indicar sus responsabilidades y colaboraciones. El modelado de clases-‐responsabilidades-‐colaboraciones (CRC) aporta un medio sencillo de identificar y organizar las clases que resulten relevantes al sistema o requisitos del producto. Ambler [AMB95] describe el modelado CRC de la siguiente manera: Un modelo CRC es realmente una colección de tarjetas índice estándar que representan clases. Las tarjetas están divididas en tres secciones. A lo largo de la cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo se listan las responsabilidades de la clase a la izquierda y a la derecha los colaboradores. Adicionalmente, los objetos y clases pueden clarificarse por un conjunto de características: Tangibilidad. ¿Representa la clase algo tangible o palpable (por ejemplo, un teclado o sensor), o representa información más abstracta (por ejemplo: una salida prevista)? Exclusividad. ¿Es la clase atómica (es decir, no incluye otras clases) o es agregada (incluye al menos un objeto anidado)? Secuencia. ¿Es la clase concurrente (es decir posee su propio hilo de control) o secuencial (es controlada por recursos externos)? Persistencia. La clase es temporal (se crea durante !a ejecución del programa y es eliminada una vez que éste termina), o permanente (es almacenada en una base de datos)? Integridad. ¿Es la clase corrompible (es decir, no protege sus recursos de influencias externas) o es segura (la clase refuerza los controles de accesos a-‐ sus recursos)?

CAPÍTULO

22 DISEÑO ORIENTADO A OBJETOS 22.1 Diseño para sistemas orientados a objetos Las cuatro capas de la pirámide de diseño O0 son:

1. La capa subsistema. Contiene una representación de cada uno de los subsistemas, para permitir al software conseguir sus requisitos definidos por el cliente e implementar la infraestructura que soporte los requerimientos del cliente.

2. La capa de clases y objetos. Contiene la jerarquía de clases, que permiten al sistema ser creado usando generalizaciones y cada vez especializaciones más acertadas. Esta capa también contiene representaciones.

3. La capa de mensajes. Contiene detalles de diseño, que permite a cada objeto comunicarse con sus colaboradores. Esta capa establece interfaces externas e internas para el sistema.

4. La capa de responsabilidades. Contiene estructuras de datos y diseños algorítmicos, para todos los atributos y operaciones de cada objeto.

FIGURA 22.1. La pirámide del Diseño OO.

22.1.1. Enfoque convencional vs. OO

FIGURA 22.2. Transformación de un modelo de análisis O0 a un modelo de diseño OO. Fichman y Kemerer [FIC92] sugieren diez componentes de diseño modelado, que pueden usarse para comparar varios métodos convencionales y orientados a objetos:

1. representación de la jerarquía de módulos. 2. especificación de las definiciones de datos. 3. especificación de la lógica procedimental. 4. indicación de secuencias de proceso final-‐a-‐final (end-‐to-‐end) 5. representación de estados y transiciones de los objetos. 6. definición de clases y jerarquías. 7. asignación de operaciones a las clases. 8. definición detallada de operaciones. 9. especificación de conexiones de mensajes. 10. identificación de servicios exclusivos.

22.1.2. Aspectos del diseño Bertrand Meyer sugiere cinco criterios para juzgar la capacidad de métodos de diseño para conseguir modularidad, y los relaciona al diseño orientado a objetos: Descomponibilidad: la facilidad con que un método de diseño ayuda al diseñador a descomponer un problema grande en problemas más pequeños, haciéndolos más fácil de resolver.

Componibilidad el grado con el que un método de diseño asegura que los componentes del programa (módulos), una vez diseñados y construidos, pueden ser reutilizados para crear otros sistemas. Comprensibilidad la facilidad con la que el componente de un programa puede ser entendido, sin hacer referencia a otra información o módulos. Continuidad: la habilidad para hacer pequeños cambios en un programa y que se revelen haciendo los cambios pertinentes en uno o muy pocos módulos. Protección: una característica arquitectónica, que reduce la propagación de efectos colaterales, si ocurre un error en un módulo dado. De estos criterios, Meyer, sugiere cinco principios básicos de diseño, que pueden ser deducidos para arquitecturas modulares: (1) unidades lingüísticas modulares, (2) pocas interfaces, (3) pequeñas interfaces (acoplamiento débil), (4) interfaces explícitas y (5) ocultación de información. 22.1.3. El Panorama de DO0 Haremos una breve revisión global de los primeros métodos de DOO: El método de Booch. Como se vio en el Capítulo 21, el método Booch abarca un «proceso de micro desarrollo» y un <<proceso de macro desarrollo». En el contexto del diseño, el macro desarrollo engloba una actividad de planificación arquitectónica, que agrupa objetos similares en particiones arquitectónicas separadas, capas de objetos por nivel de abstracción, identifica situaciones relevantes, crea un prototipo de diseño y valida el prototipo aplicándolo a situaciones de uso. El método de Rumbaugh. La técnica de modelado de objetos (TMO) [RUM91] engloba una actividad de diseño que alienta al diseño a ser conducido a dos diferentes niveles de abstracción. El diseño de sistema se centra en el esquema de los componentes que se necesitan para construir un sistema o producto completo. El modelo de análisis se divide en subsistemas, los cuales se asignan a procesadores y tareas. El método de Jacobson. El diseño para ISOO (Ingeniería del software orientada a objetos) es una versión simplificada del método propietario Objectory, también desarrollado por Jacobson. El modelo de diseño enfatiza la planificación para el modelo de análisis ISOO. En principio, el modelo idealizado de análisis se adapta para acoplarse al ambiente del mundo real. El método de Coad y Yourdon. Éste método para DO0, se desarrolló estudiando «cómo es que los diseñadores orientados a objetos efectivos» hacen su trabajo. La aproximación de diseño dirige no sólo la aplicación, sino también la infraestructura de la aplicación, y se enfoca en la representación de cuatro componentes mayores de sistemas: la componente de dominio del problema, la componente de interacción humana, la componente de administración de tareas y la de administración de datos.

El método de Wirfs-‐Brock. Wirfs-‐Brock, Wilkerson y Weiner definen un conjunto de tareas técnicas, en la cual el análisis conduce sin duda al diseño. Los protocolos3 para cada clase se construyen refinando contratos entre objetos. Cada operación (responsabilidad) y protocolo (diseño de interfaz) se diseña hasta un nivel de detalle que guiará la implementación. Se desarrollan las especificaciones para cada clase (definir responsabilidades privadas y detalles de operaciones) y cada subsistema (identificar las clases encapsuladas y la interacción entre subsistemas). Para llevar a cabo un diseño orientado a objetos, un ingeniero de software debe ejecutar las siguientes etapas generales:

1. Describir cada subsistema y asignar a procesadores y tareas. 2. Elegir una estrategia para implementar la administración de datos, soporte de

interfaz y administración de tareas. 3. Diseñar un mecanismo de control, para el sistema apropiado. 4. Diseñar objetos creando una representación procedural para cada operación, y

estructuras de datos para los atributos de clase. 5. Diseñar mensajes, usando la colaboración entre objetos y relaciones. 6. Crear el modelo de mensajería. 7. Revisar el modelo de diseño y renovarlo cada vez que se requiera.

FIGURA 22.3. Flujo de Proceso para DOO.

22.2 El proceso de diseño de sistema El diseño de sistema desarrolla el detalle arquitectónico requerido para construir un sistema o producto. El proceso de diseño del sistema abarca las siguientes actividades:

• Partición del modelo de análisis en subsistemas. • Identificar la concurrencia dictada por el problema. • Asignar subsistemas a procesadores y tareas. • Desarrollar un diseño para la interfaz de usuario. • Elegir una estrategia básica para implementar la administración (gestión) de

datos. • Identificar recursos globales y los mecanismos de control requeridos para su

acceso. • Diseñar un mecanismo de control apropiado para el sistema, incluyendo

administración de tareas. • Considerar cómo deben manejarse las condiciones de frontera. • Revisar y considerar trade-‐offs.

Cuando se definen (y diseñan) los subsistemas, se deben seguir los siguientes criterios de diseño:

• El subsistema debe tener una interfaz bien definida, a través de la cual se reduzcan todas las comunicaciones con el resto del sistema.

• Con la excepción de un pequeño número de «clases de comunicación», las clases incluidas dentro del subsistema deben colaborar sólo con otras clases dentro del subsistema.

• El número de subsistemas debe ser bajo. • Un subsistema puede ser particionado internamente, para ayudar a reducir la

complejidad. Buschmann y sus colegas sugieren el siguiente enfoque de diseño para estratificación por capas:

1. Establecer los criterios de estratificación por capas. Esto significa decidir cómo se agruparán los subsistemas en una arquitectura de capas.

2. Determinar el número de capas. Muchas de ellas complican innecesariamente; muy pocas debilitan la independencia funcional.

3. Nombrar las capas y asignar subsistemas (con sus clases encapsuladas) a una capa. Asegurarse de que la comunicación entre subsistemas (clases) en una capa, y otros subsistemas (clases) en otra capa, siguen la filosofía de diseño de la arquitectura.

4. Diseñar interfaces para cada capa. 5. Refinar los subsistemas, para establecer la estructura de clases para cada capa. 6. Definir el modelo de mensajería para la comunicación entre capas.

7. Revisar el diseño de capas, para asegurar que el acoplamiento entre capas se minimiza (un protocolo cliente/servidor puede ayudar a realizar esta tarea)

8. Iterar para refinar el diseño de capas. 22.2.3. Componente de administración de tareas Coad y Yourdon sugieren la estrategia siguiente, para el diseño de objetos que manipulan tareas concurrentes:

• se determinan las características de la tarea. • se define un coordinador de tarea y objetos asociados. • se integra el coordinador y otras tareas.

Las siguientes etapas de diseño pueden aplicarse para especificar un contrato para un subsistema:

1. Listar cada petición que puede ser realizada por los colaboradores del subsistema. Organizar las peticiones por subsistema y definirlas dentro de uno o más contratos apropiados. Asegurarse de anotar contratos que se hereden de superclases.

2. Para cada contrato, anotar las operaciones (las heredadas y las privadas,) que se requieren para implementar las responsabilidades que implica el contrato. Asegurarse de asociar las operaciones con las clases específicas, que residen en el subsistema.

3. Considerar un contrato a la vez, crear una tabla con la forma de la figura 22.5 Para cada contrato, la tabla debe incluir las siguientes columnas:

• Tipo: el tipo de contrato (por ejemplo, cliente/servidor o punto-‐a-‐punto). • Colaboradores: los nombres de los subsistemas que son parte del contrato. • Clase: los nombres de las clases (contenidas en el subsistema), que

proporcionan servicios denotados por el contrato. • Operaciones: nombres de las operaciones (dentro de la clase), que

implementan los servicios. • Formato del mensaje: el formato del mensaje requerido para implementar la

interacción entre colaboradores.

4. Si los modos de interacción entre los subsistemas son complejos, debe crear un

diagrama subsistema-‐colaboración como el de la Figura 22.6. El grafo de colaboración es similar, en forma, al diagrama de flujo de sucesos examinado en el Capítulo 2 1. Cada subsistema se representa, junto con sus interacciones con otros subsistemas. Los contratos que se invocan durante interacción, se

detallan como se muestra en la Figura. Los detalles de la interacción se determinan observando el contrato en la tabla de colaboración del subsistema.

Incluir en el Resumen paginas 387-‐403 Estudiar

INGENIERfA DEL SOFTWARE. U N ENFOQUE PRACTICO

El objetivo de esta sección es mostrar el uso de diagramas UML, descrito en la Sección 22.25, aplicado a un sistema real. Este sistema es un sistema de comercio electrónico (e-commerce).

22.6.1. Libros-en-línea Libros-en-línea es una compañía creada reciente- mente, que es subsidiaria de otra gran compañía mul- tinacional de comercio, conocida como Pollday Publishing. Los directores de Pollday Publishing se decidieron a llevar a cabo un gran crecimiento en ventas por internet entre sus clientes, y decidieron pre- parar a Libros-en-Línea para ello. El concepto que Pollday tiene es el de un sitio Web de comercio elec- trónico, que tenga catálogos detallados de cada libro que manejan, junto con recursos con los que el usuario del sitio Web puede ordenar libros, utilizando una forma incluida en una página Web. A continuación, se muestran algunos extractos, tomados del conjun- to de requisitos iniciales, detallados por el equipo téc- nico de Libros-en-línea: 1.

2.

3.

4.

5.

Libros-en-línea desea desarrollar la capacidad de ventas en línea por medio de la Web. EL sitio web que implementa esta capacidad debe permitir al cliente examinar los detalles del libro, ordenarlo y registrar su dirección de correo electrónico para recibir ofertas especiales con detalles, publicaciones nue- vas y revisiones. Cuando un cliente accede al sitio Web, cada uno de los recursos antes descritos se despliegan. Si el cliente registra su dirección de correo electró- nico, se le preguntarán su información personal. Esto incluye su nombre, una dirección de correo electró- nico, una dirección postal. Un miembro del equipo conocido como el administrador de contratos será el responsable de enviar información de oferta, etc., a los clientes. El cliente podrá comprar libros del catálogo en línea, examinando las páginas con detalles de los libros y seleccionando el libro, que comprará mediante algún mecanismo como el de presionar un botón. El sistema deberá mantener un carrito de compras virtual, en el que los detalles de cada libro se almacenan. Conforme el carrito se va llenando de libros, se muestra al cliente el precio acumulado de todas sus compras. Cuando el cliente ha terminado de comprar en el sitio Web, se le pedirá información acerca de qué forma de envío se utilizará. Por omisión se mostrará la opción de envío por correo estándar, y un servicio de envío expreso garantizado para entregar dentro de 24 horas.

6. El sitio web deberá interactuar con un sistema de control de inventario, que también requiere desarrollo. Este sistema de control de inventarios debe mane- jar el proceso de recepción de libros de los inventarios de las editoriales, retiro de libros cuando se ordenan por parte de un cliente, y reordenación de existencia de un libro, cuando se encuentra por vaciarse, para encarar un problema de suministros, en un tiempo de siete días.

7. El control de inventarios por parte del administrador será fijado en un tiempo de siete semanas. Él o ella tendrán la responsabilidad de mantener las ventas, y la disponibilidad de existencias y, cuando las existencias de un libro se encuentren bajas, hacer un nuevo pedido. Para realizar esto, este sistema de control de inventarios debe proporcionar informes de ventas y existencias de inventario con regularidad.

8. Un Administrador de Marketting intervendrá cada ocho semanas. El Jefe de Marketting tendrá la fun- ción de determinar los precios a los que los libros serán vendidos. Se dará la situación de que un libro puede tener un número diferente de precios durante su tiempo de vida; por ejemplo, se debe decidir si se ofrece con un mayor descuento durante las primeras semanas, y luego ajustar el precio a los precios reco- mendados por las editoriales. La compañía que desarrolló el software para Libros-

en-línea, primero identificó un número de clases candidatas, que a continuación se detallan:

RegistroCliente. Detalles de alguien que compra libros, o que se registró para recibir correos electró- nicos con información. Libro. El artículo principal, qué Libros-en-línea vende. Orden. Una orden que un cliente realiza, para uno o más libros. Esta orden debe ser para una simple copia de un libro, o para copias de un número de libros o incluso múltiples copias de muchos libros. Una orden contendrá un número de líneas de orden (véase a continuación), y una especificación de envío. LíneaDeOrden. Esta es una simple línea de orden. Por ejemplo la orden de la copia de un libro. Una orden consistirá en una o más líneas de orden. Una línea de orden contendrá información acerca de qué libro se ordena y la cantidad ordenada (usual- mente 1) . Carrito. Es un contenedor que existe durante la exploración del sitio Web, por parte de un cliente que realiza una orden. Los contenidos del carrito serán líneas de orden. Cuando un cliente complete una orden, las líneas de orden del carrito y la informa- ción de envío proporcionada por el usuario serán ane- xadas a una orden.

398

CAPfTULO 22 DISENO ORIENTADO A OBJETOS

OrdenEspera. Esta es una parte de la orden, la cual no puede cumplirse por las existencias del almacén. Si el cliente está conforme, esperando por un libro que no está en existencia, entonces se realiza una orden de espera. Esta orden de espera se satisface, cuando las existencias del libro se restauran por Libros-en-línea. Almacén. Esta es una colección de libros que se encuentran en existencia. Una orden de libro o de colección de libros se manda al almacén y de ahí se retiran los libros de sus cajas del almacén, se empaquetan y se despachan al cliente. En ese momento, se ajustan los detalles de las existencias. RegistroExistencias. Estos son los datos que des- criben los detalles de las existencias de un libro; por ejemplo, cuántos hay en existencia, el nivel actual cuando se ha hecho una requisición a las editoriales, y la localización de los libros dentro del almacén. NotaEmpaque. Esta es una nota enviada con una colección de libros al cliente. La nota de empaque contiene información acerca de cuántos libros se enviaron y la tarifa de envío aplicada. También puede contener detalles de algunos libros, que no pudieron ser enviados porque no se encontraban en las existencias. Tarjetacrédito. Un cliente pagará por sus libros mediante una tarjeta de crédito. El sistema permite al cliente pre-registrar su o sus tarjetas, para que no tenga que reescribirlas cada vez que haga una orden.

Registro

/ / ’/ Q------- Comprobar pedido A \

Borrar tarjeta de crédito

Registrar tarjeta de crédito

FIGURA 22.25. Algunos casos de uso para el actor Cliente.

Estas fueron, entonces, las clases identificadas princi- palmente. También se identificaron un número de actores:

Cliente. Este es el actor principal: la persona que lleva a cabo las acciones, que resultan en los mayores cambios de estado del sistema. Administrador de marketting. Es un actor importante que ajusta muchos de los parámetros del sistema, tales como el precio de los libros. Administrador del control de inventarios. Alguien que controla los inventarios en un almacén y toma decisiones acerca de las órdenes. Existen un gran número de casos de uso asociados

con estas acciones, muchas de ellas asociados con el actor cliente, se muestran en la Figura 22.25.

La selección de casos de uso asociados con el Cliente, y las mostradas en la Figura 22.25 incluyen casos de uso para:

Registro. Aquí el cliente proporciona su nombre y su clave. Una vez registrada, pueden examinar el catálogo de libros. Ordenar. Aquí el cliente ordena una o más copias de un libro. Realizar. El cliente completa la orden y ordena al sistema iniciar el proceso en que la orden se despacha. Buscar un libro. El cliente busca, en el catálogo en línea, un libro específico. Eliminar tarjeta de crédito. Aquí el cliente puede eliminar una o más de las tarjetas de crédito registra- das y asociadas con él. Registrar tarjeta de crédito. Aquí el cliente registra una o más de sus tarjetas de crédito al sistema. Una porción de uno de estos diagramas de clase para

el sistema, se muestra en la Figura 22.26. Un número de roles asociados con el diagrama se ha omitido; regu- larmente se incluyen. Algunas de las relaciones entre clase, también se omitieron.

El diagrama muestra muchas de estas clases antes descritas. Las únicas clases que se omitieron son: Ordensatisfecha y OrdenEspera. Estas dos clases son especializaciones de la clase Orden, que representa una orden de libros para un cliente.

DeQrden

FIGURA 22.26. Una sección de un diagrama de clases para el caso de estudio.

399

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

Cuando se hace un pedido, algunos de los artículos pedidos pudieron no haberse servido, porque los libros no estaban en existencia. Cuando esto ocurre, la orden se divide en dos: todos los libros que pueden propor- cionarse en un objeto Ordensatisfecha, y aquellos que no pudieron encontrarse, se registran en un objeto Orden- Espera. Las relaciones en el diagrama de clases se detallan a continuación.

Un almacén se asocia con un número de registros de existencias, los cuales detallan los libros almacena- dos en el almacén. Un simple almacén se asocia con uno o más registros de existencia. Un registro de existencia se asocia con un solo libro, y un libro se asocia con un solo registro de existencia. Una orden puede consistir en un número de líneas de orden, y una línea de orden será asociada con una sola orden. Un cliente registrará su número de tarjeta de crédito al sistema, un número de tarjeta de crédito se asocia con un solo cliente. Un cliente se asocia con un número de órdenes satisfechas, las cuales se realizan sobre un período de tiempo. Cada orden satisfecha se asocia con un solo cliente. Un cliente se asocia con un número de órdenes en espera, que actualmente no pueden ser satisfechas. Cada orden en espera se asocia con un solo cliente. La Figura 22.26 muestra solo algunas de las rela- - -

cienes involucradas, por ejemplo, existe una relación

entre tarjetas de crédito y órdenes, en virtud de que una tarjeta de crédito particular se utiliza para pagar una orden. De cualquier manera, se muestra suficiente detalle para proporcionar una indicación de qué tan com- plicado se ve un diagrama de clases UML.

Un ejemplo de diagrama de secuencias asociado con el caso en estudio se muestra en la Figura 22.27.

Aquí el cliente ordena un libro. Esto resulta en el registro de existencias para el libro consultado, y se ajusta si el libro está en existencia. Si el libro está en existencia, un objeto de tipo línea de orden se crea, el cual se anexa a una orden, la cual se construye conforme el cliente navega por el sitio web de Libros-en-línea. El diagrama final (Fig. 22.28) muestra un diagrama de estado para el objeto Orden.

Un cliente primero realiza la orden, y el estado del objeto Orden se vuelve orden parcial; entonces se da al cliente la opción de añadir más libros o de eliminar libros de su orden. En cualquier momento de la construcción de la orden, el cliente puede cancelar la orden, esto conduce a la terminación. Cuando el cliente indica que se ha llegado al fin de la orden, entonces la orden se vuelve una orden de libros completa. En este punto, el cliente tiene dos opciones: cancelar al orden o especificar el tipo de envío que se usará para la orden. Si se seleccio- na el tipo de envío, entonces la orden se convierte en una orden completa. En esta etapa, el cliente tiene otras dos opciones: confirmar la orden, en este caso la orden se envía para ser procesada, o cancelar la orden. Ambas opciones conducen al punto de salida del diagrama de estados.

TOS

La etapa final de desarrollo, dentro del ciclo de vida orientada a objetos, es la programación. No es la intención de este libro llegar a más detalle acerca de este proceso; la programación es analizada como importante pero como actividad subsidiaria al análi- sis y diseño; pero se proporciona una pequeña intro- ducción en el lenguaje de programación Java. La sección otras lecturas y fuentes de información al final del capítulo detalla un gran número de buenos libros sobre el tema.

El proceso de programación involucra la conversión de un diseño orientado a objetos en un código de programa. Efectivamente, esto significa que las clases definidas en el diseño deben ser convertidas en clases expresadas en un lenguaje de programación orientado a objetos como Java, C++ o SmallTalk. Esta sección se concentra en Java, que se está volviendo rápidamente el lenguaje de programación de facto, para desarrollar los modernos sistemas distribuidos.

Una clase en Java se introduce por medio de la pala- bra clave class, dentro del código para la clase; el pro- gramador define los atributos y operaciones para la clase.

Un ejemplo del código esqueleto de una clase se muestra a continuación.

clacc Cliente { priva te String NombreCl i en t e; priva te String DireccionCl i en t e; // se definen más atributos aquí public String obtenerNombreCliente/ ) i //código para obtenerNombreCliente 1 public void modificarDireccionCliente ( String di recci on j i //código para modificarDireccionCliente 1

//código para las operaciones restantes 1

La primera línea de código define que el nombre de la clase será Cliente. Inmediatamente a continuación, las descripciones de atributos de clase. En el código anterior, solo se muestran dos atributos: el nombre del

400

Guia de Estudio de Ingenieria del Software IIfiles.rfernandez.webnode.es/200000012-5265353606/Guia...

Documents

Transcript of Guia de Estudio de Ingenieria del Software IIfiles.rfernandez.webnode.es/200000012-5265353606/Guia...