Diagramas finales SW

549 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
549
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Diagramas finales SW

  1. 1. [DOCUMENTACION ] Ingeniería de Software III UNIVERSIDAD DE LA AMAZONIA FACULTAD DE INGENIERIA DE SISTEMASDOCUMENTACION Y DIAGRAMAS DEL SISTEMA “HOLA MUNDO” BAJO ARQUITECTURA .NET GUSTAVO ADOLFO DIAZ TOVAR COD: 172001464 INGENIERIA DE SOFTWARE III EDWIN EDUARDO MILLAN ROJAS VIII SEMESTRE FLORENCIA-CAQUETA 2010
  2. 2. [DOCUMENTACION ] Ingeniería de Software IIISISTEMA PROPUESTORequerimientos Funcionales“Hola Mundo” es un sistema a desarrollar para la lectura de un mensaje por parte de sus usuarios.El Administrador de Base de Datos del sistema (DBA), identificado previamente, es el encargado de ingresar o modificar, si éste así lo considera, el mensaje que serávisualizado por los demás usuarios que ingresen al sistema; además, tiene las facultades de Registrar o Eliminar usuarios, de Asignar o Eliminar roles (Admin, Cliente) deacuerdo a sus decisiones.El Administrador de la aplicación (Admin) al igual que el DBA está encargado de la modificación del mensaje, además de efectuar la descarga de éste para ser almacenadoen disco en su estación de trabajo, ésta última acción está permitida para todo usuario previamente registrado e identificado por el sistema (DBA-Admin-Cliente).Hola Mundo, dispone de un usuario invitado que sólo está apto para visualizar el mensaje. De éste modo el sistema podrá ser consultado por cualquier usuariorespetando el Rol que el sistema lee inmediatamente el usuario es debidamente identificado.OBSERVACIONES Y MEJORAS:  En la definición de los Usuarios del sistema existe una inconsistencia entre lo que se plantea en los requerimientos funcionales (Pag 9 ArquitecturaNet.pdf) con lo definido en el diagrama de casos de uso, por tal motivo, para efecto de mejora a la definición del diseño del diagrama de Casos de Uso se plantearon 4 Roles dentro del sistema que son: 1. DBA: Tiene control total de cada una de las operaciones del sistema. 2. Administrador: Tiene privilegios de DBA excepto el de asignar roles y de eliminar Usuarios. 3. Cliente: Esta registrado en el sistema y tiene privilegios de Consultar el mensaje, de Mirar su perfil y descargar el mensaje. 4. Invitado: Tiene privilegios de consultar el mensaje y de registrarse ante el sistema.
  3. 3. [DOCUMENTACION ] Ingeniería de Software III Como mejora a la definición de usuarios y casos de uso del sistema propuesto por los Ingenieros Ives Pacheco y Laura Bohorquez diseñadores del sistema “Hola Mundo”, se propuso mejorar el diseño de los diagramas de casos de uso como respuesta a los requerimientos funcionales; como es el manejo de los mensajes, el control de los registros de usurario y la definición de los privilegios. Por cuestiones de corrección y mejoras de diseño, se adicionaron al modelo de casos de uso tres nuevos procesos funcionales que son: 1. Registrar Mensaje: Permite registrar en la base de datos el mensaje que se quiere mostrar a los usuarios que acceden a la aplicación. 2. Eliminar Mensaje: Permite eliminar de la base de datos el mensaje almacenado. 3. Buscar Usuarios: Permite retornar cada uno de los atributos definidos para cada uno de los usuarios registrador en la base de datos. Por motivos de implementación y de interpretación se excluyo del diseño el caso de uso Eliminar Roles, ya que según las especificaciones los roles ya estarían predefinidos en la aplicación como lo son (DBA, Administrador, Invitado y Cliente) y estos deben estar asignados obligatoriamente a cada nuevo usuario, lo que invalida la opción de eliminarlos por cuestiones de integridad de los datos, por otro lado, en el diagrama de Entidad Relación no se describe un control de usuarios desde la lógica de persistencia lo que hizo necesario implementar el control de usuarios desde la lógica de negocio por medio del manejo de los roles, lo que hace necesario que cada usuario tenga asignado un rol dentro de la base de datos para controlar su navegabilidad dentro de la aplicación. El diagrama de clases actual no modela ni describe correctamente la estructura del sistema, presenta inconsistencia y no están definidos cada uno de los métodos y atributos que harán parte del sistema (Pag 14 ArquitecturaNEt.pdf). En la mejora a este diagrama se adicionaron nuevos métodos que surgieron a partir del análisis y de la revisión de las especificaciones, como también a partir del manejo del control de usuarios, considerando como importante la definición de estos dentro del diagrama, como también se completo el diseño con la definición de las interfaces de las clases cmensaje y cpersona con cada uno de sus métodos. Se adicionaron los siguientes métodos: Clase cmensaje: 1. Mostrar_mensaje(): Retorna el Mensaje que se encuentra registrado en la base de datos 2. Insertar_mensaje():Permite registrar en la base de datos el mensaje 3. Eliminar_mensaje(): Elimina de la base de datos el mensaje que este almacenado. 4. Crear_texto(string mensaje, int alineacion, int tamaño, int tipo); Generar un archivo con extensión pdf con el mensaje registrado en la base de datos.
  4. 4. [DOCUMENTACION ] Ingeniería de Software III Clase cpersona: 1. Buscar_usuario(); Retorna cada uno de los datos registrados para el usuario consultado. 2. Eliminar_persona(): Elimina cada uno de los datos registrador para el usuario seleccionado. 3. Setloginrol(string login, string rol); Almacena temporamente el login y el rol del usuario que abre una session en la aplicación 4. Getlogin();Retorna el login del usuario mientras este tenga la sesión abierta. 5. Getrol();Retorna el rol del usuario mientras este tenga la sesión abierta. En el diseño de los diagramas de secuencia se definió cada una de los pasos que realizan los objetos y la interacción de estos. Es importante aclarar que cada uno de las secuencias tiene unas condiciones que están definidas en la nota de cada diagrama, para este diseño se elaboraron 11 diagramas que describen el funcionamiento y la interacción de las instancias. Del modelo ER actual no existe la documentación de las especificaciones ni el diccionario de datos del mismo, lo que no permitió interpretar el atributo (Sel) de la tabla cmensaje. A partir del análisis del sistema y de la definición entregada sobre el sistema, se considero necesario eliminar de la tabla cmensaje este atributo ya que no representa ninguna relación funcional con los demás atributos de esta tabla y este no representa un atributo importante en la definición del sistema. Como no existe una documentación clara de cada uno de los atributos de las tablas, al normalizar no surgieron nuevas tablas ya cada uno de los atributos de la tabla persona y mensaje presentan una dependencia funcional a su respectiva llave primaria. Aunque en los requerimientos no se define el control de registro de cada mensaje, en la mejora se propone una relación de uno a muchos entre cpersona y cmensaje para determinar el responsable del ingreso del mensaje, de tal manera se podrá auditar los mensajes. En términos generales el diseño actual del sistema no cumple a plenitud los requerimientos funcionales y no están bien especificados cada uno de los diagramas lo que dificulta la implementación, como mejora al sistema actual se entrega un nuevo diseño que mantiene las bases de la definición del sistema propuesto pero que se ajusta a el control de la seguridad en las sesiones y a la navegabilidad que requiere el cliente. El diagrama de Despliegue presentado por los diseñadores no describe las direcciones ni el tipo de artefacto que se utilizaría, ni tampoco describe las direcciones correspondientes de cada uno de los servidores. Uno de los errores encontrado en este diagrama (Pag 32 Arquitectura.Net.pdf) es la forma como se esta empaquetando la aplicación en el servidor Web ya que en este no se encuentran códigos fuentes como los cs. Como mejora a este diagrama se propone la definición del direccionamiento, la definición de los tipos de artefactos requeridos y la corrección de la versión del Framework a la 4.0
  5. 5. [DOCUMENTACION ] Ingeniería de Software IIIA partir de lo anterior se diseño y se implemento de la siguiente manera: DEFINICON USUARIOS DEL SISTEMA Identificación Nombre Casos de Uso Registrar Mensaje, Modificar Mensaje, Consultar Mensaje, Eliminar Mensaje, Registrar Usuario, Buscar 1 DBA Usuario, Modificar Datos, Eliminar Usuario Descargar Mensaje, Asignar Rol Registrar Mensaje, Modificar Mensaje, Consultar Mensaje 2 Administrador Eliminar Mensaje, Registrar Usuario, Buscar Usuario, Modificar Datos, Descargar Mensaje 3 Cliente Consultar Mensaje, Descargar Mensaje 4 Invitado Consultar Mensaje, Registrar Usuario
  6. 6. [DOCUMENTACION ] Ingeniería de Software IIIDIAGRAMA DE CASOS DE USO
  7. 7. [DOCUMENTACION ] Ingeniería de Software IIIDIAGRAMA DE CLASES
  8. 8. [DOCUMENTACION ] Ingeniería de Software III1. Registrar Cliente
  9. 9. [DOCUMENTACION ] Ingeniería de Software III2. Buscar Usuario
  10. 10. [DOCUMENTACION ] Ingeniería de Software III3. Modificar Datos
  11. 11. [DOCUMENTACION ] Ingeniería de Software III4. Eliminar Usuario
  12. 12. [DOCUMENTACION ] Ingeniería de Software III5. Asignar Roles
  13. 13. [DOCUMENTACION ] Ingeniería de Software III6. Registrar Mensaje
  14. 14. [DOCUMENTACION ] Ingeniería de Software III7. Modificar Mensaje
  15. 15. [DOCUMENTACION ] Ingeniería de Software III8. Eliminar Mensaje
  16. 16. [DOCUMENTACION ] Ingeniería de Software III9. Consultar Mensaje
  17. 17. [DOCUMENTACION ] Ingeniería de Software III10. Descargar Mensaje
  18. 18. [DOCUMENTACION ] Ingeniería de Software III11. Validar Usuario
  19. 19. [DOCUMENTACION ] Ingeniería de Software IIIDIAGRAMA DE ESTRUCTURAS COMPUESTAS
  20. 20. [DOCUMENTACION ] Ingeniería de Software IIIDIAGRAMA DE DESPLIEGUE

×