4

CAPITULO II

MODELADO DE DOMINIO

2.1 REQUISITOS

En ICONIX un requisito se distingue claramente de un caso de uso (Silva

y Videira, 2001). Porque, un caso de uso describe un comportamiento (la

interaccin hombre - maquina) y, un requisito describe una regla para el

comportamiento. Adems, un caso de uso satisface uno o ms requisitos

funcionales y, un requisito funcional puede ser satisfecho por uno o ms casos

de uso.

2.1.1 REQUISITOS FUNCIONALES

Al comenzar un proyecto de software, una persona o un equipo de

analistas del negocio, hablar con el cliente, los usuarios finales y otros, y esa

persona o el equipo, crear un paquete con documentos de los requisitos

funcionales. Es un documento importante, pero es difcil crear un diseo desde

la lista de requisitos funcionales, porque no esta estructurado.

2.1.2 MEJORES PRACTICAS PARA RECOLECTAR REQUISITOS

a. Usar una herramienta para modelar, que soporte enlace y trazabilidad

entre requisitos y casos de uso.

b. Vincular los requisitos a los casos de uso.

c. Evitar requisitos disfuncionales, separar detalles funcionales de la

especificacin de comportamiento.

d. Escribir por lo menos un caso de prueba para cada requisito.

e. Distinguir entre diferentes tipos de requisitos.

f. Evitar el sndrome de "gran documento rgido.

g. Estimar escenarios para los casos de uso, no de los requisitos funcionales.

h. No hacer de los requisitos una declaracin tcnica de moda.

5

2.2 MODELADO DE DOMINIO INICIAL

Es la tarea de descubrir objetos (clases), que representan cosas y

conceptos del mundo real. Segn ICONIX, el modelado de dominio inicial

abarca palabras externas de los requisitos, para construir el modelo esttico

(Rosenberg, et al., 2005).

Figura N 2.1: Modelado de dominio inicial.

2.2.1 DEFINICION DEL MODELO DE DOMINIO

El modelo de dominio es un artefacto colaborativo vivo. Es refinado y

actualizado en cada fase del proyecto, de modo que refleja siempre la

comprensin actual del dominio del problema. El modelo de dominio sirve

como un glosario de trminos, que puede ser utilizado en la primera fase para

escribir los casos de uso (Borrillo, 2004).

Un modelo de dominio es un glosario del proyecto: un diccionario de todos los

trminos usados en el proyecto (lista de requisitos funcionales). El modelo de

dominio es mejor que el glosario del proyecto, porque muestra grficamente

cmo los trminos se relacionan entre s. En la prctica es un diagrama de

clases simplificado, con lneas dibujadas entre las diferentes clases (objetos de

dominio) para mostrar cmo se relacionan entre s. El modelo de dominio

6

muestra las relaciones de generalizacin(es un,) agregacin (tiene un) y

asociacin entre las clases de dominio.

2.2.2 PRACTICAS PARA CONSTRUIR EL MODELO DE DOMINIO

a. Enfocarse en objetos del mundo real (dominio del problema).

b. Usar las relaciones de generalizacin (es-un), agregacin (tiene-un) y,

asociacin entre clases, para mostrar cmo los objetos se relacionan

entre s.

c. Limitar su esfuerzo para el modelado de dominio inicial a dos horas.

d. Organizar sus clases alrededor de abstracciones claves en el dominio

del problema.

e. No confundir el modelo de dominio con un modelo de datos.

f. No confundir un objeto, que representa una instancia de una clase, con

una tabla de la base de datos, que tiene coleccin de tuplas.

g. Usar el modelo de dominio como un glosario del proyecto (grfico).

h. Hacer el modelo de dominio inicial antes de escribir sus casos de uso,

para evitar ambigedad de nombres (sustantivos).

i. No espere que su diagrama de clases final coincida con su modelo de

dominio, debe existir cierto parecido entre ellos.

j. No poner pantallas y otras clases en su modelo de dominio.

2.2.3 ERRORES FRECUENTES DEL MODELADO DE DOMINIO

Estos se listan de acuerdo a (Rosenberg, et al., 2005) y son:

a. Asignar multiplicidad a las asociaciones al inicio del modelado.

b. Analizar verbo y sustantivo exhaustivamente.

c. Asignar operaciones a las clases sin explorar los casos de uso y

diagramas de secuencia.

d. Perfeccionar cdigo para reuso, sin satisfacer los requisitos.

e. Debatir uso de agregacin o composicin en cada asociacin.

f. Presumir una estrategia de implementacin especfica en esta fase.

g. Usar nombres difciles de entender para las clases.

h. Hacer la implementacin.

i. Crear un esquema uno-a-uno entre las clases del modelo de dominio

7

y las tablas de la base de datos.

j. Utilizar patrones de diseo de forma prematura.

El objetivo del modelo de dominio, es hacer un primer levantamiento de las

entidades que forman parte del problema. Los errores indicados pretenden

prevenirlo para evitar la bsqueda de detalles.

2.2.4 PRACTICA DEL MODELADO DE DOMINIO

Aplicamos la metodologa ICONIX, al caso comercializacin de la tara y

sus derivados en la Regin Ayacucho. Definimos una cadena productiva

como un sistema formado por la interaccin de la produccin, acopio,

transformacin y consumo, operados por los actores directos e indirectos y la

necesidad de informacin para los actores.

Figura N 2.2: Flujo de la cadena productiva de tara. (Avendao, et al., 2007)

8

LA TARA Y SUS DERIVADOS

La vaina de tara proporciona derivados con potencial industrial, alimenticio y

mdico, para producir hidrocoloides, taninos y cido glico, entre otros. La

vaina esta compuesta por semilla y cscara, esta presenta mayor

concentracin de taninos, usado en la industria. El cido glico derivado del

tanino es usado como: antioxidante para aceites, decolorante en la industria

de cervecera, en fotografa, tintes, fbrica del papel, litografa. El fruto es

usado para: producir aceite, helados, harina proteica. Existen otros derivados

de la semilla para producir: jabones, pinturas, barnices, esmaltes, tintes de

imprenta, mantecas y margarinas comestibles, por su bajo contenido de cido

oleico (1.4%). El uso mdico en: gastroenterologa, lceras, cicatrizantes,

antinflamatorios, antispticos, antidiarreicos, antimicticos, antibacterianos,

antiescorbticos, odontolgicos. (De la Cruz, 2004)

Vaina de Tara Semilla de Tara Hojuela Tara Goma de Tara

Figura N 2.3: La tara y sus derivados. (De la Cruz, 2004)

CARACTERSTICAS FSICAS Y QUMICAS DE LA TARA Y SUS DERIVADOS

La tabla 2.1, muestra las caractersticas fsicas y qumicas de la tara y sus

derivados, indicando la composicin en porcentaje.

Caracterstica Fruto (vaina y semilla) (%) Semilla

(%) Goma

(%) Germen

(%) Cscara

(%) Humedad 11.70 12.01 13.76 11.91 10.44 Protenas 7.17 19.62 2.50 40.22 1.98 Cenizas 6.24 3.00 0.53 8.25 3.05 Fibra bruta 5.30 4.00 0.86 1.05 1.05 Estracto etreo 2.01 5.20 0.48 12.91 0.97 Carbohidratos 67.58 56.17 81.87 25.66 83.56 Taninos 62.00 -.- -.- -.- -.- Azucares -.- -.- 83.20 -.- -.-

Tabla N 2.1: Caractersticas de la tara y sus derivados. (De la Cruz, 2004)

9

Humedad.- Humedad del fruto o derivados a una temperatura y presin.

Protena.- Segn el mtodo Kjeldhal, utilizando como catalizador selenio, con

factor de conversin de protenas 6.25.

Extracto etreo.- Segn el mtodo Boxhlet, con tiempo de extraccin 6 horas.

Cenizas.- Determinando por el mtodo de incineracin a la temperatura de

550 C, durante 6 horas.

Fibras brutas.- Residuo orgnico lavado y seco que queda despus de hervir

sucesivamente el material con H2SO4 y NaOH y, convertirlo en ceniza.

Carbohidratos.- Determinado por diferencia de los anlisis de humedad,

protena, cenizas, fibra bruta y extracto etreo.

Azcares totales.- Segn el mtodo volumtrico de Lane Eynon y Fehling, a fin

de reducir todo el in cprico o cuproso.

Fibra diettica.- La muestra es gelatinizada y digestada enzimticamente con

proteasa y amiglucosidasa para remover la protena y el almidn.

A continuacin mostramos los entregables del modelado de dominio.

N Req. Requisitos FUNCIONALES

01 El administrador debe ser capaz de crear una cuenta para un usuario, previa solicitud de acceso

02 El software debe ser capaz de proveer la actualizacin de las caractersticas de la tara y sus derivados 03 El productor debe ser capaz de publicar su oferta para la venta de tara 04 El productor puede registrar una boleta, factura por la venta de tara

05 El productor debe ser capaz de realizar una proforma ante la cotizacin de un acopiador o transformador para la venta de tara

06 El productor debe ser capaz de realizar una cotizacin de bien o servicio a un proveedor (actor indirecto) para comercializar tara 07 El acopiador debe ser capaz de publicar su oferta para la venta de tara

08 El acopiador podr registrar una boleta, factura o contrato por la venta de tara

09 El acopiador podr ser capaz de emitir una proforma ante la cotizacin de un transformador u otro acopiador para la venta de tara

10 El acopiador puede realizar una cotizacin de bien o servicio a un proveedor para comercializar tara

11 El acopiador puede realizar una cotizacin de tara al productor para la compra

12 El transformador debe ser capaz de publicar su oferta para la venta de tara y su derivados

13 El transformador podr registrar una boleta, factura o contrato por la venta de tara y sus derivados

14 El transformador podr emitir una proforma ante la cotizacin de un cliente para la venta de tara y sus derivados

10

15 El transformador ser capaz de realizar una cotizacin de bien o servicio para comercializar tara

16 El transformador puede realizar una cotizacin de tara y sus derivados al acopiador o productor para la compra

17 El cliente puede ser capaz de realizar una cotizacin de tara y sus derivados al transformador

18 El software debe ser capaz de proveer la actualizacin de las caractersticas de un bien o servicio

19 El proveedor de bien o servicio debe ser capaz de publicar su oferta de un bien o servicio

20 El proveedor de bien o servicio puede realizar una proforma ante la cotizacin de un cliente (actor directo) para la venta de bien o servicio

21 El proveedor de bien o servicio (actor indirecto) debe ser capaz de registrar una boleta o factura por la venta de un bien o servicio para comercializar tara

22 El software debe ser capaz de mostrar la matriz de competencia para la tara y su derivados de la regin

23 El software debe ser capaz de mostrar la demanda y los mercados para la tara y sus derivados

24 El software debe ser capaz de mostrar la matriz histrica de precios para la tara y sus derivados NO FUNCIONALES

25 El software para comercializar tara debe ser una aplicacin web y contar con ayudas para recordar la clave de acceso.

26 El software debe tener las ayudas necesarias para su aprendizaje y correcta operacin.

27 El software debe ser capaz de ejecutarse en cualquier sistema operativo garantizando su portabilidad 28 El software debe presentar interfaces fciles de utilizar

29 El software debe ser personalizable para garantizar el cumplimiento del rol de un actor

30 El software debe presentar una arquitectura tcnica y codificacin usando estndares que permita su operacin y mantenimiento adecuado

Tabla N 2.2: Requisitos funcionales y no funcionales.

N Req. N C.P Casos de Prueba de Aceptacin

05 09 14

01 Comprobar que los datos del actor (persona natural o jurdica) proveedor del producto tara son correctos.

02 Comprobar que la cotizacin, es de un actor (transformador, acopiador y cliente) y presenta informacin correcta sobre la fecha de vigencia, descripcin, unidad, cantidad.

03 Comprobar que el producto tara, provee un actor (productor, transformador y acopiador) y presenta cdigo, descripcin y caractersticas correctas.

04 Verificar que la cantidad, el precio unitario, descuento, subtotal y total para un tem son correctos.

05 Imprimir la proforma de productos tara y verificar que los datos se grabaron correctamente.

Tabla N 2.3: Caso de prueba de aceptacin. Emitir proforma producto

11

GLOSARIO DE TRMINOS

Administrador Derivado Proforma Mercado Cuenta Venta Demanda Acopiador Usuario Transformador Productor Cotizacin Solicitud Cliente Oferta Bien Caracterstica Actor directo Servicio Boleta Tara Competencia Actor indirecto Factura

Figura N 2.4: Modelo de dominio. Software comercializacin de tara

class Objetos Modelo de Dominio

BienServicio

Documento comercializacin

ProformaCotizacin Oferta

Persona

Cuenta usuario

Administrador

Comprobante pago

Boleta

Factura

Producto

Natural Jurdica

Solicitud

Acopiador

Actor

Actor directo Actor indirecto

ClienteProductor Proveedor bienTransformador Proveedor servicio

Mercado

Regin

Demanda

Producto

Competencia

precisa

compra/vendebien

compra/vendeproducto

es una

compra/vendeservicio

necesita

lee

creauna

tiene

tiene una

requiere