02 clase IS445 semana 2.pdf

SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA

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 interacción

hombre - máquina) y, un requisito describe una regla para el comportamiento. Además,

un caso de uso satisface uno o más requisitos funcionales y, un requisito funcional

puede ser satisfecho por uno o más 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 difícil crear un diseño desde la lista de requisitos funcionales,

porque no está 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 especificación

de comportamiento.

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

e. Distinguir entre diferentes tipos de requisitos.

f. Evitar el síndrome de "gran documento rígido”.

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

h. No hacer de los requisitos una declaración técnica de moda.

2.2 MODELADO DE DOMINIO INICIAL

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

“mundo real”. Según ICONIX, el modelado de dominio inicial abarca palabras externas

Modelado de Dominio MSc. Ing. Efraín Elías Porras Flores

SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA de los requisitos, para construir el modelo estático (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 comprensión

actual del dominio del problema. El modelo de dominio sirve como un glosario de

términos, 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

términos usados en el proyecto (lista de requisitos funcionales). El modelo de dominio

es mejor que el glosario del proyecto, porque muestra gráficamente cómo los términos

se relacionan entre sí. En la práctica es un diagrama de clases simplificado, con líneas

dibujadas entre las diferentes clases (objetos de dominio) para mostrar cómo se

relacionan entre sí. El modelo de dominio muestra las relaciones de generalización(es

un,) agregación (tiene un) y asociación entre las clases de dominio.


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA 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 generalización (es-un), agregación (tiene-un) y, asociación

entre clases, para mostrar cómo 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 colección de tuplas.

g. Usar el modelo de dominio como un glosario del proyecto (gráfico).

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

evitar ambigüedad 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 código para reuso, sin satisfacer los requisitos.

e. Debatir uso de agregación o composición en cada asociación.

f. Presumir una estrategia de implementación específica en esta fase.

g. Usar nombres difíciles de entender para las clases.

h. Hacer la implementación.

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

tablas de la base de datos.

j. Utilizar patrones de diseño de forma prematura.


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA 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 búsqueda de detalles.

2.2.4 PRIMERA PRÁCTICA DEL MODELADO DE DOMINIO

Aplicamos la metodología ICONIX, al caso comercialización de la tara y sus

derivados en la Región Ayacucho. Definimos una cadena productiva como un sistema

formado por la interacción de la producción, acopio, transformación y consumo,

operados por los actores directos e indirectos y la necesidad de información para los

actores.

Figura Nº 2.2: Flujo de la cadena productiva de tara. (Avendaño, et al., 2007)


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA LA TARA Y SUS DERIVADOS

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

para producir hidrocoloides, taninos y ácido gálico, entre otros. La vaina está

compuesta por semilla y cáscara, esta presenta mayor concentración de taninos, usado

en la industria. El ácido gálico derivado del tanino es usado como: antioxidante para

aceites, decolorante en la industria de cervecera, en fotografía, tintes, fábrica del papel,

litografía. 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 médico en: gastroenterología, úlceras, cicatrizantes, antinflamatorios,

antisépticos, antidiarreicos, antimicóticos, antibacterianos, antiescorbúticos,

odontológicos. (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)

CARACTERÍSTICAS FÍSICAS Y QUÍMICAS DE LA TARA Y SUS DERIVADOS

La tabla 2.1, muestra las características físicas y químicas de la tara y sus derivados,

indicando la composición en porcentaje.

Característica Fruto (vaina y semilla) (%)

Semilla (%)

Goma (%)

Germen (%)

Cáscara (%)

Humedad 11.70 12.01 13.76 11.91 10.44 Proteínas 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 etéreo 2.01 5.20 0.48 12.91 0.97 Carbohidratos 67.58 56.17 81.87 25.66 83.56 Taninos 62.00 -.- -.- -.- -.-


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA Azucares -.- -.- 83.20 -.- -.-

Tabla Nº 2.1: Características de la tara y sus derivados. (De la Cruz, 2004)

Humedad.- Humedad del fruto o derivados a una temperatura y presión.

Proteína.- Según el método Kjeldhal, utilizando como catalizador selenio, con factor de

conversión de proteínas 6.25.

Extracto etéreo.- Según el método Boxhlet, con tiempo de extracción 6 horas.

Cenizas.- Determinando por el método de incineración a la temperatura de 550 ºC,

durante 6 horas.

Fibras brutas.- Residuo orgánico lavado y seco que queda después de hervir

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

Carbohidratos.- Determinado por diferencia de los análisis de humedad, proteína,

cenizas, fibra bruta y extracto etéreo.

Azúcares totales.- Según el método volumétrico de Lane Eynon y Fehling, a fin de

reducir todo el ión cúprico o cuproso.

Fibra dietética.- La muestra es gelatinizada y digestada enzimáticamente con proteasa

y amiglucosidasa para remover la proteína y el almidón.

A continuación 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 actualización de las características 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 cotización de un acopiador o transformador para la venta de tara

06 El productor debe ser capaz de realizar una cotización 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 cotización de un transformador u otro acopiador para la venta de tara

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

11 El acopiador puede realizar una cotización 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 cotización de un cliente para la venta de tara y sus derivados

15 El transformador será capaz de realizar una cotización de bien o servicio para comercializar tara

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

17 El cliente puede ser capaz de realizar una cotización de tara y sus derivados al transformador

18 El software debe ser capaz de proveer la actualización de las características 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 cotización 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 región

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 histórica de precios para la tara y sus derivados

NO FUNCIONALES

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

26 El software debe tener las ayudas necesarias para su aprendizaje y correcta operación.

27 El software debe ser capaz de ejecutarse en cualquier sistema operativo garantizando su portabilidad

28 El software debe presentar interfaces fáciles de utilizar

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

30 El software debe presentar una arquitectura técnica y codificación usando estándares que permita su operación y mantenimiento adecuado

Tabla Nº 2.2: Requisitos funcionales y no funcionales.

Nº Req. Nº C.P Casos de Prueba de Aceptación

05 09 14

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

02 Comprobar que la cotización, es de un actor (transformador, acopiador y cliente) y presenta información correcta sobre la fecha de vigencia, descripción, unidad, cantidad.

03 Comprobar que el producto tara, provee un actor (productor, transformador y acopiador) y presenta código, descripción y características 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 aceptación. Emitir proforma producto

GLOSARIO DE TÉRMINOS

Administrador Derivado Proforma Mercado Cuenta Venta Demanda Acopiador Usuario Transformador Productor Cotización Solicitud Cliente Oferta Bien Característica Actor directo Servicio Boleta Tara Competencia Actor indirecto Factura

Figura Nº 2.4: Modelo de dominio. Software comercialización de tara


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA 2.2.5 SEGUNDA PRÁCTICA DEL MODELADO DE DOMINIO

La aplicación práctica “SISTEMA WEB PARA EL RESTAURANTE EL NINO”,

fue desarrollado el año 2011, por el equipo integrado, según los estudiantes:

GRUPO : 10 CURSO : SISTEMAS DE INFORMACIÓN II SIGLA : IS-445 ALUMNOS : CÁCERES CURO, Abilio HUAMÁN CURO, Edwin (Delegado) FLORES NÚÑEZ, Eder H. FERNÁNDEZ MEDINA, Ruth PAUCAR RONDINEL, Liz Karla BÁEZ CHIPANA, Pavel DOCENTE : MSc. Ing. Efraín Elías Porras Flores

Identificar Requisitos Nº Req. REQUISITOS FUNCIONALES

1 El administrador debe ser capaz de registrar el menú según categorías, que se mostrarán en la carta.

2 El administrador debe ser capaz de actualizar el menú que se mostrarán en la carta diariamente.

3 El administrador debe ser capaz de registrar a todos los empleados para el control respectivo de los turnos y horarios.

4 El sistema debe permitir generar la planilla de empleados mensualmente, para realizar remuneraciones respectivas del personal.

5 El Administrador debe ser capaz de asignar cuentas de usuario a los empleados que necesariamente interactuaran con el sistema.

6 El sistema debe permitir registrar los insumos adquiridos. 7 El sistema debe permitir controlar y actualizar el almacén de insumos.

8 El sistema debe permitir generar reportes sobre los insumos que se tienen en almacén.

9 El sistema debe permitir registrar y actualizar los artículos con el que cuenta el restaurante.

10 El sistema debe permitir generar reporte sobre los artículos que se tienen en almacén.

11 El sistema debe permitir registrar y controlar a los clientes (Persona natural y Persona Jurídica).

12 El sistema debe ser capaz de registrar y controlar las reservas de mesas.

13 El sistema debe ser capaz de registrar las recetas de todos los menús que se ofrecen en la carta.

14 El sistema debe permitir la consulta de las recetas de los menús previa solicitud del cocinero.

15 El sistema debe permitir registrar y controlar a los proveedores de bienes y servicios.

16 El sistema debe permitir al administrador realizar la respectiva orden de compra de



insumos.

17 El sistema debe mostrar el menú con una imagen que lo represente y con su respectiva especificación, según la categoría que pertenezca en la carta.

18 El sistema debe permitir al cliente realizar la cotización de los menús y bebidas que el restaurante ofrece.

19 El sistema debe permitir al cliente realizar sugerencias y quejas.

20 El sistema debe permitir registrar y controlar las bebidas ofrecidas por el restaurante.

21 El sistema debe generar un reporte de las bebidas que se tienen en el restaurante.

22 El sistema debe ser capaz de mostrar un informe de las ventas del día, semanal, mensual, anual.

23 El sistema debe generar un reporte de flujo de caja diario, semanal, mensual, etc.

24 El sistema permite al cajero emitir un comprobante, al momento de realizarse el pago del consumo.

25 El sistema debe ser capaz de mostrar los menús más vendidos y/o menos vendidos. 26 El sistema muestra las bebidas más consumidas por los clientes del restaurante.

27 El sistema debe permitir registrar y controlar la atención de pedidos por mesa, realizado por los clientes.

28 El sistema debe permitir fraccionar el pago de un pedido de consumo por mesa.

29 El sistema debe permitir consultar los pedidos realizados por los clientes.

30 El sistema debe permitir al Administrador registrar el horario de entrada y salida de los empleados.

31 El sistema debe permitir generar un reporte de todos los clientes más frecuentes.

32 El sistema debe permitir registrar, controlar y generar el mapa de mesas para la atención de pedidos de consumo y reserva de mesas.

33 El administrador debe ser capaz de controlar los cargos de empleados. NO FUNCIONALES 1 El sistema debe ser amigable y de fácil uso para el cliente y usuario. 2 El sistema debe mostrar ayudas al usuario para su correcta navegabilidad.

3 El sistema debe ser personalizable para garantizar el cumplimiento del rol de un actor.

4 El sistema web debe ser capaz de ejecutarse en cualquier sistema operativo garantizando su portabilidad.

5 El sistema debe realizarse usando estándares de calidad que permita una adecuada operación y mantenimiento.

6 El sistema debe permitir brindar seguridad en el flujo de caja.

Glosario de Términos

1. Administrador.- Responsable directo del negocio que realiza el control y

la administración del negocio.

2. Cajero.- Es el actor encargado de registrar ventas, administrar el flujo de

caja y emitir comprobantes de pago.

3. Cocinero.- Encargado de preparar los diferentes platos ofrecidos en la

carta de acuerdo a la receta.


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA 4. Mesero.- Encargado de atender los clientes.

5. Empleado.- Es la entidad que agrupa a los diferentes trabajadores del

negocio.

6. Cliente.- Es el actor que realiza el consumo de los de bienes y servicios

que ofrece el restaurante.

7. Persona Natural.- Es un tipo de cliente que no representa a ninguna

organización.

8. Persona Jurídica.- Es un tipo de cliente que representa a una

organización y posee RUC.

9. Proveedor Bien.- Es el encargado de abastecer de insumos y utensilios al

restaurante.

10. Proveedor servicio.- Es el encargado de ofrecer diferentes servicios.

11. Cotización.- Son evaluaciones de los precios de los diferentes platos,

bebidas, y servicios del restaurante, al pedido del cliente antes de realizar

la venta para determinar lo conveniente.

12. Reserva.- Es la acción de separar una mesa o los servicios ofrecidos por

parte del cliente.

13. Pedido de Consumo.- Es la acción en la cual el cliente se presenta

directamente en el ambiente del restaurante y hace el pedido de los platos

y bebidas para su consumo.

14. Mesa.- Es el objeto donde el cliente consume los platos y bebidas previo

pedido.

15. Mapa de mesas.- Abstracción visual de la ubicación de las mesas en el

restáurate.

16. Pedido.- Es la solicitud que los clientes realizan para el consumo y

atención de los servicios que ofrecen el restaurante.

17. Articulo.- son los objetos utilizados para atender al cliente.

18. Menú.- Es el producto gastronómico que ofrece el restaurante a los

clientes.


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA 19. Receta.- Es lista de insumos y procedimientos para la preparación de un

plato.

20. Insumo.- Todo los productos adquiridos de los proveedores que son

necesarios para la preparación de los platos.

21. Carta.- Es la lista de platos y bebidas ofrecidas diariamente por el

restaurante.

22. Bebida.- Es el producto que ofrece el restaurante para acompaña a los

platos.

23. Pago.- Es acción de intercambiar dinero por productos y/o servicios

ofrecidos por el restaurante.

24. Caja.- Lugar donde se realiza el pago luego del consumo.

25. Comprobante.- Es el documento que se emite para verificar el pago

realizado por el cliente.

26. Boleta.- Es el comprobante que se emite para los clientes naturales.

27. Factura.- Es el comprobante que se emite para los clientes jurídicos.

28. Orden de Compra.- Es el documento que se emite para realizar la compra

de insumo o artículos a un proveedor.

29. Planilla empleado.- Es el registro de empleados con sus respectivos roles

y salario asignado generado mensualmente.


SISTEMAS DE INFORMACIÓN II (IS445) SEGUNDA SEMANA MODELO DE DOMINIO INICIAL


Documents

02 clase IS445 semana 2.pdf