CORPORACION UNIVERSITARIA AUTONOMA DEL CAUCA

1
CORPORACION UNIVERSITARIA AUTONOMA DEL CAUCA

• LOS SISTEMAS DE INFORMACION GEOGRAFICA, UNA
  HERRAMIENTA DE PLANIFICACION PARA EL DESARROLLO
  TERRITORIAL

Bienvenidos
2
FLUJOS DE TRABAJO
CICLO DE VIDA CLÁSICO
1. Análisis de sistemas. En esta etapa se deberán
utilizar las herramientas para la recolección de
datos como Cuestionarios, Entrevistas, Revisión
de Documentos y Observación, y representar la
información recabada en diagramas de procesos
como Yourdon, Hipo, Tablas, Arboles, etc.
3
FLUJOS DE TRABAJO

• 2. Diseño de sistemas. En esta etapa deberá
  realizarse diseño de
• Salidas (reportes por pantalla o impresora).
• Entradas (interfaces).
• Bases de datos con diagramas de dependencias
  funcionales para explicar la normalización,
  definer restricciones de integridad de la base de
  datos y para representar el esquema completo de
  la base de datos podrá utilizar diagramas
  entidad/relación Toma de decisiones con tablas o
  árboles.
• .

4
FLUJOS DE TRABAJO
3. Programación. En esta etapa se podrá presentar
el código del programa, siempre y cuando la
empresa lo autorice, si la empresa no autoriza
deberá presentarse una carta donde lo justifique
la empresa, sin embargo al final de la residencia
deberá mostrar el programa funcionando.
5
FLUJOS DE TRABAJO
4. Implantación. En esta etapa deberá indicarse
el método que se recomienda utilizar como por
ejemplo implantación directa, por etapas, enfoque
piloto o en paralelo.   5. Pruebas. Especificar
los tipos de pruebas que habrá que realizar al
sistema.  
6
FLUJOS DE TRABAJO
METODOLOGIA ORIENTADA A OBJETOS PROCESO
UNIFICADO DE DESARROLLO (RUP) Basado en UML  

• Una metodología de desarrollo de software OO
  consta de los siguientes elementos
• Conceptos y diagramas ( Modelo)
• Etapas y definición de entrega en cada una de
  ellas.
• Actividades y recomendaciones.

7
FLUJOS DE TRABAJO

• 1. Análisis de requerimientos.
• En esta etapa se busca las necesidades del
  usuario y la forma que se va a presentar la
  solución.
•  
• Actividades
• Identificar los casos de uso del Sistema (
  descripción textual )
• Dar detalle a los casos de usos ( diagrama )
• Definir una interfaz inicial del sistema ( si es
  aplicable )

8
FLUJOS DE TRABAJO

• d. Desarrollar el modelo del mundo ( diagrama de
  clases )
•         Identificar clases
•         Atributos
•         Operaciones
•         Relaciones ( asociación, herencia,
  composición y uso )
•         Cardinalidad
•  
• e. Validar los modelos ( con el cliente clases,
  atributos, operaciones y crear diagrama de
  secuencia o de colaboración )

9
FLUJOS DE TRABAJO
2. Diseño del sistema En esta etapa se define una
subdivisión en aplicaciones del sistema y la
forma de comunicación con los sistemas existentes
con los que debe interactuar.  
10
FLUJOS DE TRABAJO
Actividades a. Identificar la arquitectura del
sistema        Definir los componentes del
sistema b.Refinar los casos de usos (
expandidos) aplicados al software. (Textualmente
y en diagrama )  
11
FLUJOS DE TRABAJO
3. Diseño detallado En esta etapa se adecua el
análisis a las características específicas de
ambiente de implementación ( software )  
12
FLUJOS DE TRABAJO

• Actividades
• a. Agregar los detalles de implementación del
  modelo del mundo
•  Completar los detalles de la clase ( diagrama de
  clases )
• Subdividir en paquetes ( diagrama de paquetes )  

13
FLUJOS DE TRABAJO

• b. Desarrollar el modelo de interfaz
• Conocer el ambiente de base
• Enlazar las clases de interfaz con el modelo del
  mundo
• Crear diagrama de interacción ( procesos )
•   Crear diagrama de estados de procesos.
• c. Desarrollar el modelo de control, persistencia
  y comunicaciones relacionado con redes, ambientes
  WEB, etc.

14

• 4. Implementación y pruebas
• Se desarrolla el código
• Actividades
• Definir estándares de programación
•         Lenguajes
•         Directorios
• Codificación y pruebas de unidad
• Pruebas de integración
• Prueba del sistema

 
15
Clasificación de iteraciones
IteraciónIndividual
Elaboracion
Concepción
Construccion
Transicion
Iter. k
Iter. 1
Iter. n
Iter. n1
Iter. m
Iter. m1
Prelim. iterations
..

..
Requerimientos Analisis
Flujos de trabajo básicos (En terminologia
clásica son etapas)
Diseño Implementacion prueba
16
FLUJOS DE TRABAJO
modelo captura una vista de un sistema del mundo
real. Es una abstracción de dicho sistema,
considerando un cierto propósito. Así, el modelo
describe completamente aquellos aspectos del
sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle.
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
17
FLUJOS DE TRABAJO
Diagrama una representación gráfica de una
colección de elementos de modelado, a menudo
dibujada como un grafo con vértices conectados
por arcos
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
18
DIAGRAMAS UML

• Diagrama de Casos de Uso
• Diagrama de Clases
• Diagrama de Objetos
• Diagramas de Comportamiento
• Diagrama de Estados
• Diagrama de Actividad

Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
19
DIAGRAMAS UML

• Diagramas de Interacción
• Diagrama de Secuencia
• Diagrama de Colaboración
• Diagramas de implementación
• Diagrama de Componentes
• Diagrama de Despliegue

Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
20
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
21
FLUJOS DE TRABAJO
PAQUETES Los paquetes ofrecen un mecanismo
general para la organización de los
modelos/subsistemas agrupando elementos de
modelado Se representan gráficamente como
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
22
FLUJOS DE TRABAJO
PAQUETES Se representan gráficamente como
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
23
PAQUETES Cada paquete corresponde a un
submodelo (subsistema) del modelo (sistema) Un
paquete puede contener otros paquetes, sin límite
de anidamiento pero cada elemento pertenece a
(está definido en) sólo un paquete Una clase de
un paquete puede aparecer en otro paquete por la
importación a través de una relación de
dependencia entre paquetes
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
24
FLUJOS DE TRABAJO
REQUERIMIENTOS Son una descripción de la
necesidades o deseos de un producto. La meta es
identificar y documentar lo que en realidad se
necesita, en un forma que claramente se lo
comunique al cliente y a los miembros del equipo
de desarrollo.
Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
25
FLUJOS DE TRABAJO

• REQUISITOS
• El propósito fundamental del flujo de trabajo de
  los requisitos es guiar el dearrollo hacia el
  sistema correcto, mediante una descripción de los
  requisitos (condiciones o capacidades que el
  sistema debe cumplir) suficientemente buena para
  llegar a un acuerdo con el cliente.

Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
26
FLUJOS DE TRABAJO

• REQUISITOS
• El reto fundamental a conseguir es que el cliente
  debe ser capaz de leer y comprender el resultado
  de la captura de requisitos, utilizando un
  lenguaje del cliente para describirlo

Los Sistemas de Información Geográfica, una
herrmamienta de planificación para el desarrollo
territorial 2004
27
FLUJOS DE TRABAJO

• REQUISITOS
• Enumerar los requisitos candidatos Lista de ideas
  que se pueden decidir implemtar en un futuro
• Nombre y una descripción
• Estado (propuesto-aprobado-incluido o validado)
• Costo estimado
• Prioridad (crítico importante o secubdario)
• Nivel del riesgo (crítico, significativo u
  ordinario)

28
FLUJOS DE TRABAJO

• REQUISITOS
• b. Comprender el contexto del sistema
• Modelo Dominio describe los conceptos
  importantes del contexto como objetos como
  objetos del dominio y enlaza estos objetos con
  otros.
• La identificación y al asignación de nombres
  ayuda desarrollar un glosario que permita
  comunicarse mejor a los trabajan en el sistema.

29
FLUJOS DE TRABAJO

• REQUISITOS
• b. Comprender el contexto del sistema
• Modelo Negocio Espeficica qué procesos del
  negocio soportará el sistema, además de
  identificar los objetos del dominio, también
  establece las comptetencias requeridas en cada
  proceso sus trabajadores, sus responsablidades y
  las operaciones que llevan a cabo, considerandose
  decisivos para la identificación de los casos de
  uso

30
FLUJOS DE TRABAJO

• REQUISITOS
• c. Captura de requisitos funcionales
• Técnica para identificar los requisitos del
  sistema basada en casos de uso.
• Cada caso de uso representa una forma de usar el
  sistema (de dar soporte a un usuario durante un
  proceso de negocio). Cada usuario necesita varios
  casos de uso distintos que representan los modos
  diferentes de utilizar el sistema.

31
FLUJOS DE TRABAJO

• REQUISITOS
• d. Captura de requisitos no funcionales
• Especifican propiedades del sistema, como
  restrcciones del entorno o de la implementación,
  rendimiento, dependencias de la plataforma,
  facilidad de mantenimiento, extensibilidad y
  fiablidad

32
FLUJOS DE TRABAJO

• REQUISITOS

33
FLUJOS DE TRABAJO

• REQUISITOS

34
FLUJOS DE TRABAJO

• REQUISITOS

Inicio Identificar las la mayoría de los casos de
uso, para delimitar y el alcance del proyecto y
detallar los mas importantes Elaboración Capturar
la mayoría de los requisitos restantes, para
estimar el esfuerzo de desarrollo 80 de los
requisitos y descrito la mayoría de los casos de
suo al final Construcción capturan los reuisitos
restantes
35
FLUJOS DE TRABAJO

• REQUISITOS
• Artefactos

Modelo de casos de Uso
Glosario
36
DIAGRAMA DE CASOS DE USO

Casos de Uso es una técnica para
capturar información de cómo un sistema o
negocio trabaja, o de cómo se desea que trabaje
No pertenece estrictamente al enfoque orientado a
objeto, es una técnica para captura de requisitos
37
DIAGRAMA DE CASOS DE USO
Ingeniería de requisitos es el proceso para
establecer los servicios que el sistema debe
proveer y las restricciones bajo las cuales debe
operar. El apelativo Un requisito funcional
describe un servicio o función del sistema. Un
requisito nofuncional es una restricción sobre el
sistema ( por ejemplo el tiempo de respuesta) o
sobre el proceso de desarrollo (por ejemplo el
uso de un lenguaje específico).

38
DIAGRAMA DE CASOS DE USO
Definición de requisitos es una descripcion de
alto nivel usada para efectos contractuales. Espe
cificación de requisitos es una escripción
detallada de qué debe hacer el sistema. Puede
servir de contrato entre el usuario y el
desarrollador. Especificación del software es
una escripción aún más detallada que establece el
puente entre ingeniería de requisitos y diseño.

39
DIAGRAMA DE CASOS DE USO
Los Casos de Uso (Ivar Jacobson) describen bajo
la forma de acciones y reacciones el
comportamiento de un sistema desde el p.d.v. del
usuario Permiten definir los límites del sistema
y las relaciones entre el sistema y el entorno
Los Casos de Uso son descripciones de la
funcionalidad del sistema independientes de la
implementación

40
Criterios para identificar Casos de Uso

• Resultado de Valor Cada ejecución satisfactoria
  de un caso de uso debe proporcionar algún valor
  al actor para alcanzar su objetivo.
• Un Actor en concreto Identificar los casos de
  uso que proporcionen valores a usuario
  individuales reales

41
DIAGRAMA DE CASOS DE USO

42

43

• Actores
• Principales personas que usan el sistema
• Secundarios personas que mantienen o
  administran el sistema
• Material externo dispositivos materiales
  imprescindibles que forman parte del ámbito de la
  aplicación y deben ser utilizados
• Otros sistemas sistemas con los que el sistema
  interactúa
• La misma persona física puede interpretar varios
  papeles como actores distintos
• El nombre del actor describe el papel desempeñado

44
DIAGRAMA DE CASOS DE USO

Inclusión una instancia del Caso de Uso origen
incluye también el comportamiento descrito por el
Caso de Uso destino
45
DIAGRAMA DE CASOS DE USO

Extensión el Caso de Uso origen extiende el
comportamiento del Caso de Uso destino
46
DIAGRAMA DE CASOS DE USO
Las relaciones ltltincludegtgt y ltltextendgtgt
corresponden ambas a factorizaciones del
comportamiento de un caso de uso, es decir, el
caso de uso incluido y el caso de uso que
extiende representan un fragmento de interacción
de otro caso de uso. Sin embargo, la intensión es
diferente la relación ltltincludegtgt pretende
evitar duplicación de interacciones en distintos
casos de uso, la relación ltltextendsgtgt pretende
describir una variación del comportamiento normal
de un caso de uso, sobre todo cuando dicha
variación pudiera complicar la legibilidad del
caso de uso.

47
DIAGRAMA DE CASOS DE USO

48
Un caso de uso debe ser simple, inteligible,
claro y conciso Generalmente hay pocos actores
asociados a cada Caso de Uso Preguntas clave
cuáles son las tareas del actor? qué
información crea, guarda, modifica, destruye o
lee el actor? debe el actor notificar al
sistema los cambios externos? debe el sistema
informar al actor de los cambios internos?

49
La descripción del Caso de Uso comprende el
inicio cuándo y qué actor lo produce? el fin
cuándo se produce y qué valor devuelve? la
interacción actor-caso de uso qué mensajes
intercambian ambos? objetivo del caso de uso
qué lleva a cabo o intenta?

50
cronología y origen de las interacciones
repeticiones de comportamiento qué operaciones
son iteradas? situaciones opcionales qué
ejecuciones alternativas se presentan en el caso
de uso?

51
CLASIFICACION

• Nivel de abstracción
• a. Abstractos describen las interacciones de
  manera ideal, abstrayendo los detalles de
  tecnología e implementación, especialmente
  aquellos relacionados con las interfaces de
  usuario.

52
CLASIFICACION

• Nivel de abstracción
• b. Reales describen las interacciones en
  términos de su diseño real, incluyendo los
  detalles de la tecnología empleadas en las
  entradas y salidas.

53
CLASIFICACION

2. Nivel de detalle a. Alto Nivel describen
las interacciones muy brevemente, usando dos o
tres frases. Son utilizados durante las fases
iniciales de captura de requerimientos con el fin
de obtener rápidamente una visión de la
funcionalidad y el grado de complejidad del
sistema, Los casos de uso de alto nivel son
siempre abstractos
54
CLASIFICACION

Descripción casos de uso de Alto Nivel
55
CLASIFICACION

Descripción casos de uso de Alto Nivel Describe
clara y concisamente el proceso Caso de Uso
Nombre del caso de Uso o función del
sistema Actores Actores involucrados en el
sistema Tipo Importancia de impacto en el
sistem Descripción descripción del proceso que
realiza el caso de Uso
56
CLASIFICACION

Descripción casos de uso de Alto Nivel Tipo
corresponde a una categoría asignada dependiendo
de la importancia, y que es la base para
establecer un orden de prioridad en el momento de
planificar su implementación
57
CLASIFICACION
Descripción casos de uso de Alto
Nivel Tipos Primario representa una
interacción principal y común en el sistema
Secundario representa una interacción menor o
de rara ocurrencia Opcional representa una
interacción que puede no se abordada

58
CLASIFICACION

2. Nivel de detalle b. Extendidos describen
las interacciones con mayor detalle que los de
alto nivel , enumerando a paso a paso los eventos
que se presentan durante una ocurrencia típica
del caso de uso
59

60
DIAGRAMA DE ACTIVIDADES
El Diagrama de Actividad es utilizado para
describir una secuencia de acciones, las cuales
pueden corresponder a distintos niveles de
abstracción de un sistema el algoritmo de una
operación en una clase, la interacción de un
grupo de objetos, la especificación de un caso de
uso, las actividades que integran un
procedimiento en una empresa.

61
DIAGRAMA DE ACTIVIDADES
El Diagrama de Actividad es una especialización
del Diagrama de Estado, organizado respecto de
las acciones y usado para especificar Un
método Un caso de uso Un proceso de negocio
(Workflow) Las actividades se enlazan por
transiciones automáticas. Cuando una actividad
termina se desencadena el paso a la siguiente
actividad

62
DIAGRAMA DE ACTIVIDADES
El Diagrama de Actividad es una especialización
del Diagrama de Estado, organizado respecto de
las acciones y usado para especificar Un
método Un caso de uso Un proceso de negocio
(Workflow) Las actividades se enlazan por
transiciones automáticas. Cuando una actividad
termina se desencadena el paso a la siguiente
actividad

63
Pasajero
Vendedor
Aerolínea
Solicitar pasaje
Verificar Existencia vuelo
Dar detalles vuelo
Informar alternativas Y precios
Seleccionar vuelo
Reservar Plazas
Solicitar pago
Confirmar Plaza Reservada
Pagar pasaje
Emitir Tiquete
64
GLOSARIO
Define términos comunes importantes que los
analistas utilizan al describir el sistema, es
útil para alcanzar un consenso entre los
desarrolladores en relación a la definición de
conceptos y nociones para reducir el riesgo.
65
GLOSARIO
Glosario o diccionario modelo (semejante a un
diccionario de datos) incluye y define todos los
términos que requieren explicación para mejorar
la comunicación y aminorar el riesgo de malos
entendidos
66
GLOSARIO

Término nombre del concepto, características Cate
goría Clasificación como concepto, atributo o
caso de uso Comentario Significado del término
sin ambiguedades
67
GLOSARIO
Concepto En términos informales el concepto es
una idea, cosa u objeto. En un lenguaje formal se
puede considerar a partir de su símbolo,
intensión y extensión Símbolo Palabra o
imágenes que representan un concepto Intensión
La definición del concepto. Extensión conjunto
de ejemplos a que se aplica el concepto.

68
GLOSARIO

Atributo Es un valor lógico de un dato de un
objeto
69
ARBOL DE FUNCIONES
Las funciones hay que identificarlas y listarlas
en grupos cohesivos y lógicos Categorías Evidente
Debe realizarse, y el usuario debería saber que
se ha realizado Oculta debe realizarse, aunque
no es visible para los usuarios. Superflua
Opcionales su inclusión no repercute
significativamente.
70
ARBOL DE FUNCIONES
Ref Su representación es R1.1 ..... R1.n para
funciones de un tipo, si es otro tipo de función
entonces R2.1 ... R2.n Función Actividad a
realizar Categoria evidente, oculta o superflua