Análisis y Diseño de una aplicación Web de Medicina Tradicional y Natural (página 2)

Enviado por Carlos J. Castelao Gonz�lez

Partes: 1, 2

Este modelo es definido a través de tres artefactos: el diagrama de casos de uso del negocio, la descripción de los casos de uso del negocio y el diagrama de actividades de casos de uso del negocio [2].

Actores y trabajadores del negocio.

Considerando como actor del negocio a cualquier individuo, grupo, entidad, organización, máquina o sistema de información externos; que interactúa con el negocio para beneficiarse de sus resultados, se definen los siguientes actores del negocio

Tabla 1: Actores del negocio.

Actor	Descripción
Adulto Mayor	Persona mayor de 60 años, vinculado a la Cátedra del Adulto Mayor que acude al Joven Club para buscar información sobre Medicina Tradicional y Natural.
Especialista MNT	Doctor, Licenciado u otro Técnico especializado en Medicina Tradicional y Natural que atiende a la Cátedra del Adulto Mayor

En el negocio actúan un grupo de personas realizando una o varias actividades, interactuando unas con otras y manipulando entidades; los llamados trabajadores del negocio. A continuación se describen los trabajadores del negocio bajo estudio

Tabla 2: Trabajadores del Negocio.

Trabajador	Descripción
Instructor	Persona encargada de la instrucción en el Joven Club de Computación y Electrónica.
Webmaster	Instructor que tiene la tarea de publicar información en la red local de la entidad.
Digitalizador	Conjunto de dispositivos electrónicos que permiten digitalizar la información.
Servidor	Computadora principal de la entidad que brinda diferentes servicios tales como: datos, intranet, búsqueda de información a través de una biblioteca digital, Internet y correo electrónico.

Diagrama de casos de Uso del negocio.

Para tener una visión general de los diferentes procesos de negocio de la organización, se elabora el diagrama de casos de uso del negocio, en el que aparece cada proceso del negocio como un caso de uso, relacionado con el actor del negocio, como se muestra en la figura 1.

edu.red

Figura 1: Diagrama de Casos de Uso del Negocio.

1.3.5 Descripción textual de los Casos de Uso del Negocio.

Caso de Uso del Negocio:	Publicar Información Medicina Tradicional y Natural.
Actores:	Especialista MTN (inicia).
Propósito:	Brindar información a los estudiantes de la Cátedra del Adulto Mayor.
Resumen: El caso de uso se inicia cuando el Especialista contacta el Webmaster para publicar información en el servidor del Joven Club. Puede que la información antes de ser publicada en el Servidor sea necesario digitalizarla o buscarla en Internet. El caso de uso termina cuando finalmente la información queda publicada en el Servidor.
Acción del Actor	Respuesta del Proceso del Negocio
1. Especialista MTN solicita publicación de la información. 5. Recibe la notificación.	2. Webmaster recibe la solicitud de Especialista MTN. 3. Webmaster publica la información en el Servidor. 4. Webmaster notifica a Especialista MTN la publicación.
Curso Alternativo de los eventos.
Acción 2	Si la información no existe Webmaster busca la información en Internet y notifica a Especialista MTN para su publicación. Especialista MTN evalúa la información y decide si se publica o no. En caso afirmativo notifica la aprobación al Webmaster y se pasa al paso 3. Si la información existe Webmaster revisa que esté digitalizada. En caso afirmativo se pasa al paso 3. En caso contrario Webmaster digitaliza la información con el Digitalizador y se pasa al paso 3.
Prioridad:	Alta
Mejoras:	Se propone la creación de un Sitio Web Dinámico con una estructura bien definida, que sea publicado en la Intranet de la instalación, pueda ser actualizado sin dificultad por el Webmaster con el asesoramiento y trabajo conjunto con el especialista en Medina Tradicional y Natural en la selección del contenido, imágenes y otros recursos que faciliten el aprendizaje. Se considera oportuno incluir un sistema de ejercicios propuestos por cada unidad de contenido y que al final de cada unidad aparezca un grupo de preguntas o ejercicios para la autoevaluación del estudiante.
Otras secciones:	–

Ver Anexo A.1: Diagrama de Actividades del Caso de Uso del negocio "Publicar Información Medicina Tradicional y Natural".

Caso de Uso del Negocio:	Buscar Información sobre MTN
Actores:	Adulto Mayor (Inicia)
Propósito:	Publicar toda la información a los estudiantes de la Cátedra del Adulto Mayor sobre MTN
Resumen: Proceso que comienza cuando el adulto mayor se acerca a la instalación solicitando información sobre Medicina Tradicional y Natural. Generalmente es atendido por un instructor quien se limita a buscar en el servidor solo aquello que el Webmaster haya publicado.
Acción del Actor	Respuesta del Proceso del Negocio
1. El Adulto Mayor solicita información sobre medicina tradicional y natural al Instructor. 6. El Adulto Mayor recibe notificación. 7. El Adulto Mayor consulta información.	2. El Instructor recibe solicitud del adulto mayor. 3. El Instructor procesa la solicitud. 4. El Instructor busca y obtiene información a través del Servidor. 5. El Instructor notifica los resultados de la información hallada al Adulto Mayor.
Curso Alternativo de los eventos.
Acción 6.	En caso de Adulto Mayor no reciba resultados de la búsqueda finaliza el caso de uso.
Prioridad:	Alta
Mejoras:	Utilizar un Sitio Web Dinámico como medio de enseñanza que facilite la búsqueda de información.
Otras secciones:	–

Ver Anexo A.2: Diagrama de Actividades del Caso de Uso del negocio "Buscar Información sobre MTN".

Diagrama de Clases del Modelo de Objetos del Negocio.

El diagrama de clases, como artefacto que se construye para describir el modelo de objetos del negocio, muestra la participación de los trabajadores y entidades del negocio, y su colaboración o relación en la realización del negocio.

Un modelo de objetos del negocio es un modelo interno a un negocio. Describe como cada caso de uso del negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y unidades de trabajo [3].

edu.red

Figura 2: Diagrama de clases del Modelo de Objeto del Negocio.

1.4 Captura de Requerimientos.

En este punto se identifican los requisitos funcionales y no funcionales del sistema que dará solución al problema planteado; quiénes interactuarán con él (actores del sistema) y las distintas funcionalidades que ofrecerá a cada uno de los actores [4].

1.4.1 Requisitos Funcionales.

En la realización de los casos de uso del negocio, se obtienen las actividades que serán objeto de automatización. Estas actividades no son exactamente los requerimientos funcionales, pero sí son el punto de partida para identificar qué debe hacer el sistema [4].

Se espera que el sistema propuesto tenga las siguientes funcionalidades.

1. Realizar autenticación de los usuarios al sistema.
2. Permitir que los usuarios registrados en el sistema cambien su clave de acceso.
3. Registrar Usuario.
4. Actualizar información del Usuario.
5. Eliminar Usuario.
6. Registrar Tema.
7. Actualizar los datos del Tema.
8. Eliminar Tema.
9. Registrar Material Complementario.
10. Actualizar los datos del Material Complementario.
11. Eliminar Material Complementario.
12. Registrar SEP (Sistema de Ejercicios Propuestos).
13. Actualizar los datos del SEP.
14. Eliminar SEP.
15. Registrar Autoevaluación.
16. Actualizar los datos de la Autoevaluación.
17. Eliminar Autoevaluación.
18. Calificar actividad de autoevaluación.
19. Publicar información referente a la importancia, funciones, y objetivos de la MTN.
20. Publicar enlaces a otros sitios de interés.
21. Consultar Temas de cada módulo.
22. Consultar Materiales Complementarios (MC) de cada módulo.
23. Consultar SEP de cada tema.
24. Consultar Autoevaluación del tema.
25. Consultar Enlaces.
26. Consultar Información MTN.
27. Permitir la salida por impresora de todos los informes que sean visualizados.
28. Consultar ayuda.
29. Registrar Posible Respuesta.
30. Actualizar los datos de la Posible Respuesta.
31. Eliminar Posible Respuesta.

Requisitos no funcionales.

Apariencia: El sistema debe ser sencillo y que permita la navegación orientada al usuario a través de señales de navegación.

Usabilidad: El sistema podrá ser utilizado por cualquier persona con mínimos conocimientos en el manejo de la computadora y el ambiente Web en sentido general, debido a que contará con una ayuda a fin de documentar al usuario en su utilización.

Rendimiento: El sistema deberá ser rápido ante las solicitudes de los usuarios y en el procesamiento de la información. La eficiencia de la aplicación estará determinada en gran medida por el aprovechamiento de los recursos que se disponen en el modelo Cliente/Servidor, y la velocidad de las consultas a la base de datos. Se realizará la validación de los datos y la manipulación de eventos en el cliente y en el servidor aquellas que por cuestiones de seguridad, o de acceso a los datos lo requieran. Lográndose así un tiempo de respuesta más rápido, una mayor velocidad de procesamiento, y un mayor aprovechamiento de los recursos.

Modelo del Sistema.

Actores del modelo de sistema.

Los actores representan terceros fuera del sistema que colaboran con él [6].Cada trabajador del negocio que tiene actividades a automatizar es un candidato a actor del sistema.

Tabla 3.1 Descripción de los actores del sistema.

Nombre del Actor

Justificación

Usuario

Usuario que no necesita autenticación. Puede consultar toda la información que esté disponible y autoevaluarse si así lo desea.

Requerimientos asociados: 18, 21, 22, 23, 24, 25, 26, 27 y 28.

Usuario Registrado

Este actor realiza las mismas actividades que Usuario pero además garantiza la protección de la información a través del control de usuarios y se encarga de gestionar los temas, materiales complementarios, sistemas de ejercicios propuestos, ejercicios para la autoevaluación, así como la publicación de información referente a MTN y enlaces a otros sitios de interés.

Requerimientos asociados: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 y 31.

Casos de Uso del sistema.

Cada forma en que los actores usan el sistema se representa con un Caso de Uso. Los Casos de Uso son "fragmentos" de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Un Caso de Uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia [7].

Se proponen los siguientes casos de uso para el sistema:

1. Autenticar. (R1)
2. Cambiar Contraseña. (R2)
3. Administrar Usuarios. (R3,4,5)
4. Gestionar Tema. (R6,7,8)
5. Gestionar Material Complementario. (R9,10,11)
6. Gestionar SEP. (R12,13,14)
7. Gestionar Autoevaluación. (R15,16, 17)
8. Realizar Autoevaluación. (R18, 24)
9. Publicar Información MTN. (R19, 27)
10. Publicar Enlaces. (R20, 27)
11. Consultar Temas del Módulo. (R21, 27)
12. Consultar MC del Módulo. (R22, 27)
13. Consultar SEP del Tema. (R23, 27)
14. Consultar Enlaces. (R25)
15. Consultar Información MTN. (R26)
16. Consultar ayuda. (R28, 27)
17. Gestionar Posibles Respuestas. (R29, 30, 31)

Paquetes y sus relaciones.

Subdividir los casos de uso en paquetes resulta de mucha ayuda en la modelación de cualquier sistema informático.

Los paquetes son un mecanismo de organización de elementos que subdividen el modelo en otros más pequeños que colaboran entre sí. Este particionamiento debe hacerse sobre la base de los requerimientos funcionales y el dominio del problema; y debe ser reconocible por las personas con conocimiento del dominio [8].Se propone el siguiente diagrama de paquetes:

edu.red

Figura 3: Paquetes por Casos de Uso. Relación entre Paquetes.

Diagramas de Casos de uso del Sistema.

edu.red

Figura 4: Jerarquía de actores.

edu.red

Figura 5: Paquete de Administración. Diagrama de Casos de Uso.

edu.red

Figura 6: Paquete de Gestión. Diagrama de Casos de Uso.

edu.red

Figura 7: Paquete de Publicación. Diagrama de Casos de Uso.

Descripción textual de los Casos de Uso del Sistema.

Caso de Uso (1)	Autenticar
Actores	Usuario Registrado (inicia).
Propósito	Proteger el acceso a la información.
Resumen El caso de uso inicia cuando Usuario Registrado desea gestionar información. Para ello debe ingresar su login y su contraseña y a continuación el sistema chequea. Si los datos son válidos, el usuario podrá acceder a las opciones del sistema que le corresponden, en caso contrario el sistema muestra un mensaje de error denegando el acceso y finalizando así el caso de uso.
Referencias	R1
Precondiciones	El login y la contraseña deben estar registrados y el usuario debe estar habilitado.
Poscondiciones	El usuario accede a la información que le corresponde según su nivel.
Requisitos Especiales	—
Prototipo	Anexo B.1

Caso de Uso (2)	Cambiar Contraseña
Actores	Usuario Registrado (inicia).
Propósito	Permitir que el usuario registrado cambie su clave de acceso al sistema.
Resumen El caso de uso se inicia cuando un usuario registrado desea cambiar su contraseña. El sistema le muestra un formulario en el que debe introducir la anterior contraseña y la nueva; confirmando esta última a fin de evitar posibles equivocaciones. Una vez que introduce los datos, el sistema confirma que estén completos y sean válidos. Si no lo son muestra mensaje de error y no realiza la modificación. En caso de que no existan errores, la contraseña es cambiada satisfactoriamente.
Referencias	R2
Precondiciones	Debe existir información almacenada del usuario registrado y este debe estar activo.
Poscondiciones	La contraseña se actualiza en caso de no existir errores.
Requisitos Especiales	—
Prototipo	Anexo B.2

Caso de Uso (3)	Administrar Usuarios
Actores	Usuario Registrado (inicia).
Propósito	Proteger la información del sistema a través de la administración de usuarios con niveles de acceso.
Resumen El caso de uso se inicia cuando un Usuario Registrado selecciona Control de Usuarios, el sistema muestra la lista de todos ellos. Este elige la operación a realizar: Registrar, Actualizar o Eliminar usuario del sistema. No se modifica el nombre de usuario ni este pueden existir valores duplicados del mismo. Al eliminar los usuarios se valida que deba quedar al menos un usuario definido. De esta forma la información queda actualizada finalizando el caso de uso.
Referencias	R3, R4 y R5.
Precondiciones	Debe existir al menos un usuario en la base de datos.
Poscondiciones	Se actualiza la información referente a los usuarios: Si acción: registrar, se registra un usuario. Si acción: actualizar, se actualiza la información. Si acción: eliminar, se elimina el usuario.
Requisitos Especiales	—
Prototipo	Anexo B.3

Caso de Uso (4)	Gestionar Tema.
Actores	Usuario Registrado (inicia).
Propósito	Definir los temas de cada módulo de contenido.
Resumen El caso de uso se inicia cuando Usuario Registrado selecciona el módulo y a continuación Adicionar Tema. Este elige la operación a realizar: Registrar, Actualizar Tema. No se permite modificar el código del Tema ni pueden existir valores duplicados de este dato. Al eliminar un tema se valida que no tenga información asociada, en caso contrario no podrá ser eliminado. La información es actualizada finalizando el caso de uso.
Referencias	R6, R7 y R8.
Precondiciones	Debe existir al menos un módulo definido.
Poscondiciones	Se actualiza la información referente al tema: Si acción: registrar, se registra un tema. Si acción: actualizar, se actualiza el tema. Si acción: eliminar, se elimina el tema.
Requisitos Especiales	—
Prototipo	Anexo B.4

Caso de Uso (5)	Gestionar Material Complementario.
Actores	Usuario Registrado (inicia).
Propósito	Definir los materiales complementarios de cada módulo de contenido.
Resumen El caso de uso se inicia cuando Usuario Registrado selecciona el módulo y a continuación Adicionar Material Complementario. Este elige la operación a realizar: Registrar, Actualizar o Eliminar Material Complementario. No se permite modificar el código del Material ni pueden existir valores duplicados de este dato. La información es actualizada finalizando el caso de uso.
Referencias	R9, R10 y R11.
Precondiciones	Debe existir al menos un módulo definido.
Poscondiciones	Se actualiza la información referente al material complementario: Si acción: registrar, se registra un material. Si acción: actualizar, se actualiza el material. Si acción: eliminar, se elimina el material.
Requisitos Especiales	—
Prototipo	Similar al Anexo B.4

Caso de Uso (6)	Gestionar SEP.
Actores	Usuario Registrado (inicia)
Propósito	Definir el Sistema de Ejercicios Propuestos de cada tema.
Resumen El caso de uso se inicia cuando Usuario Registrado selecciona un tema y a continuación Adjuntar Sistema de Ejercicios Propuestos. Este elige la operación a realizar: Registrar, Actualizar o Eliminar SEP. La información es actualizada finalizando el caso de uso.
Referencias	R12, R13 y R14.
Precondiciones	Debe existir al menos un tema definido.
Poscondiciones	Se actualiza la información referente al SEP: Si acción: registrar, se registra el SEP. Si acción: actualizar, se actualiza el SEP. Si acción: eliminar, se elimina el SEP.
Requisitos Especiales	—
Prototipo	Anexo B.5

Caso de Uso (7)	Gestionar Autoevaluación.
Actores	Usuario Registrado (inicia).
Propósito	Definir el sistema de autoevaluación de cada tema.
Resumen El caso de uso se inicia cuando Usuario Registrado selecciona un tema y a continuación Adicionar Autoevaluación. Este elige la operación a realizar: Registrar, Actualizar o Eliminar Autoevaluación. La información es actualizada finalizando el caso de uso.
Referencias	R15, R16 y R17. Gestionar Posible Respuesta (include).
Precondiciones	Debe existir al menos un tema definido.
Poscondiciones	Se actualiza la información referente a la autoevaluación: Si acción: registrar, se registra la autoevaluación. Si acción: actualizar, se actualiza la autoevaluación. Si acción: eliminar, se elimina la autoevaluación.
Requisitos Especiales	—
Prototipo	Anexo B.6

Caso de Uso (8)	Realizar Autoevaluación.
Actores	Usuario (inicia)
Propósito	Responder ejercicio para una autoevaluación del tema.
Resumen El caso de uso se inicia cuando Usuario selecciona un tema y a continuación Autoevaluación. Una vez que el usuario ha contestado las preguntas y procede a solicitar la calificación, el sistema le muestra su puntuación. Se muestran los resultados obtenidos por el usuario finalizando el caso de uso.
Referencias	R18 y R24.
Precondiciones	Debe existir al menos un ejercicio de autoevaluación definido.
Poscondiciones	—
Requisitos Especiales	—
Prototipo	Anexo B.7

Caso de Uso (9)	Publicar Información MTN.
Actores	Usuario Registrado (inicia).
Propósito	Publicar información acerca de la importancia de la Medicina Tradicional y Natural.
Resumen El caso de uso se inicia cuando Usuario Registrado desea publicar información de carácter relevante relacionada con la Medicina Tradicional y Natural. La información es publicada finalizando el caso de uso.
Referencias	R19 y R27.
Precondiciones	—
Poscondiciones	—
Requisitos Especiales	—

Caso de Uso (10)	Publicar Enlaces.
Actores	Usuario Registrado (inicia).
Propósito	Publicar enlaces a varios sitios de interés relacionados con la Medicina Tradicional y Natural.
Resumen El caso de uso se inicia cuando Usuario Registrado desea publicar enlaces de carácter relevante relacionados con sitios de interés que contemplen un especio para la Medicina Tradicional y Natural, así como despierten motivación sobre el tema. La información es publicada finalizando el caso de uso.
Referencias	R19 y R27.
Precondiciones	—
Poscondiciones	—
Requisitos Especiales	—

Caso de Uso (11)	Consultar Temas del Módulo.
Actores	Usuario (inicia).
Propósito	Consultar un tema perteneciente a un módulo de contenido.
Resumen El caso de uso se inicia cuando Usuario consulta un tema de uno de los módulos de contenido del sitio. A continuación se le muestra el contenido correspondiente. La información es consultada finalizando el caso de uso.
Referencias	R21 y R27.
Precondiciones	Debe existir al menos un tema definido.
Poscondiciones	—
Requisitos Especiales	—

Caso de Uso (12)	Consultar MC del Módulo.
Actores	Usuario (inicia).
Propósito	Consultar los materiales complementarios pertenecientes a un módulo de contenido.
Resumen El caso de uso se inicia cuando Usuario desea consultar los materiales complementarios de un módulo de contenido. A continuación se le muestra la información correspondiente. El MC es consultado finalizando el caso de uso.
Referencias	R22 y R27.
Precondiciones	Debe existir al menos un MC definido.
Poscondiciones	—
Requisitos Especiales	—
Prototipo	Anexo B.8

Caso de Uso (13)	Consultar SEP del Tema.
Actores	Usuario (inicia).
Propósito	Consultar el Sistema de Ejercicios Propuestos de cada tema.
Resumen El caso de uso se inicia cuando Usuario Registrado selecciona un tema y a continuación Consultar Sistema de Ejercicios Propuestos. A continuación se le muestra la información correspondiente. El SEP es consultado finalizando el caso de uso.
Referencias	R23 y R27.
Precondiciones	Debe existir al menos un SEP definido.
Poscondiciones	—
Requisitos Especiales	—
Caso de Uso (14)	Consultar Enlaces.
Actores	Usuario (inicia).
Propósito	Visitar sitios de interés relacionados con Medicina Tradicional y Natural.
Resumen El caso de uso se inicia cuando Usuario desea visitar los enlaces publicados. A continuación se le muestra la información correspondiente. El sitio web acorde al enlace es visitado finalizando el caso de uso.
Referencias	R25.
Precondiciones	La información de los enlaces debe estar disponible.
Poscondiciones	—
Requisitos Especiales	—

Caso de Uso (15)	Consultar Información MTN.
Actores	Usuario (inicia).
Propósito	Consultar información acerca de la importancia de la Medicina Tradicional y Natural.
Resumen El caso de uso se inicia cuando Usuario desea revisar información de carácter relevante relacionada con la Medicina Tradicional y Natural. La información es consultada finalizando el caso de uso.
Referencias	R26.
Precondiciones	—
Poscondiciones	—
Requisitos Especiales	—

Caso de Uso (16)	Consultar Ayuda.
Actores	Usuario (inicia).
Propósito	Facilitar una asistencia técnica al usuario ante cualquier interrogante.
Resumen El caso de uso inicia cuando Usuario presenta dificultades para realizar una operación y para esto acude a la ayuda. Seguidamente el sistema le muestra la página de ayuda que se puede explorar, finalizando así el caso de uso.
Referencias	R27 y R28.
Precondiciones	—
Poscondiciones	—
Requisitos Especiales	—

Caso de Uso (17)	Gestionar Posibles Respuestas.
Actores	Usuario Registrado (inicia).
Propósito	Conformar las posibles respuestas que formarán parte de un ejercicio de autoevaluación.
Resumen El caso de uso inicia cuando Usuario Registrado selecciona un tema y luego la opción Autoevaluación – Adicionar Posibles Respuestas. A continuación se podrá Registrar, Actualizar o Eliminar una posible respuesta para la autoevaluación finalizando el caso de uso.
Referencias	R29, R30 y R31.
Precondiciones	Debe existir al menos un tema y una autoevaluación en la base de datos.
Poscondiciones	Se actualiza la información referente a la posible respuesta de la autoevaluación: Si acción: registrar, se registra una posible respuesta. Si acción: actualizar, se actualiza la posible respuesta. Si acción: eliminar, se elimina la posible respuesta.
Requisitos Especiales	—
Prototipo	Anexo B.9

Descripción de la solución propuesta.

Diagrama de tres capas, detallando cada una de las capas mediante paquetes.

edu.red

Figura 8: Diagrama de 3 capas.

Diagrama del modelo lógico de datos.

El diagrama del modelo lógico de datos o diagrama de clases persistentes, muestra las clases capaces de mantener su valor en el espacio y en el tiempo (Ver Anexo C.1).

Diagrama del modelo físico de datos.

Cuando se define correctamente el modelo lógico, se hace mucho menos engorroso llegar al modelo de datos o modelo físico como también se le denomina en la metodología RUP de la siguiente forma: "el modelo de datos representa la estructura

o descripción física de las tablas de la base de datos y es obtenido a partir del diagrama de clases persistentes" (Ver Anexo C.2).

Diagrama de Componentes.

Un diagrama de componentes muestra un conjunto de componentes y sus relaciones. Gráficamente representan una colección de nodos o componentes y arcos, los primeros representan componentes, interfaces y los segundos relaciones de dependencia, generalización / especialización, asociación, agregación/composición y realización. El diagrama de componentes describe los elementos físicos del sistema y sus relaciones. En el caso de las aplicaciones Web, podrían describirse todas las páginas Web del sistema y sus relaciones.

edu.red

Figura 9: Diagrama de componentes.

Diagrama de implementación.

El modelo de implementación denota la implementación del sistema en términos de componentes y subsistemas de implementación. Describe cómo se organizan los componentes de acuerdo con los mecanismos de estructuración, y modularización disponibles en el entorno de la implementación y en el lenguaje o lenguajes de programación utilizados, y como dependen los componentes unos de otros [9].

edu.red

Figura 10: Diagrama de implementación.

Principios de diseño del sistema.

El diseño de la interfaz de una aplicación, el formato de los reportes, la concepción de la ayuda y el tratamiento de excepciones tiene gran influencia en el éxito o fracaso de una aplicación. A continuación se describen los principios de diseño que deben tenerse en cuenta para el desarrollo del sistema.

Diseño de la interfaz de entrada, salidas y menús del sistema.

El menú estará acorde en gran medida a los requerimientos funcionales, no funcionales y a la temática en cuestión. El uso adecuado de iconos e imágenes relativamente pequeñas facilitará la comprensión de las funcionalidades del sistema.

La interfaz diseñada para el sitio web dinámico debe estar concebida para la resolución 800×600 píxel. La navegabilidad por las páginas debe ser consistente y evitando la ruptura de hipervínculos.

Deben ser utilizados colores claros y relajantes a la vista del usuario para que este se sienta cómodo mientras interactúa con el sistema.

Tratamiento de errores.

En el sistema propuesto se deben evitar, minimizan y tratar los posibles errores, con el fin de garantizar la integridad y confiabilidad de los datos que se registran y muestran. Las posibilidades de introducir información errónea por parte del usuario deben ser mínimas, manteniendo un nivel de validación de la información y en caso de errores comunicar los mismos a través de mensajes y cuadros de alerta. Los mensajes de error que emita el sistema tendrán un lenguaje de fácil comprensión para los usuarios.

Concepción general de la ayuda.

La ayuda quedará compuesta en gran parte por la explicación funcional del sistema aunque debe incluir temas teóricos para una mejor comprensión. Esto tiene el objetivo de que el usuario no solo tenga la explicación funcional, sino que también pueda entender en qué consiste el software y cuente con mayor información en caso de decidir posteriormente en su mantenimiento.

Referencias Bibliográficas.

1. Jacobson, I. El Proceso Unificado de Desarrollo de software / –Addison-Wesley. 2000. –t.1.–p. 58.
2. Ibídem, p. 110.
3. Ibídem, p. 116.
4. Ibídem, p. 107.
5. Ibídem, p. 110.
6. Ibídem, p. 128.
7. Ibídem, p. 129.
8. Hernández González, Anaisa. Modelo del Sistema: material para uso docente. — Ciudad de La Habana: [sn], 2005 –p.20.
9. Jacobson, I. El Proceso Unificado de Desarrollo de software / –Addison-Wesley. 2000. –t.1.–p. 257.

Anexos

ANEXO A: DIAGRAMAS DE ACTIVIDADES.Anexo A.1: Diagrama de Actividades del Caso de Uso del Negocio: Publicar Información Medicina Tradicional y Natural.

edu.red