Modelamiento de sistemas de información

Escuela de Ingeniería Industrial

Tarea 1:

Modelamiento de sistemas de información

por

Jose Cifuentes Varela

                Jorge Cortes Peña

               Cristobal Lavin Pavez

Profesor: Guillermo Bustos

Ayudantes: Catalina Herreros, Gabriela Rojas

Junio, 2017

2

Índice

Índice        2

Glosario        3

Lista de Abreviaturas o Siglas        4

1        Introducción        5

2        Supuestos para el modelado del sistema        6

3        Modelamiento del sistema        8

3.1  Dimensión Funcional        8

3.1.1        Diagrama de Casos de Uso        9

3.1.2        Documentación de Casos de Uso        10

3.2  Dimensión Estática        28

3.2.1 Diagrama de Clases        28

3.3  Dimensión Dinámica        30

3.3.1        Diagrama de Actividades        30

3.3.2        Diagrama de Secuencia        40

3.3.3        Diagrama de Interacción Global        50

3.3.4        Diagrama de Máquina de Estados        51

Bibliografía        56

3

Glosario

Hardware: Equipo

4

Lista de Abreviaturas o Siglas

DAct: Diagrama de Actividades

DCla: Diagrama de Clases

DCU: Diagrama de Caso de Uso

DIG: Diagrama de Interacción Global

DME: Diagrama de Máquina de Estados

DoCU: Documentación de Casos de Uso

DSec: Diagrama de Secuencia

5

1        Introducción

En el presente informe se presenta el modelamiento mediante el paradigma de objetos UML de  un sistema de Puntos de Información Universitaria (en adelante , PIU ) , el cual busca que estudiantes,profesores,empleados y público en general puedan acceder a distintos tipos de información.

El contexto de este sistema se encuentra en nuestra universidad (PUCV) la cual pretende mejorar la implementación y el acceso a información por parte de la mayoría de la comunidad universitaria. Es ahí donde el sistema pretende ser útil para un facil y mayor acceso a informacion general , administrativa y personal , dependiendo en cada caso del tipo de persona el cual pretende hacer uso del sistema.

Adicionalmente, a partir de los registros mencionados, es que tanto ARTI como el CTI pueden solicitar al sistema la emisión de diferentes informes, para obtener información a partir de los datos que el sistema maneja, tal como historial de actualizaciones, reparaciones, responsables, etc.; así como también el conocer los equipos que más hayan utilizado la garantía respectiva a partir de fallas que puedan presentar los equipos, como también el correspondiente servicio técnico.

6

2        Supuestos para el modelado del sistema

En este capítulo se presentan todos los supuestos aplicados para modelar el sistema. Los supuestos fueron realizados para cada CU, con algunas consideraciones especiales para el DCla.

Para todos los casos de uso, se asume que ARTI ya está identificado en el sistema, lo cual se refleja a través de las pre-condiciones en cada CU.

Para el CU: Registrar cambio de ubicación

1.- Cuando se registra el cambio de ubicación de un equipo, el sistema agrega internamente la fecha actual como fecha de la nueva ubicación.

2.- El sistema entiende que la última fecha registrada en la ubicación, es decir la más cercana a la fecha actual, es la ubicación actual del equipo.

3.- La actualización de ubicaciones están fuera de los límites del sistema. Por ende, el sistema solo puede verificar las ubicaciones antes de registrarlas.

4.- Cuando existe un cambio de ubicación de un equipo que se encontraba en servicio técnico, además de cambiar la ubicación se debe cambiar el estado a disponible y no se cambiará el estado del equipo que podría haber estado reemplazándolo ya que no está dentro de las funcionalidades del sistema a modelar.

5.- Dado que el registro de cambio de ubicación es posterior a la ejecución del mismo, no es necesario cambiar el estado del equipo a no disponible.

Para el CU: Registrar actualización de componente

6.- El sistema no verifica si hay stock del componente porque el registro es posterior a al cambio de componente.

7.- Cuando existe una actualización de un componente, el componente reemplazado cambiará su estado a “para reposición”.

8.- Para dos componentes iguales, el nombre será el mismo y el código será el diferenciador.

Para el CU: Registrar falla

9.- Se ha realizado el diagnóstico por parte del servicio técnico antes de iniciar el registro de la falla.

10.- Sistema asume que si la garantía está disponible pero no cubre la falla del equipo, entonces se debe pagar por el servicio.

11.- Solo existe registro de factura de reparación cuando no aplica garantía.

7

Para el CU: Registrar reposición de insumos

12.- La reposición del insumo es anterior al registro, por ende no se verifica si existe stock para asignar la reposición.

Para el CU: Asignar CIB

13.- El CIB se ha recibido previamente a la asignación del código a su equipo.

14.- El sistema no valida CIB y asume que ARTI lo ingresará correctamente.

Para el CU: Registrar compra

15.- El sistema sólo registra los datos de factura asociada a la compra de equipos, es decir, no registra los datos de la factura de compra de insumos ni componentes cuando son comprados individualmente; aunque claramente se registran los cambios en stock de dichos elementos.

16.- Se ha recibido previamente la compra con la factura.

Para el CU: Asignar equipo

17.- Los usuarios se encuentran registrados en el sistema. La actualización de estos no es parte de las funcionalidades que posee el sistema. El sistema solo valida al momento que ARTI ingresa un usuario al sistema.

Para el CU: Dar de baja equipo

18.- Cuando se da de baja un equipo, éste no será eliminado del sistema sino que se cambiará su estado a “eliminado”.

19.- Cuando se da de baja un equipo, también se dará de baja los componente cambiando el estado de cada uno de estos a eliminado.

...