Asi

Anlisis de sistemas de Informacin en la prctica
Javier Gutirrez javierj@us.es
ASI en la prctica
Objetivo: Desarrollar un ASI aplicando tcnicas de desarrollo estructurado y de orientacin a objetos.
Introduccin a Mtrica 3
ndice:
1. Un resumen del proceso. 2. Definicin del sistema. 3. Identificacin de requisitos. 4. Establecimiento de subsistemas de anlisis. 5. Anlisis de casos de uso. 6. Anlisis de clases. 7. Definicin del modelo de datos. 8. Definicin del modelo de procesos. 9. Definicin de interfaces de usuario. 10. Terminar el ASI. 11. Conclusiones.
Un resumen del proceso
Un resumen del proceso ASI
Un resumen del proceso ASI

Entradas Salidas
Descripcin de la solucin. Catlogo de requisitos. Catlogo de normas y estndares. Catlogo de usuarios. Estndares y normativas de la instalacin. Estructura de datos del sistema origen.

Catlogo de requisitos. Glosario. Contexto del sistema. Modelo de negocio. Modelo de dominio. Modelo de casos de uso. Descripcin de subsistemas. Resultado del anlisis de consistencia. Modelo de clases. Interfaces de usuario.
Un segundo ejemplo de Mtrica

Sokoban
Cliente.

Un juego de escritorio? En Internet? Para mviles? Para PDAs? Para televisin interactiva?. (Juego Internet) Cliente rico?. HTML estndar?. (Juego Mvil) Java?. Smbian? Requisitos de accesibilidad para personas con minusvalas?
EVS.
EVS.
Modelo de dominio.

Iniciar partida
Mover jugador Usuario
Reiniciar nivel
ASI.
Nombre Descripcin Precondicin Secuencia principal
01- Iniciar partida El usuario desea iniciar una nueva partida de Sokoban. Ninguna 01 02 03 El usuario solicita comenzar una nueva partida. El sistema carga el nivel inicial. El sistema muestra la pantalla de juego y espera a que el usuario realice un movimiento (Caso de uso 02).
Modelo de requisitos.
Errores / Alternativas Postcondicin Notas
No Partida iniciada No
ASI.
Modelo de anlisis.
ASI.
Modelo de anlisis (ms detallado).
ASI.
Modelo de datos.

2.4 2.1 2.2
MOVER JUGADOR
Analizar pulsacin de tecla
MOVIMIENTO IDENTIFICADO
Mover imagen jugador
MOVER CAJA
Movimiento de elementos
CAMBIAR POSICION JUGADOR
NIVELES
CAMBIAR POSICIN CAJAS
2.3
MOSTRAR NIVEL
ASI. Modelo de procesos (fragmento).
Dibujar pantalla
FIN DEL MOVIMIENTO
Proceso mover jugador.
Definicin del sistema

Esta actividad tiene como objetivo efectuar una descripcin del sistema, delimitando su alcance, estableciendo las interfaces con otros sistemas e identificando a los usuarios representativos.

Caso prctico: Catlogo de normativas para funcionarios. Las normativas se agruparn segn el RPT. Cada funcionario debe conocer las normativas de su RPT.

Catlogo de normativas para funcionarios. Proceso de negocio. As tendra que ser una prueba de sistema / aceptacin.
Funcionario Registrador Administrador
Registrar normativa
[Normativa]
Autorizar normativa
Consultar normativa
Establecimiento de los requisitos
10

Definicin, anlisis y validacin de los requisitos a partir de la informacin facilitada por el usuario. Participantes: Analistas, usuarios expertos. Tcnicas y prcticas: Sesiones de trabajo, catalogacin, casos de uso.
Establecimiento de requisitos
11

Las sesiones de trabajo pueden ser de varios tipos en funcin de las personas que participen en ellas, el objetivo que se persiga y el modo de llevarlas a cabo
JAD (Joint Application Design) JRP (Joint Requirements Planning)
. Reuniones. Los grandes protagonistas son los usuarios. Es por tanto vital su participacin activa en las mismas.
Entrevistas

Un caso de uso es una secuencia de acciones realizadas por actores y el sistema, que producen un resultado observable y valioso para un actor en particular. Es decir, representa el comportamiento del sistema con el fin de dar respuestas a los usuarios.
12

Ejemplo:
Sacar dinero de un cajero automtico Actores: el usuario del cajero. Sistema bajo estudio: el cajero automtico. Objetivo del actor: obtener dinero en metlico de su cuenta bancaria.
Cules son los actores?. Cul es el sistema?. Cul es el resultado de valor?.
Establecimiento de casos de uso

Despus de las entrevistas, hemos identificado los casos de uso del sistema de normativas.
Suscribirse a avisos de normativa Ver una normativa Consultar normativas
Funcionario
<<extend>>
Registrar normativa <<include>> <<include>> <<include>> Acceso al sistema Reemplazar normativa <<include>>
Borrar normativa Registrador
Administrador
Aprobar normativa
13
!!
Tenemos un problema. Los diagramas UML de casos de uso:

No me indican los pasos que hay que dar para realizar el caso de uso. No indican precondiciones o poscondiciones. No indican escenarios alternativos ni tratamiento de errores.
Plantillas / patrones de casos de uso.
14

Ve r una norm ativ a
<<extend>> Funcionario Consultar norm a tiv as
Error / alternativas
Post condition Prioridad
UC-02. Consultar normativa No. 1 El funcionario solicita consultar las normativas. 2 El sistema solicita el puesto de trabajo del funcionario. 3 El actor introduce su puesto de trabajo. 4 El sistema busca todas las normativas asociadas al puesto de trabajo. 5 El sistema muestra las normativas. 3.1 Si el puesto de trabajo introducido no existe, entonces el sistema muestra un mensaje de error y repite el paso 2. 4.1. Si no existe ninguna normativa para dicho puesto de trabajo el sistema muestra un mensaje y este caso de uso termina. 5.1. Si el usuario desea consultar una normativa concreta, se ejecuta el caso de uso UC-03. Ver una normativa. No. Alta.
Nombre Descripcin Precondicin Secuencia principal Error / alternativas
UC-03. Ver una normativa Se ha ejecutado el caso de uso UC-02 y se ha seleccionado una normativa. 1 El funcionario selecciona una normativa. 2 El sistema muestra toda la informacin de la normativa. 2.1 Si hay un error recuperando la informacin de la normativa, entonces el sistema informa de que dicha normativa est temporalmente de baja, se enva un mensaje de correo electrnico al usuario administrador y este caso de uso termina. 2.2. En cualquier momento, el usuario puede descargar el PDF de la normativa. No. Alta.
Registrar normativa <<include>> <<include>> <<include>> Acceso al sistema Reemplazar normativa <<include>>
Administrador
Aprobar normativa
Error / alternativas Post condition Prioridad
UC-01. Acceso al sistema No. 1 El actor solicita el acceso al sistema. 2 El sistema solicita su nombre de usuario y su clave. 3 El actor introduce su nombre de usuario y clave. 4 El sistema valida el nombre de usuario y la clave. 5 El sistema permite el acceso al actor. 4.1 Si el nombre de usuario o la contrasea no son correctos, el sistema muestra un error y repite el paso 2.. Actor registrador o administrador validado.. Media.
15

Los casos de uso no son los nicos requisitos que podemos especificar en plantillas.
Requisitos no funcionales. Requisitos de almacenamiento de informacin. Requisitos de interfaz grfica. Objetivos. Requisitos de navegacin. Etc...
Nombre Descripcin Datos especficos RI-01. Normativas Nombre y descripcin Identificador Fecha de alta Nombre de la normative Puesto al que corresponde Documento PDF
Qu tipos de requisitos se nos ocurren?
Naturaleza Entero, autogenerado, nico Fecha Cadena Puesto Fichero binario.

Consejos para escribir casos de uso. Texto breve. Palabras y frases sencillas. Utilizar la jerga de nuestro cliente. No hacer literatura. Emplear verbos de accin en presente. Construir frases completas con sujeto y predicado. No emplear abreviaturas (salvo que sean de la jerga). Hilvanar bien la historia que contamos. Resultados para los actores participantes !!!.
16
Anlisis de requisitos: Repasar los requisitos para detectar inconsistencias, ambigedades, omisiones, duplicidades etc. Validacin de requisitos: Repasar los requisitos con los usuarios para ver si son vlidos, consistentes y completos.
Identificacin de subsistemas de anlisis

Descomponer el sistema en subsistemas.
17

Criterios para identificar subsistemas.
Procesos de negocio. Homogeneidad de procesos. Servicios comunes. Prioridad. Afinidad de requisitos. Localizacin geogrfica.

Subsistema de funcionarios Suscribirse a avisos de normativa Ver una normativa
Subsistema de funcionarios
Funcionario
Consultar normativas
<<extend>>
Subsistema de registradores Registrar normativa <<include>> <<include>> <<include>> Acceso al sistema Reemplazar normativa <<include>>
Subsistema de registradores
Subsistema de administracin Aprobar normativa
Subsistema de administracin
Administrador
!!
No es una descomposicin muy ilustrativa.
18

Homogeneidad de operaciones.
Suscribirse a avisos de normativa Ver una normativa
Funcionario
<<extend>>
Subsistema de registradores Registrar normativa <<include>> <<include>> <<include>> Acceso al sistema Reemplazar normativa <<include>>
Subsistema de consulta de ediciones
Subsistema de administracin Aprobar normativa
Administrador
Subsistema de edicin de notificacines
Subsistema de servicios comunes

Agrupa los elementos del Modelo de Diseo, Anlisis, o
Construccin con el objeto de obtener una visin ms clara. Contiene los siguientes elementos:
Paquetes: agrupacin de elementos, casos de uso, clase o componentes Dependencias entre paquetes
Paquete de Negocio Paquete BD + Ejemplar + Prstamo + Ttulo + Informacin del prestatario + Ttulo del libro + Reserva + Ttulo de la revista + Persistencia
Paquete GUI + Ventana de Prstamos + Ventana de Devoluciones + Ventana de Reservas + Ventana de Mantenimiento
Paquete de Utilidad + ObjetoID
19

Integracin de subsistemas.
Subsistema de consulta de ediciones
Consultas
Subsistema de edicin de notificacines
Subsistema de servicios comunes
Acceso al sistema
Por simplicidad, no usaremos una divisin en subsistemas.
Anlisis de casos de uso
20

Identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la interaccin dichos objetos.

Utilizamos diagramas de clases en PSI, EVS, ASI y DSI. Cul es el objetivo de los diagramas de clases en cada uno de esos procesos?.
Veamos un ejemplo.
21
Descripcin del problema

Sokoban
Cliente.
Requisitos
22
Anlisis

Nombre Descripcin Precondicin Secuencia principal UC-02. Consultar normativa No. 1 El funcionario solicita consultar las normativas. 2 El sistema solicita el puesto de trabajo del funcionario. 3 El actor introduce su puesto de trabajo. 4 El sistema busca todas las normativas asociadas al puesto de trabajo. 5 El sistema muestra las normativas. 3.1 Si el puesto de trabajo introducido no existe, entonces el sistema muestra un mensaje de error y repite el paso 2. 4.1. Si no existe ninguna normativa para dicho puesto de trabajo el sistema muestra un mensaje y este caso de uso termina. 5.1. Si el usuario desea consultar una normativa concreta, se ejecuta el caso de uso UC-03. Ver una normativa. No. Alta.
1: Informacin necesaria.
Norma +Id +Nombre +PuestoAsociado
2: Operaciones.
ConsultaNormas +consultar(puestoTrabajo)
3: Interfaces.
FormularioConsultaNormas
FormularioResultadoNormas
23

Ahora, todo junto.
Notacin tradicional.
FormularioConsultaNormas ConsultaNormas +consultar(puestoTrabajo)
Notacin especfica de anlisis (RUP).
ConsultaDeNormas
ConsultarNormas
Norma FormularioResultadoNormas * Mostrar * +Id +Nombre +PuestoAsociado
ResultadoNormas
UnaNorma
Se podran aadir ms relaciones, pero lo haremos ms adelante.

Nombre Descripcin Precondicin Secuencia principal Error / alternativas UC-03. Ver una normativa Se ha ejecutado el caso de uso UC-02 y se ha seleccionado una normativa. 1 El funcionario selecciona una normativa. 2 El sistema muestra toda la informacin de la normativa. 2.1 Si hay un error recuperando la informacin de la normativa, entonces el sistema informa de que dicha normativa est temporalmente de baja, se enva un mensaje de correo electrnico al usuario administrador y este caso de uso termina. 2.2. En cualquier momento, el usuario puede descargar el PDF de la normativa. No. Alta.
1: Informacin necesaria.
Norma +Id +Nombre +PuestoAsociado +FechaAlta +DocumentoPDF
2: Operaciones.
VerDetalleNorma
Nombre Descripcin Datos especficos
RI-01. Normativas Nombre y descripcin Identificador Fecha de alta Nombre de la normative Puesto al que corresponde Documento PDF
Naturaleza Entero, autogenerado, nico Fecha Cadena Puesto Fichero binario.
3: Interfaces.
FormularioDetalleNorma
Otro caso de uso nos da ms informacin de una clase ya identificada.
24

Ahora, todo junto.
ConsultaDeNormas
ConsultarNormas
A medida que aadimos nuevos elementos, refinamos los diagramas.
ConsultarDetalleNormas
DetalleDeNorma
ConsultaDeNormas 1 0..*
ConsultarNormas
ENorma ResultadoNormas
DetalleDeNorma
ENorma ResultadoNormas

Despus de analizar varios casos de uso.
FormularioConsultaNormas ConsultaNormas +establecerPuesto(puesto) +consultar() +mostrarResultados() +verDetalleNorma(norma) * VerDetalleNorma Registrador Norma * FormularioDetalleNorma +Id +Nombre +PuestoAsociado +FechaAlta +DocumentoPDF +REgistrada Administrador 1 1 +consultar(puestoTrabajo) Funcionario ActorPrivilegiado +Nombre +Clave
Completa, Solapada
Registrada por 1 *
FormularioDeAcceso
ValidarActor +validas(nombre, clave)
Todava no es necesario tener el diagrama tan avanzado.
25

Ejercicios de diagramas de clases.
1. Ejercicio pequeo. 2. Anlisis de nuestros casos de uso.
Al menos seis clases. Al menos una boundary, entity y control. Utilizar las dos notaciones.
La segunda tarea la veremos ms adelante.
26
Anlisis de clases
Anlisis de clases
Describir cada una de las clases que ha surgido, identificando las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas.
27
Anlisis de clases
Responsabilidades de una clase: definen la funcionalidad de esa clase, y estn basadas en el estudio de los papeles que desempean sus objetos dentro de los distintos casos de uso. A partir de estas responsabilidades, se puede comenzar a encontrar las operaciones que van a pertenecer a la clase. Estas deben ser relevantes, simples, y participar en la descripcin de la responsabilidad.
Anlisis de clases
Patrones para la definicin de clases.
CA-01 Descripcin Responsabilidades * FormularioConsultaNormas . Permitir a los actores del sistema realizar una consulta de normas. Permitir a los actores del sistema ver el detalle de una norma. Descripcin Significado Descripcin Significado establecerPuesto Consultar verDetalleNorma
Atributos Operaciones
Antes.
Despus.
+establecerPuesto(puesto) +consultar() +mostrarResultados() +verDetalleNorma(norma)
28
Anlisis de clases
Clase (estructura).
FormularioConsultaNormas +establecerPuesto(puesto) +consultar() +mostrarResultados() +verDetalleNorma(norma)
Para definir el comportamiento interno de las clases ms complejas utilizamos mquinas de estados.
Clase FormularioConsultaNormas
Mquina de estados (comporamiento).

EnEspera establecerPuesto ListoParaConsultar consultar RealizarConsulta [ NoExistenNormativas ] / Mensaje de error
[ ExistenNormativas ] / MostrarResultados NoVerDetalles ConsultaRealizada VerDetalles / Llamar a ver detalles
Anlisis de clases
A lo largo del ASI podemos ir refinando nuestras clases.
ActorRegistrado +Nombre +Clave
Completa, Solapada
ActorRegistrado: Almacenar informacin de cada uno de los actores que tienen privilegios especiales.
Administrador
Registrador
ValidarActor: Comprobar si un actor est registrado como ActorPrivilegiado

ActorPrivilegiado +Nombre +Clave +validar()
29
Anlisis de clases
Las relaciones (asociaciones, agregaciones, generalizaciones, etc.) ya las tenemos puestas en nuestro diagrama. Este es un buen momento para repasarlas.
Tenamos esta tarea pendiente. Ahora que sabemos las operaciones de cada clase podemos completarla
30

Funcionario
ConsultaNormas
1 : establecerPuesto() 2 : Consultar()
3 : Consultar()
4 5
ActorPrivilegiado +Nombre +Clave +validar() Completa, Solapada * VerDetalleNorma Registrador Norma * FormularioDetalleNorma +Id +Nombre +PuestoAsociado +FechaAlta +DocumentoPDF +REgistrada +Id +Nombre +Clave 1 * Administrador
FormularioConsultaNormas ConsultaNormas +establecerPuesto(puesto) +consultar() +mostrarResultados() +verDetalleNorma(norma) 1 1 +consultar(puestoTrabajo)
Funcionario
Registrada por
FormularioDeAcceso

Mensajes
: Bibliotecario
: Ttulo : Ventana de Prstamos 1: encontrar ttulo ( ) 2: encontrar (String)
: Informacin : Prstamo del prestatario
: Ejemplar
3: encontrar ejemplar ( )
4: encontrar sobre ttulo (Ttulo)
5: identificar prestatario ( ) 6: encontrar (String) 7: crear(informacin del prestatario, ejemplar)

Focos de control:perido en el que el objeto esta ejecutando una accion
LINEA DE VIDA:existencia del objeto
OBJETOS
31

FormularioConsultaNormas ConsultaNormas +establecerPuesto(puesto) +consultar() +mostrarResultados() +verDetalleNorma(norma) * VerDetalleNorma Registrador Norma * FormularioDetalleNorma +Id +Nombre +PuestoAsociado +FechaAlta +DocumentoPDF +REgistrada +Id +Nombre +Clave 1 * Administrador 1 1 +consultar(puestoTrabajo) Funcionario ActorPrivilegiado +Nombre +Clave +validar() Completa, Solapada
Registrada por
FormularioDeAcceso
Establecer puesto Funcionario Consultar FormularioConsultaNormas
Consultar
ConsultaNormas
Selecciona
Object1 Object2 Norma

:Ttulo
OBJETO MENSAJE
2: encontrar (String) 1: encontrar ttulo () 3: encontrar ejemplar () 5: identificar prestatario ()
:Ejemplar
:Ventana de Prestamos
4: encontrar sobre ttulo (Ttulo)
6: encontrar (String)
:Bibliotecario
7: crear (informacin del prestatario ,ejemplar)
?:Informacin del Prestatario
:Prstamo
VINCULO:une objetos y tiene asociado varios mensajes
32

Nombre Descripcin Precondicin Secuencia principal Error / alternativas UC-03. Ver una normativa Se ha ejecutado el caso de uso UC-02 y se ha seleccionado una normativa. 1 El funcionario selecciona una normativa. 2 El sistema muestra toda la informacin de la normativa. 2.1 Si hay un error recuperando la informacin de la normativa, entonces el sistema informa de que dicha normativa est temporalmente de baja, se enva un mensaje de correo electrnico al usuario administrador y este caso de uso termina. 2.2. En cualquier momento, el usuario puede descargar el PDF de la normativa. No. Alta. Son
menos pasos que el anterior pero necesitamos ms llamadas y ms objetos.

Funcionario FormularioConsultaNormas VerDetalleNorma FormularioDetalleNorma
1 : verDetalleNormativa() 2 : verDetalleNormativa() 3 : mostrarDetalleNorma()

Ejercicios de diagramas de clases.
1. Vamos a llevar nuestro diagrama de clases hasta el lmite.
Una generalizacin. Una composicin. Nombres y multiplicidades para la mayora de las relaciones. Un diagrama de secuencia?.
Cuntas clases tendramos en el anlisis de un sistema?.
33
Elaboracin del modelo de datos
34

El modelo de datos se elabora mediante un enfoque descendente (top-down). A partir del modelo conceptual de datos (si existe), se elabora un ER extendido y normalizado con las entidades necesarias para cumplir la funcionalidad del sistema y se aaden al modelo. Se especifica la necesidad de una migracin y carga inicial de datos. Esto se refinar en el DSI.
35

El modelo lgico es un refinamiento del modelo conceptual en el que se ha resuelto:
Resolver las relaciones complejas entre las distintas entidades. Eliminar las relaciones redundantes que puedan surgir como consecuencia de la resolucin de las relaciones complejas. Eliminar cualquier ambigedad sobre el significado de los atributos. Identificar las relaciones de dependencia entre entidades . Completar la informacin de las entidades y los atributos. Revisar y completar los identificadores de cada entidad.

Normalizacin: eliminacin de dependencias entre atributos que originen anomalas en la actualizacin de los datos, y proporcionar una estructura ms regular para la representacin de las tablas. Cul es la gran pega de la normalizacin?.
36

Se trata de una tcnica cuyo objetivo es la representacin y definicin de todos los datos que se introducen, almacenan, transforman y producen dentro de un sistema de informacin, sin tener en cuanta las necesidades de la tecnologa existente, ni otras restricciones. Las ventajas de realizar un modelo de datos son: Compresin de los datos de una organizacin y del funcionamiento de la organizacin. Obtencin de estructuras de datos independientes del entorno fsico. Control de posibles errores desde el principio, o al menos, darse cuenta de las deficiencias lo antes posible. Mejora del mantenimiento. EMPLEADO DEPARTAMENTO

Los elementos fundamentales del modelo son: Entidad:OBJETO real o abstracto sobre el cual se desea almacenar informacin. Las reglas que deben cumplir son: tienen que tener existencia propia
cada ocurrencia de un tipo de entidad debe poder distinguirse de las dems todas las ocurrencias de un tipo de entidad deben tener los mismos atributos. Tipo de Entidad: estructura genrica de un conjunto de entidades con las mismas caractersticas. Interrrelacin(Relacin): es una asociacin o correspondencia entre una o varias entidades.
37

Una Interrelacin se caracteriza por:
nombre: que lo distingue del resto de las relaciones tipo de ocurrencia: numero mximo de ocurrencias de cada Tipo de Entidad que interviene en una ocurrencia: Interrelaciones(1,1): cada ocurrencia de una entidad se relaciona con una y solo una ocurrencia de la otra entidad Interrelaciones(1,N): cada ocurrencia de una entidad puede estar relacionada con cero, una o varias ocurrencias de la otra entidad Interrelaciones(M,N): cada ocurrencia de una entidad puede estar relacionada con cero, una o varias ocurrencias de la otra, y viceversa. Cardinalidad: numero mximo y mnimo de ocurrencias de un Tipo de Entidad que pueden estar relacionadas con una ocurrencia de otro Tipo de Entidad . La cardinalidad mxima coincide con el tipo de correspondencia.

Dominio: conjunto nominado de valores homogneos Atributo:propiedad o caracterstica de un tipo de entidad. Cada Tipo de Entidad ha de tener un conjunto mnimo de atributos que identifican unvocamente cada ocurrencia del Tipo de Entidad, denominado identificador principal
38

La representacin grfica de las cardinalidades admite dos tipos de notacin:
Mediante una etiqueta del tipo (0,1), (1,1), (0,n) o (1,n), que se coloca en el extremo de la entidad que corresponda. Si se representan las cardinalidades, la representacin del tipo de correspondencia es redundante. Grficamente, mediante un crculo que indica la opcionalidad de la interrelaccin. De acuerdo al ejemplo anterior, la representacin sera la siguiente:

La teora de la Normalizacin tiene por objetivo la eliminacin de dependencias entre atributos que originan anomalas en la actualizacin de los datos y proporciona una estructura mas regular para la representacin de la tablas, constituyendo el soporte para el diseo de bases de datos relacionales. Aplicando esta tcnica se obtiene el modelo lgico de datos normalizado. Una relacin esta en una determinada forma Normal si satisface un cierto conjunto de retricciones sobre los atributos.
39

FUNCIONAL: un atributo Y depende funcionalmente de otro X si, y solo si, a cada valor de X le corresponde un nico valor de Y. COMPLETA: un atributo Y tiene dependencia funcional completa respecto de otro X, si depende funcionalmente de el en su totalidad, es decir no depende de ninguno de los atributos que formen parte de X. TRANSITIVA: un atributo depende transitivamente de otro si, y solo si, depende de el a travs de otro atributo.

PRIMERA FORMA NORMAL(1FN): una entidad est en 1FN si no tiene grupos repetitivos, es decir, un atributo solo puede tomar un nico valor de un dominio simple. SEGUNDA FORMA NORMAL(2FN): una entidad est en 2FN si esta en 1FN y todos los atributos que no forman parte de las claves candidatas ( atributos no principales ) tienen dependencia funcional completa respecto de stas. TERCERA FORMA NORMA(3FN): una entidad est en 3FN si est en 2FN y todos sus atributos no principales depende directamente de la clave primaria.
40
Elaboracin del modelo de procesos
41

Se analizan las necesidades del usuario para establecer el conjunto de procesos que conforma el sistema de informacin. Para ello, se realiza una descomposicin de dichos procesos siguiendo un enfoque descendente (top-down)

Se elabora una especificacin para cada proceso primitivo, especificacin que permita conocer en detalle el
Tipo de tratamiento (en lnea o por lotes), Operativa asociada, Restricciones y limitaciones del proceso. Caractersticas de rendimiento relevantes. Frecuencia de ejecucin, Procesos asociados Tiempos mximos de respuesta, Franja horaria Perodos crticos, Nmero mximo de usuarios concurrentes, etc.
Este anlisis permite establecer los criterios de distribucin de los componentes software al definir la arquitectura fsica del sistema. Tambin se debe especificar qu procesos van a estar bajo control del usuario y cules bajo control del sistema.
42

Especificacin de interfaces con otros sistemas
Procesos del sistema de informacin asociados. Especificaciones funcionales de los sistemas origen o destino. Formatos de los datos intercambiados. Aspectos operativos de la interfaz: en lotes o en lnea y medio fsico utilizado. Frecuencia o periodicidad del intercambio. Evento que desencadena la interfaz. Validaciones, requisitos especiales de seguridad, etc. Modificaciones o adaptaciones necesarias en los sistemas origen o destino.
No hay una tcnica / prctica definida.
Identificacin de perfiles y dilogos

1. Se identifican los distintos perfiles de usuario. 2. Se identifican todos los procesos del DFD que requieren una comunicacin con usuarios. 3. Se descomponen en dilogos. 4. Se asignan los dilogos a los perfiles de usuario.
Si hemos trabajado con casos de uso, los perfiles deben ser los actores.
43
Diagramas de flujos de datos

El objetivo del diagrama de flujo de datos es la obtencin de un modelo lgico de procesos que represente los requisitos del sistema con independencia de las restricciones fsicas del entorno. Permite representar grficamente la lgica de procesos, mostrando el flujo o movimiento de los datos a travs del sistema as como las transformaciones que pueden sufrir como resultado de la ejecucin de dichos procesos.
EXT 1 EXT 2
EXT 3
EXT 4

Elementos: ENTIDAD EXTERNA: Ente AJENO al sistema, pero que suministra o recibe informacin del mismo. (Ej.: Ciudadano, Ministerio, Otras Consejeras...) PROCESO: FUNCIN que transforma o manipula datos (Ej.: Archivar, Buscar ...) ALMACN DE DATOS: DEPSITO de informacin en el sistema (Ej.: Archivo) FLUJO DE DATOS: COMUNICACIN entre procesos, almacenes y entidades externas (tubera de informacin) (Ej.: Solicitudes)
44

MODELO DE PROCESOS: conjunto de DFD de diferentes niveles de abstraccin, de modo que cada uno proporciona una visin mas detallada de una parte definida en el nivel anterior. Contiene: Diagrama de Contexto(nivel 0). Varios DFD en niveles intermedios. Varios DFD en el ultimo nivel de detalle.

NOTACIN: ENTIDAD EXTERNA:
A1 CLIENTE
PROCESO
ID LOCALIZACIN
NOMBRE DEL PROCESO
ALMACEN
ID NOMBRE
FLUJO
NOMBRE DEL FLUJO DE DATOS
45
HABILITACIN
EMPLEADOS
Datos Personal Estructura, Nminas, Parmetros
Datos Procesados, Informes 0 CONSEJERA
Nominillas, certificados
NMINA
Modelos Oficiales rdenes de transferencia
BANCOS
ESTADO
DIAGRAMA DE CONTEXTO
FLUJO DE DIALOGO
Datos personal Datos bsicos
P1 PERSONAL
D1
EMPLEADOS
HABILITACIN
Datos personal procesados,info rmes Datos estructura
Datos Incidencias
D2
INCIDENCIAS
Datos estructura procesados, informes
Datos plazas
P2 ESTRUCTURA
Datos servicios
D3
PLAZAS
D4
SERVICIOS
DIAGRAMA DE SUBSISTEMAS (I)
46
Datos parmetros
P3 PARAMETROS
Datos conceptos
D5
CONCEPTOS
D1
EMPLEADOS
HABILITACIN
Datos parmetros procesados,inform es Datos nminas
Datos grupos
D6
GRUPOS
D2
INCIDENCIAS
D3
PLAZAS
Datos nminas procesados, informes Nominillas, certificados
P4 CLCULOS
Modelos oficiales Datos nminas rdenes transferencia
D7
NOMINAS
EMPLEADOS
FLUJO DE CONSULTA ESTADO BANCOS
DIAGRAMA DE SUBSISTEMAS (II)
Definicin de interfaces de usuario
47
Especificar las interfaces entre el sistema y el usuario: formatos de pantallas, dilogos, e informes, principalmente.

Principios generales de la interfaz:
Directrices generales en cuanto a la interfaz y aspectos generales de interaccin. Principios de composicin de pantallas y criterios de ubicacin de los distintos elementos dentro de cada formato. Normas para los mensajes de error y aviso, codificacin, presentacin y comportamientos. Normas para la presentacin de ayudas. Hay que establecer criterios similares para la interfaz impresa.
48

Principios generales de la interfaz / catlogo de normativas: Interfaz grfica, manipulable mediante ratn y teclado. Interfaz HTML compartible con HTML 4.1 Transactional. Nivel AAA de accesibilidad. Todos los mensajes de error se mostrarn en ventanas emergentes. Etc
Normativas.

Especificacin de formatos de la interfaz de pantalla:
Todo caso de uso debe completarse con una interfaz de usuario.
Consultar normativas Funcionario
49

Especificacin de formatos de la interfaz de pantalla:
Existen muchas formas de especificar una interfaz.
Tambin podemos usar plantillas.

Tambin definimos formularios adicionales.
Suscribirse a avisos de normativa Ver una normativa
Funcionario
<<extend>>
50

Comportamiento dinmico de la interfaz:
El objetivo de esta tarea es definir los flujos entre los distintos formatos de interfaz de pantalla, y tambin dentro del propio formato. Este comportamiento se describe mediante un modelo de navegacin de interfaz de pantalla.
Interfaces para funcionarios
Men principal
Bsqueda de normativa Subscripcin a avisos
Ver detalle de normativa
51
Terminar el ASI.
Terminar el ASI
52
Terminar el ASI
Anlisis de consistencia: 1. 2. 3. 4. 5. 6. 7. Cul es el objetivo del anlisis de consistencia?. Cules son las acciones a desarrollar?. Qu obtenemos al final del anlisis de consistencia?. Cmo verificaramos los modelos del ejemplo que hemos hecho?. Cmo se hace un anlisis de consistencia?. Qu comprobamos en un anlisis de consistencia de un desarrollo orientado a objetos?. Cul es la mejor manera de que los usuarios validen los modelos?
Terminar el ASI
Elaboracin de la especificacin de requisitos software.
Introduccin. mbito y alcance. Participantes. Requisitos del sistema de informacin. Visin general del sistema de informacin. Referencia de los productos a entregar. Plan de accin.
53
Terminar el ASI
Especificacin del plan de pruebas:
1. Segn Mtrica, qu es un plan de pruebas?. 2. En el ASI construimos un plan de prueba completo?. 3. Cul es el objetivo de esta actividad?. 4. Qu niveles de prueba contempla Mtrica 3?. 5. En qu niveles se profundiza ms?. 6. Qu engloba el alcance de las pruebas?. 7. Qu es el entorno de pruebas?. 8. Cules son los criterios de aceptacin del sistema?
Terminar el ASI
Anlisis de consistencia:
Funcionario FormularioConsultaNormas ConsultaNormas
1 : establecerPuesto()
ConsultaNormas 1 +consultar(puestoTrabajo)
2 : Consultar()
3 : Consultar()
+establecerPuesto(puesto) +consultar() +mostrarResultados() +verDetalleNorma(norma)
4 5
Tambin podemos comprobarlo de forma matricial.
54
Conclusiones.
Conclusiones
Esto no se hace de manera secuencial !!!! No hay un orden claro para realizar ASI 2 8. Tampoco hay una divisin clara de qu hacer en cada momento. Tampoco hay un criterio claro de hasta dnde llegar Debemos tener una metodologa de anlisis. Esto nos da libertad.
55
Conclusiones
El modelo lgico de datos puede ser una vista del modelo de clases
ActorPrivilegiado +Nombre +Clave +validar()
Registrador Norma +Id +Nombre +PuestoAsociado +FechaAlta +DocumentoPDF * Registrada por 1
Norma +Id +Nombre +PuestoAsociado +FechaAlta +DocumentoPDF +REgistrada ActorPrivilegiago Registrada por * 1 +Id +Nombre +Clave +Tipo
El tipo debe ser Registrador
Conclusiones
Diagrama de actividades. Diagrama de colaboracin /interaccin. Diagrama de clases. Diagrama de secuencia. Diagrama de componentes. Diagrama de estados Diagrama de casos de uso.
Diagramas de UML.
56
Conclusiones
Diagrama de comunicacin. Diagrama de composicin estructural. Diagrama de despliegue. Diagrama de objetos. Diagrama de paquetes. Diagrama de tiempos. 13 tipos de diagramas.
57

Asi

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Asi

Загружено:

Авторское право:

Доступные форматы

Anlisis de sistemas de Informacin en la prctica

Javier Gutirrez javierj@us.es

Objetivo: Desarrollar un ASI aplicando tcnicas de desarrollo estructurado y de orientacin a objetos.

Un resumen del proceso

Un resumen del proceso ASI

Un resumen del proceso ASI

Un segundo ejemplo de Mtrica

Un segundo ejemplo de Mtrica

Un segundo ejemplo de Mtrica

Un segundo ejemplo de Mtrica

Mover jugador Usuario

Nombre Descripcin Precondicin Secuencia principal

Errores / Alternativas Postcondicin Notas

Un segundo ejemplo de Mtrica

Un segundo ejemplo de Mtrica

Modelo de anlisis (ms detallado).

Un segundo ejemplo de Mtrica

Un segundo ejemplo de Mtrica

Analizar pulsacin de tecla

Mover imagen jugador

CAMBIAR POSICION JUGADOR

CAMBIAR POSICIN CAJAS

ASI. Modelo de procesos (fragmento).

FIN DEL MOVIMIENTO

Proceso mover jugador.

Definicin del sistema

Definicin del sistema

Definicin del sistema

Definicin del sistema

Definicin del sistema

Establecimiento de los requisitos

Establecimiento de los requisitos

Establecimiento de los requisitos

Establecimiento de los requisitos

Establecimiento de los requisitos

Cules son los actores?. Cul es el sistema?. Cul es el resultado de valor?.

Establecimiento de casos de uso

Borrar normativa Registrador

Tenemos un problema. Los diagramas UML de casos de uso:

Establecimiento de casos de uso

<<extend>> Funcionario Consultar norm a tiv as

Post condition Prioridad

Nombre Descripcin Precondicin Secuencia principal Error / alternativas

Post condition Prioridad

Borrar normativa Registrador

Nombre Descripcin Precondicin Secuencia principal

Error / alternativas Post condition Prioridad

Establecimiento de casos de uso

Qu tipos de requisitos se nos ocurren?

Naturaleza Entero, autogenerado, nico Fecha Cadena Puesto Fichero binario.

Establecimiento de casos de uso

Identificacin de subsistemas de anlisis

Identificacin de subsistemas de anlisis

Identificacin de subsistemas de anlisis

Borrar normativa Registrador

Subsistema de administracin Aprobar normativa

No es una descomposicin muy ilustrativa.

Identificacin de subsistemas de anlisis

Suscribirse a avisos de normativa Ver una normativa

Borrar normativa Registrador

Subsistema de consulta de ediciones

Subsistema de administracin Aprobar normativa

Subsistema de edicin de notificacines

Subsistema de servicios comunes