¡Descarga Práctica 4: Herencia y polimorfismo en Programación Orientada a Objetos - Prof. Gracía y más Apuntes en PDF de Ingeniería del Software solo en Docsity!
Programación Orientada a Objetos
Práctica 4: Herencia y polimorfismo
Implementación del caso de uso 4
«Gestión del catálogo de artículos» del S. G. L.
Curso 2014–
Índice
**1. Introducción 2
- Objetivos 2
- Descripción de los requisitos del caso de uso 4 2
- Diagrama de clases del caso de uso 4 2
- Implementación de las clases 3**
5.1. La clase Articulo.................................. 3 5.2. La clase ArticuloAlmacenable........................... 4 5.3. La clase Libro.................................... 4 5.4. La clase Cederron.................................. 4 5.5. La clase LibroDigital................................ 4 5.6. La clase Autor.................................... 5
6. El Makefile 5
Rev: 255, 25 de mayo de 2015 1 Enunciado-CasoUso-4.tex
1. Introducción
En esta práctica se va a llevar a cabo la implementación y prueba del caso de uso 4 «Gestión del catálogo de artículos» del Sistema de Gestión de Librería (SGL) descrito de manera general en la sección de prácticas del campus virtual de la asignatura.
Se partirá de la solución del caso de uso 3, desarrollada en la práctica anterior, junto con los requisitos correspondientes al caso de uso 4, y a partir de su diagrama de clases se realizará su implementación en el lenguaje de programación C++. Después se deberá realizar una serie de pruebas para asegurarse de que la aplicación, para el caso de uso 4, funciona correctamente y satisface los requisitos especificados.
2. Objetivos
Implementar en C++ el modelo de clases para el caso de uso 4 del SGL cumpliendo los princi- pios de la programación orientada a objetos y todas las pruebas necesarias para que estemos seguros en un alto grado de que la implementación tiene el comportamiento esperado.
3. Descripción de los requisitos del caso de uso 4
Continuaremos el desarrollo de nuestro SGL completando la gestión del catálogo de artículos, partiendo de la gestión de pedidos. Para esto es necesario incorporar al sistema los distintos tipos de artículos que van a formar parte del catálogo.
Se podrán añadir al catálogo tres tipos de artículos: libros, cederrones y libros digitales ( ebooks ). Todos ellos tienen un código de referencia interno (una cadena), un precio, un título y una fecha de publicación, pero solo de los libros y cederrones hay que almacenar el stock (número de artículos disponibles), ya que los libros digitales se distribuyen mediante descarga por Internet. De todos los artículos también se guardan los autores, que pueden ser uno o varios. Los libros digitales tienen además una fecha de expiración en la que dejan de venderse, ya que se consideran obsoletos. De los libros se almacena el número de páginas, y de los cederrones el tamaño en MB.
4. Diagrama de clases del caso de uso 4
En la figura 1 aparece el diagrama de clases asociado con el caso de uso 4. Se trata de una especialización de la clase Articulo.
[035] "Horarios", de Poyáquez. 2.009. 9,00 € A la venta hasta el miércoles 19 de junio de 2019.
Observe que esta modificación posiblemente afectará al formato de salida de la función mos- trar_carro , que imprime el contenido del carrito de un usuario en un flujo de salida. Reescriba esta función, de forma que no dependa del operador de inserción de Articulo , para conservar el formato de salida original.
5.2. La clase ArticuloAlmacenable
Esta clase será también abstracta, de forma que tampoco se podránn crear objetos de ella.
Esta clase representa a todos aquellos artículos que se puedan almacenar. Esto es, aquellos para los que hay que guardar un stock (existencias, número de artículos disponibles). Las existencias se podrán consultar y modificar a través de los métodos stock.
5.3. La clase Libro
Esta es una clase almacenable, o sea, que posee un stock , y además hay que guardar el número de páginas, que se podrá consultar a través del observador n_pag y no se podrá cambiar tras crear el objeto.
5.4. La clase Cederron
Esta clase también es almacenable (tiene stock ), y además hay que guardar el tamaño en MB (observador tam ). El tamaño no se puede cambiar una vez se ha creado el objeto.
5.5. La clase LibroDigital
Para esta clase no hay que almacenar las existencias, pero hay que tener en cuenta la fecha de expiración (observador f_expir ) en la cual los ebooks dejan de venderse. La fecha de expiración no puede cambiar una vez se ha creado el objeto.
Por tanto, no se podrán comprar libros digitales cuya fecha de expiración sea anterior a la actual. Este requisito hace necesario modificar el constructor de la clase Pedido : si un usuario ha introducido en su carrito de compra un libro digital expirado, al contrario que ocurre con los artículos almacenables sin existencias, el pedido no se anulará, simplemente el ebook no se añadirá al pedido. Si el pedido queda vacío por este motivo, debe lanzar la excepción Pedido::Vacio correspondiente.
5.6. La clase Autor
Deberá crear la clase Autor para guardar los datos de los autores (nombre, apellidos y di- rección). El constructor no lanzará ninguna excepción. Definirá públicamente en Articulo un sinónimo Autores con el tipo necesario para representar la relación.
Esta clase se ha omitido en el diagrama de la figura 1, ya que el estudiante deberá decidir cómo se relaciona esta con las otras clases. Nótese que en lo único en que estamos intere- sados es en saber cuáles son los autores de un artículo dado. Todo artículo tendrá al menos uno; de no ser así, se lanzará la excepción Autores_vacios. Dicha información (los autores) será proporcionada cuando se cree el artículo, sea del tipo que sea, y no se podrá cambiar posteriormente.
6. El Makefile
Se proporciona el fichero Makefile , donde deberá, como en prácticas anteriores, modificar la variable NOMBREALUMNO.
En resumen, la estructura de directorios sería:
Povedilla_Putierrez_Pancracio/P1/Cadena/cadena.{h,cpp} | | |Makefile | /Fecha/fecha.{h,cpp} | |Makefile /P2/luhn.cpp |-- fct.h /P4/test-caso[0134]-*.cpp |test-auto.{cpp,h} |usuario.{h,cpp} |usuario-pedido.h |tarjeta.{h,cpp} |articulo.{h,cpp} |pedido.{h,cpp} |pedido-articulo.{h,cpp} |Makefile
No están autor.cpp ni usuario-pedido.cpp porque se pueden hacer todas las funciones correspondientes inline , poniéndose entonces en las cabeceras, pero se es libre de implemen- tarlas en esos cpp que faltan, debiendo en ese caso modificar el Makefile para añadirlos a la variable COMM_SRCS.
