Por lo datos del enunciado, se observa que cada Producto tiene su impuesto propio, por lo que no es necesario crear una clase para que solo tenga el valor del porcentaje. Podría tenerse una clase si muchos productos dependiesen de un porcentaje que pueda variar, y al modificarse se modificaría en todos, pero el enunciado no lo dice.

Lo que sí diferencia a los objetos son los tipos de recargos que pueden tener (ser suntuario, tener sustituto local, o en el futuro agregarse un nuevo recargo).

Una solución alternativa es que cada producto tenga una lista de recargos, y que cada recargo sepa cómo calcular ese valor extra. Cada clase Recargo tendría sus atributos que pueden modificarse sin necesidad de tocar el código ya que pueden modificarse en tiempo de ejecución.

En la solución mencionada se utilizó el Patrón Decorator.
Por ejemplo, si tengo un TV80 que es suntuario y además

ProductoConcreto tv80 = new ProductoConcreto
ProductoConImpuesto pci = new ProductoConImpuesto
ProductoSuntuario ps = new ProductoSuntuario

Seteamos los productos para ir agregando los impuestos.
pci.producto(tv80)
ps.producto(pci)

Para calcular el precio de venta:
ps.precioVenta()

Lo que es igual a
pci.precioVenta() * impuesto = //Supongamos 0.05 el impuesto
= (tv80.precio(venta) * 0.05) * 3000 =
= ((2 * costo)) * 0.05) * 3000. //Supongamos el costo de la TV 6000
= (2 * 6000)) * 0.05) * 3000)
= 1.800.000

Como se ve el valor calculado no tiene coherencia y esto se debe a:

• Hay un error en cómo se calcula el precio de venta para el producto concreto ya que lo realiza mediante “2 * costo” y el enunciado dice el 100% del costo.

• Hay un error en el método “precioVenta()” de la clase Abstracta “ProductoConRecargo” (precio de venta * el impuesto). Si bien en el caso de Producto con impuesto se calcula bien, para el caso de suntuario lo tendría que sumar (ejemplo: 10000 + 3000, y no 10000 * 3000).

Además de calcular mal el precio de venta, es difícil agregar y quitar impuestos una vez que se creó el producto, ya que es necesario saber cuál es el producto que lo tiene como atributo y si este a su vez es atributo de otro recargo.

En la nueva solución, el precio de venta lo calcula el Producto teniendo en cuenta el costo, el impuesto y los recargos que tiene. De esta manera si se crea un nuevo recargo, solamente es necesario crear la clase.
Se pueden quitar o agregar recargos existentes a un producto de forma dinámica simplemente con agregarlos o quitarlos de su lista de recargos.

En cuanto a la cohesión del objeto Producto, aumenta ya que tiene bien definida la responsabilidad de calcular el precio de venta, cuando antes se calculaba separadamente por distintas clases.

Sobre exenciones impositivas no queda claro si se descontaría del precio de venta o si infiere en el costo del mismo. Supongo que es un recargo más.

 class Producto 

{

	var String nombre;

	var double impuesto;

	var double costo;

	var List<Recargo> recargos = newArrayList;

	

	new (String unNombre, double unCosto, double unImpuesto)

	{

		this.nombre   = unNombre;

		this.costo    = unCosto;

		this.impuesto = unImpuesto;				

	}

	

	def double precioVenta()

	{

		return (this.costo + this.calcularImpuesto() + this.calcularRecargos())

	}

	

	def double calcularImpuesto()

	{

		return this.costo * impuesto;

	}

	

	def double calcularRecargos()

	{

		return this.recargos.map[obj | obj.calcularRecargo(this)].reduce[sum, obj | sum + obj];

	}



}



interface Recargo

{	

	def double calcularRecargo(Producto unProducto)

}





class Suntuario implements Recargo

{

	var int valorExtra;

	

	new (int unValorExtra)

	{

		this.valorExtra = unValorExtra;

	}

	

	override double calcularRecargo(Producto unProducto) 

	{

		return valorExtra;

	}	

}



class SustitutoNacional implements Recargo

{

	var double porMin; //Porcentaje Mínimo

	var double porMax; //Porcentaje Máximo

	var int    valor;

	

	new (int unValor, double unPorMin, double unPorMax)

	{

		this.valor = unValor;

		this.porMax = unPorMax;

		this.porMin = unPorMin;

	}

	

	override double calcularRecargo(Producto unProducto) 

	{

		if (unProducto.costo > valor) 

		{

			return unProducto.costo * this.porMax;

		}



		return unProducto.costo * this.porMin;

	}	

}



class MainClass 

{

	def public static void main(String[] args)	

	{

		var Producto producto = new Producto("Auto",30000,0.5);

		var Suntuario suntuario = new Suntuario(3000);

		var SustitutoNacional susNac = new SustitutoNacional(10000,0.05,0.10);

		

		producto.recargos.add(suntuario);

		producto.recargos.add(susNac);

		

		println(producto.precioVenta()); 

		//Imprime 51000 (30000 + 15000 + 3000 + 3000)

	}

}

En cuanto a la persistencia, es más fácil guardar información de un producto y sus recargos si este los tiene en una lista, en vez de que cada recargo conozca solamente a otro recargo o finalmente a otro producto.

Ejemplo:
Recargo2 -> Recargo1 -> Producto

Mi solución:
Producto: [Recargo1, Recargo2]

Y en cuanto a la interfaz del usuario, el manejo de eventos y binding de datos es más fácil ya que los realiza directamente el producto, por ejemplo, para el cálculo del precio de venta es quién tiene la responsabilidad de calcularlo. En la solución del enunciado es necesario conocer el último recargo para poder calcular el precio de venta de un producto en particular, lo que hace más difícil manejar este evento.
Otro evento como podría ser el de agregar o quitar recargos, se maneja de forma más fácil ya que es solo agregar o quitarlo de la lista del objeto Producto. En la propuesta del enunciado es necesario modificar los atributos de los recargos.

Si se utiliza una metodología Ágil, se tiene una metodología:
*Orientada al producto: un producto funcionando es más importante que la documentación exhaustiva
*Orientadas a las personas: las personas y como se relacionan son más importantes que los procesos.
*Iterativa: se divide el proyecto en entregas o iteraciones en las cuales se define un entregable (software testeable por el usuario).
*Adaptativa: se acepta el cambio y error como parte natural del desarrollo.

El cliente forma parte del equipo de trabajo con quién se negocia. Se definen entre todos cuando una tarea está terminada.

En una metodología ágil, con Scrum entre las actividades que se realizan:
Reuniones diarias: no duran más de 15 minutos, se establecen las tareas para las próximas 24 horas y se revisan las tareas desde la última reunión .
Sprint: es el periodo (2-3 semanas) en el que se definen las tareas a llevar a cabo. Al final de este tiempo el equipo se reúne y evalúan las actividades desarrolladas y el resultado es un entregable para el cliente.

Si se utiliza Proceso Unificado, se tiene una metodología:
*Iterativo: e incremental, se divide el trabajo en partes más pequeñas que son iteraciones. Cada iteración amplía el producto.
*Adaptativa: se contempla la posibilidad de modificar los requerimientos hasta la última iteración.
*Persona/Proceso: no está bien definido ya que por un parte considera a las personas importantes y que deben saber qué hacer, pero por otro lado dice que las personas responden a un rol el cual les indica un proceso al cuál seguir.
*Producto/Documentación: se encuentra en la mitad ya que considera que el producto no es solo el software sino también es la documentación: casos de usos, diagrama de clases, diagramas de colaboración, etc.

Cuenta con 4 fases (inicio, elaboración, construcción e implementación) en las que se desarrollan tareas (requerimientos, análisis, diseño, test, configuración, etc) en mayor o menor tarea dependiendo de la fase en la que esté.

Entre las tareas del UP podemos ver en la captura de requerimientos en el cual se realizan casos de usos, actores, reglas de negocios, etc.