GUIA MAP DE

ANALISI I

-1-

MATERIA
CARRERA

ANALISIS I
ING. INFORMTICA Y SISTEMAS ADMISNISTRATIVOS
ING. ELECTRNICA Y SISTEMAS
ING. REDES Y TELECOMUNICACIONES

ING. SISTEMAS
PRERREQUISITO
PROGRAMACIN II
OBJETIVOS GENERALES

SIGLA
SEMESTRE
HORAS
HORAS TERICAS

SIS-130
CUARTO
80
50

HORAS PRACTICAS

30

Aplicar las definiciones de Sistemas de Informacin y los Procesos, Modelos y Herramientas para realizar los modelos de
dominio de informacin de un Sistema de Informacin.
CONTENIDO
TEMA-1 TEORA GENERAL DE SISTEMAS
Introduccin
Concepto de Sistemas
Partes de un sistema
Clasificacin de los Sistemas
Fenmeno
Entropa, Neguentropia
Homeostasis, sinergia.
TEMA-2 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE.
Caractersticas del proceso
o
Dirigido por caso de uso.
o
Centrado en la arquitectura.
o
Iterativo e incremental.
Ciclo y fases del proceso unificado
Modelos resultante del ciclo de desarrollo
TEMA-3 PLANIFICACIN DE PROYECTO
Entrevistas.
Plan de iteraciones
Planificacin temporal del Proyecto
o
Compartimentacin
o
Interdependencia
o
Hitos
o
Responsables
Diagramas de PER. GANT
TEMA-4 EL LENGUAJE UNIFICADO DE MODELADO.
o
Elementos.
o
Relaciones.
o
Diagramas.

Modelan Estructura

Modelan Comportamiento
o
Arquitectura tres capas.

Capa de negocio

Capa de datos

Capa de interfaz
o
Estereotipos del anlisis
TEMA-5 MODELO DE NEGOCIO, REQUISITOS, ANALISIS
1.
Identificacin de los procesos de negocio
2.
Identificacin de los usuarios, departamentos o elementos de la organizacin implicados en el proceso de negocio.
3.
Establecer las acciones necesarias para realizar el proceso de negocio.
4.
Diagrama de actividades que represente el proceso de negocio
5.
Listado de las actividades.
6.
Informacin generada o utilizada en cada actividad.
7.
Reglas de negocio.
MODELO DE REQUISISTOS
8.
Identificacin de los casos de Uso.
9.
Descripcin de los casos de uso.
10. Crear el modelo conceptual
MODELO DE ANALISIS
11. Identificacin de los actores definitivos del sistema.
12. Identificacin de los casos de uso y sus extensiones.
13. Se crea un modelo de casos de uso (Actualizando el modelo de CDU. del Modelo de requisitos con sus relaciones de Usa y
Extend).
14. Se crea un diagrama de secuencia y de colaboracin para cada caso de USO.
BIBLIOGRAFA
[PU-GJI ]El proceso Unificado de desarrollo de software Grady Booch James Rumbaugh Ivar Jacobson
[LU- GJI] El Lenguaje Unificado de desarrollo de software Grady Booch James Rumbaugh Ivar Jacobson
Anlisis y Diseo de Sistemas de Informacin James A. SENN
Ingeniera de Software Roger Pressman

Ing. Ernesto Soto Roca

Ing. Ernesto Soto Roca

FORMULARIO DE PLANIFICACIN DE CLASE

FACULTAD
FET
MATERIA
Anlisis I
MOD / SEM

5 - II
2007
Si
No

Fecha Autom

FECHA

28/10/2009

UNIDAD TEMATICA

OBJETIVOS

Ing. Ernesto
Soto Roca

HORARIO:

13:15

CONTENIDO / SUB-TEMA

Gestin de la materia

Definir el plan
de la materia

Contenido analtico, bibliografa, evaluaciones,

A. acadmica. prueba diagnstica

Unidad 1. Introduccin
conceptual a la materia

Comprender los
conceptos
de
sistemas y las
bases en que se
sustentan.

Introduccin
Concepto de Sistemas
Partes de un sistema
Clasificacin de los Sistemas

29/10/2009

30/10/2009
Unidad 2. El proceso
unificado de desarrollo
de software

03/11/2009

DOCENTE

Comprender un
ciclo completo
y los flujos de
trabajos
para
cada fase de
desarrollo.

Unidad 3. Planificacin
de proyecto

Fenmeno
Entropa, Neguentropia
Homeostasis, sinergia.
Caractersticas del proceso
Dirigido por caso de uso.
Centrado en la arquitectura.
Iterativo e incremental.
Ciclo y fases del proceso unificado
Modelos resultante del ciclo de desarrollo
Plan de iteraciones
Planificacin temporal
Entrevistas.

ACTIV.

MATE

MEDIOS

Magistral/practica

Magistral/practica

Magistral/practica

Magistral/Practica

04/11/2009

05/11/2009

Planificacin del Proyecto

Compartimentacin
Interdependencia
Hitos
Responsables
PER. GANT

Introduccin. Qu es UML? Lenguaje de

Modelado Unificado.
Bloques de UML
Elementos.
Estructurales (Parte esttica del modelo: clase,
interfaz,
colaboracin,
caso
de
uso,
componentes)
De comportamiento (mensajes)
De Agrupacin (Paquetes)
De Anotacin(Comentario)

LABORATORIO
MULTIMEDIA

EXAMEN PARCIAL

06/11/2009

Unidad 4. El Lenguaje
Unificado de modelado.

09/11/2009

Conocer
los
elementos
y
modelos que se
implementan
usando
el
lenguaje
Unificado
de
modelado.

Relaciones.
o
o
o
o

10/11/2009

11/11/2009

LABORATORIO
MULTIMEDIA

Dependencia
Asociacin
Generalizacin
Realizacin

Magistral/practica
MULTIMEDIA

Diagramas.
Modelan Estructura

Modelos de clase y diagramas de objeto

Modelos de componentes

Despliegue
Modelan Comportamiento

Modelo de caso de uso

Colaboracin

Estado

Actividades

De secuencia y colaboracin

LABORATORIO
MULTIMEDIA

Magistral/practica
MULTIMEDIA

Ing. Ernesto Soto Roca

13/11/2009

16/11/2009

Unidad 5. Modelo de
negocio.
Requisitos,
Anlisis

17/11/2009

El modelado de
negocio tiene
como finalidad
presentar
un
modelo de la
empresa, cuales
son
las
actividades
principales que
realiza
y
quienes
la
realizan: Para
tal objetivo se
realizan
las
siguientes
actividades:

Arquitectura tres capas.

o
Capa de negocio
o
Capa de datos
o
Capa de interfaz
Estereotipos del anlisis

MODELO DE NEGOCIO:
1.
Identificacin de los procesos de
negocio
2.
Identificacin de los usuarios,
departamentos o elementos de la
organizacin implicados en el
proceso de negocio.
3.
Establecer las acciones necesarias
para realizar el proceso de negocio.

1.
2.
3.
4.

18/11/2009

19/11/2009

MODELO DE REQUISISTOS
5.
Identificacin de los casos de Uso.
6.
Descripcin de los casos de uso.
7.
Crear el modelo conceptual
REVISIN
PROYECTO

DEL

20/11/2009

10.

11.
12.

24/11/2009

/11/2009

REVISIN
DEL
PROYECTO
EVALUACIN FINAL

LABORATORIO
MULTIMEDIA

EXAMEN
PARCIAL

LABORATORIO
MULTIMEDIA
Magistral/practica
MULTIMEDIA

MODELO DE ANALISIS
8.
Identificacin de los actores
definitivos del sistema.
9.
Identificacin de los casos de uso y
sus extensiones.

23/11/2009

25/11/2009

Diagrama de actividades que

represente el proceso de negocio
Listado de las actividades.
Informacin generada o utilizada en
cada actividad.
Reglas de negocio.

Magistral/practica
MULTIMEDIA

Se crea un modelo de casos de uso

(Actualizando el modelo de CDU.
del Modelo de requisitos con sus
relaciones de Usa y Extend).
Se crea un diagrama de secuencia y
de colaboracin para cada caso de
USO.

LABORATORIO
MULTIMEDIA

LABORATORIO
MULTIMEDIA

LABORATORIO
MULTIMEDIA
LABORATORIO
MULTIMEDIA
EXAMEN FINAL

Ing. Ernesto Soto Roca

EVALUACIONES
Evaluaciones Parciales: Tipo Proyecto
Evaluacin
Primer Parcial
Segundo Parcial
Examen final
Proyecto final
Proyecto final

Temas a evaluar
Aspectos conceptuales
Aspectos prcticos
Todo o avanzado
1er. Presentacion.
2da. presentacion

Puntos
20
20
40
10
10

Fecha

Trabajos Prctico
Descripcin
Puntos
Se orientarn al desarrollo de los modelo
de Negocio, requisitos, y anlisis de un
sistema de informacin

Ing. Ernesto Soto Roca

TEORA GENERAL DE SISTEMAS

CONCEPTOS DE SISTEMAS.
DEF. 1. Es Un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan formando un todo unitario y
complejo.
DEF. 2. Es un conjunto de partes o subsistema coordinados y en interaccin para alcanzar un conjunto de objetivo. Forman un todo unitario.
DEF. 3. Es un conjunto de modelos, interrelacionados entre si, que contribuyen a un objetivo comn.

MODELO. Los modelos son constructor diseados por un observador que persigue identificar y mensurar relaciones sistmicas complejas. Todo
sistema real tiene la posibilidad de ser representado en ms de un modelo. La decisin, en este punto, depende tanto de los objetivos del modelador como
de su capacidad para distinguir las relaciones relevantes con relacin a tales objetivos. La esencia de la modelstica sistmica es la simplificacin.

CONCEPTOS.
SINERGIA.
La suma del todo es mayor que la suma de todas sus partes. El comportamiento de un elemento no representa el comportamiento del todo.
Todo sistema es sinrgico en tanto el examen de sus partes en forma aislada no puede explicar o predecir su comportamiento. La sinergia es,
en consecuencia, un fenmeno que surge de las interacciones entre las partes o componentes de un sistema (conglomerado). Este concepto
responde al postulado aristotlico que dice que "el todo no es igual a la suma de sus partes". La totalidad es la conservacin del todo en la
accin recproca de las partes componentes (teleologa). En trminos menos esencialistas, podra sealarse que la sinergia es la propiedad
comn a todas aquellas cosas que observamos como sistemas.

HOMEOSTASIS La homeostasis es la propiedad de un sistema que define su nivel de respuesta y de adaptacin al contexto.
Es el nivel de adaptacin permanente del sistema o su tendencia a la supervivencia dinmica. Los sistemas altamente homeostticos sufren
transformaciones estructurales en igual medida que el contexto sufre transformaciones, ambos actan como condicionantes del nivel de
evolucin.

LA ENTROPA Es el grado de desorden de una organizacin. Es la perdida permanente de vida til.

La entropa de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. Los
sistemas altamente entrpicos tienden a desaparecer por el desgaste generado por su proceso sistmico. Los mismos deben tener rigurosos
sistemas de control y mecanismos de revisin, reelaboracin y cambio permanente, para evitar su desaparicin a travs del tiempo.
En un sistema cerrado la entropa siempre debe ser positiva. Sin embargo en los sistemas abiertos biolgicos o sociales, la entropa puede ser
reducida o mejor aun transformarse en entropa negativa, es decir, un proceso de organizacin ms completa y de capacidad para transformar
los recursos. Esto es posible porque en los sistemas abiertos los recursos utilizados para reducir el proceso de entropa se toman del medio
externo. Asimismo, los sistemas vivientes se mantienen en un estado estable y pueden evitar el incremento de la entropa y aun desarrollarse
hacia estados de orden y de organizacin creciente.

NEGUENTROPIA.

Los sistemas vivos son capaces de conservar estados de organizacin improbables (entropa). Este fenmeno
aparentemente contradictorio se explica porque los sistemas abiertos pueden importar energa extra para mantener sus estados estables de
organizacin e incluso desarrollar niveles ms altos de improbabilidad. La negentropa, entonces, se refiere a la energa que el sistema
importa del ambiente para mantener su organizacin y sobrevivir (Johannsen. 1975).
Neguentropia: Ya esta definido, si luego de la aplicacin de mecanismos neguentrpicos, persiste el problema, se activan los mecanismos
homeostticos.
Mecanismos homeostticos.: Son los mecanismos encargados de corregir el problema no resuelto por la neguentropa, llevando la conducta
los resultados a los valores normales. Estos mecanismos son viables y eficientes dentro de ciertos rangos de desviacin posible.
Algedonia: Son los mensajes que envan los mecanismos homeostticos al sistema central (cerebro) para
Indicar que estos son incapaces de superar el problema
Ejemplo.
La empresa ONG. Solidaridad brindaba a sus inicios servicios de prstamos de dinero, para realizar las tareas operacionales de la empresa utilizaba a un
inicio un sistema de informacin de cartera con mdulos de otorgacin de prstamos y otro de evaluacin financiera del cliente. En el ao 2001 la ONG.
Cambia de razn social y pasa a ser FFP. Con los servicios de Prestamos, caja de ahorro, y DPF. Para poder brindar estos servicios se requiere la adaptacin
del sistema actual con la implementacin de dos nuevos mdulos Caja de ahorro y DPF. La implementaron de estos nuevos mdulos ocasiona un cambio del
modelo de datos y el sistema empieza a tener fallas de funcionamiento. Que son corregidos en base a Programacin. Como el volumen de informacin generada
creci el sistema desarrollado en Visual FoxPro empieza a disminuir su performance Lento. En consecuencia la empresa toma la decisin de emprender el
desarrollo de un nuevo proyecto de sistema de informacin de cartera Caja de ahorro, y DPF.
1.- Identificar los sistemas de informacin existente en la empresa.
2.-Identificar fenmenos de: Entropa, Sinergia, Fenmenos Homeostticos, Neguentropia.

Ing. Ernesto Soto Roca

ELEMENTOS DE UN SISTEMA.
Entradas.
Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o informacin. Las entradas constituyen la
fuerza de arranque que suministra al sistema sus necesidades operativas
Todo sistema abierto requiere de recursos de su ambiente. Se denomina entrada a la importacin de los recursos ( energa, materia,
informacin) que se requieren para dar inicio al ciclo de actividades del sistema.
. Las entradas pueden ser:
- En Serie: es el resultado o la salida de un sistema anterior con el cual el sistema en estudio est relacionado en forma directa.
- Aleatoria: es decir, al azar, donde el termino "azar" se utiliza en el sentido estadstico. Las entradas aleatorias representan entradas
potenciales para un sistema.
- Retroaccin: es la reintroduccin de una parte de las salidas del sistema en s mismo.
Importa energa y recursos del medio (recursos humanos, informticos, financieros, fsicos, etc.).
Ley de Conservacin:
C.E >= C.S.
Donde : C.E.=Entrada C.S.=Salida
Cantidad de energa de un sistema = C.S. C.E.

Procesos.
El proceso es lo que transforma una entrada en salida, como tal puede ser una mquina, un individuo, una computadora, un producto qumico, una tarea
realizada por un miembro de la organizacin, etc. En la transformacin de entradas en salidas debemos saber siempre como se efecta esa
transformacin. Con frecuencia el procesador puede ser diseado por el administrador. En tal caso, este proceso se denomina "caja blanca". No obstante,
en la mayor parte de las situaciones no se conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas, porque esta
transformacin es demasiado compleja. Diferentes combinaciones de entradas o su combinacin en diferentes rdenes de secuencia pueden originar
diferentes situaciones de salida. En tal caso la funcin de proceso se denomina una "caja negra".
Caja Negra: La caja negra se utiliza para representar a los sistemas cuando no sabemos que elementos o cosas componen al sistema o proceso, pero
sabemos que a determinadas corresponden determinadas salidas y con ello poder inducir, presumiendo que a determinados estmulos, las variables
funcionaran en cierto sentido.

Salidas
Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas. Al igual que las entradas estas pueden adoptar la forma de
productos, servicios e informacin. Las mismas son el resultado del funcionamiento del sistema o, alternativamente, el propsito para el cual existe el
sistema.
Las salidas de un sistema se convierten en entrada de otro, que la procesar para convertirla en otra salida, repitindose este ciclo indefinidamente.

Retroalimentacin:
La retroalimentacin se produce cuando las salidas del sistema o la influencia de las salidas del sistema en el contexto, vuelven a ingresar al sistema como
recursos o informacin.
La retroalimentacin permite el control de un sistema y que el mismo tome medidas de correccin en base a la informacin retroalimentada

CONTEXTO - FRONTERA:
Los sistemas consisten en totalidades y, por lo tanto, son indivisibles como sistemas (sinergia). Poseen partes y componentes (subsistema), pero estos son
otras totalidades (emergencia). En algunos sistemas sus fronteras o lmites coinciden con discontinuidades estructurales entre estos y sus ambientes, pero
corrientemente la demarcacin de los lmites sistmicos queda en manos de un observador (modelo). En trminos operacionales puede decirse que la
frontera del sistema es aquella lnea que separa al sistema de su entorno y que define lo que le pertenece y lo que queda fuera de l (Johannsen.
1975:66).
Un sistema siempre estar relacionado con el contexto que lo rodea, o sea, el conjunto de objetos exteriores al sistema, pero que influyen decididamente a
ste, y a su vez el sistema influye, aunque en una menor proporcin, influye sobre el contexto; se trata de una relacin mutua de contexto-sistema.
Tanto en la Teora de los Sistemas como en el mtodo cientfico, existe un concepto que es comn a ambos: el foco de atencin, el elemento que se asla
para estudiar.
El contexto a analizar depende fundamentalmente del foco de atencin que se fije. Ese foco de atencin, en trminos de sistemas, se llama lmite de
inters.
Para determinar este lmite se consideraran dos etapas por separado:
Ing. Ernesto Soto Roca

a) La determinacin del contexto de inters.

b) La determinacin del alcance del lmite de inters entre el contexto y el sistema.
a) Se suele representar como un crculo que encierra al sistema, y que deja afuera del lmite de inters a la parte del contexto que no interesa al analista.
d) En lo que hace a las relaciones entre el contexto y los sistemas y viceversa. Es posible que slo interesen algunas de estas relaciones, con lo que habr
un lmite de inters relacional.
Determinar el lmite de inters es fundamental para marcar el foco de anlisis, puesto que slo ser considerado lo que quede dentro de ese lmite.
Entre el sistema y el contexto, determinado con un lmite de inters, existen infinitas relaciones. Generalmente no se toman todas, sino aquellas que
interesan al anlisis, o aquellas que probabilsticamente presentan las mejores caractersticas de prediccin cientfica.
SUBSISTEMAS:
En la misma definicin de sistema, se hace referencia a los subsistemas que lo componen, cuando se indica que el mismo esta formado por partes o cosas
que forman el todo.
Estos conjuntos o partes pueden ser a su vez sistemas (en este caso seran subsistemas del sistema de definicin), ya que conforman un todo en s
mismos y estos seran de un rango inferior al del sistema que componen.
Estos subsistemas forman o componen un sistema de un rango mayor, el cual para los primeros se denomina macrosistema.

CATEGORIA DE SISTEMAS DE INFORMACION

Diferencias: DSS y OLTP
Sistema para el procesamiento de transacciones.
Las aplicaciones de OLTP estn organizadas para ejecutar las transacciones para los cuales fueron hechos, como por ejemplo: mover dinero entre
cuentas, un cargo o abono, una devolucin de inventario, etc.
Sistema para el soporte a las decisiones. (DSS).
Por otro lado, un DSS est organizado en base a conceptos, como por ejemplo: clientes, facturas, productos, etc.
Otra diferencia radica en el nmero de usuarios. Normalmente, el nmero de usuarios de un DSS es menor al de un OLTP. Es comn encontrar que los
sistemas transaccionales son accesados por cientos de usuarios simultneamente, mientras que los DSS slo por decenas. Los sistemas de OLTP
realizan cientos de transacciones por segundo mientras que una sola consulta de un DSS puede tomar minutos. Otro factor es que frecuentemente los
sistemas transaccionales son menores en tamao a los Data Warehouses, esto es debido a que un DSS puede estar formado por informacin de varios
OLTPs.
Existen tambin diferencia en el diseo, mientras que el de un OLPT es extremadamente normalizado, el de un DSS tiende a ser desnormalizado. El OLTP
normalmente est formado por un nmero mayor de tablas, cada una con pocas columnas, mientras que en un DSS el nmero de tablas es menor, pero
cada una de stas tiende a ser mayor en nmero de columnas.
Los OLTP son continuamente actualizados por los sistemas operacionales del da con da, mientras que los DSS son actualizados en batch de manera
peridica.
Las estructuras de los OLTP son muy estables, rara vez cambian, mientras las de los Data Warehouses sufren cambios constantes derivados de su
evolucin. Esto se debe a que los tipos de consultas a los cuales estn sujetos son muy variados y es imposible preverlos todos de antemano.
OLPT
- Orientada a transacciones
- Detallada
- Actualizada en lnea
- Usuarios de nivel operativo
- Corre en base a repeticiones
- Orientado a operacin
- Estructura esttica
- Sin redundancia
- Alta probabilidad de acceso
- Informacin bruta (Datos)
- Actualizada en lnea
- Muchas tablas con pocas columnas

DSS
- Orientada a Conceptos
- Sumariada
- Representa valores a un tiempo (snapshot)
- Usuarios de nivel gerencial
- Corre heursticamente
- Poco sensitivo al desempeo
- Accesa conjuntos de unidades a la vez
- Orientado a anlisis
- Estructura flexible
- Con mucha redundancia
- Modesta probabilidad de acceso
- Administrada por partes
- Informacin procesada (Informacin)
- Actualizada en Batch
- Pocas tablas con muchas columnas

Ing. Ernesto Soto Roca

EL PROCESO UNIFICADO DE DESARROLLO DE SOFWARE. (PU).

Es un conjunto de actividades necesarias para transformar los requisitos de usuario en un producto software. Es una metodologa, paradigma que
transforma las entradas o requerimientos a travs de un proceso sistemtico disciplinado y cuantificable en soluciones del problema.
Caractersticas del proceso unificado

Dirigido por caso de uso

Centrado en la arquitectura
Iterativo e incremental

Fases del proceso

Flujos de trabajo

Fase de inicio
Fase de elaboracin
Fase de construccin
Fase de transicin

Dirigido por caso de uso.Un caso de uso es una pequea funcionalidad del sistema que devuelve al usuario
un resultado importante. Representa la unidad atmica funcional a travs del cual
se realizan todas las actividades necesarias para solucionar un problema, el
conjunto de casos de uso de un sistema representa la funcionalidad total del
producto. Los casos de uso no solo inician el proceso de desarrollo sino que
brindan un hilo constructor a travs de todo el proceso, los casos se analizan,
disean se implementan y se construyen los modelos de prueba.

Modelo de negocio
Requisitos
Anlisis
Diseo
Implementacin
Prueba

abrir caja

cajero

cierre caja
Gerente operacional
realizar recuperaciones
apertura del sistema

Centrado en la arquitectura.La arquitectura del sistema es un modelo que permite ver al producto antes de que este haya sido construido. Es decir los casos de uso representan la
funcionalidad del sistema y la arquitectura la forma.
La arquitectura del sistema se ve influenciada por muchos factores como ser los usuarios, sistemas operativos disponibles, software de sistemas que
participan en el desarrollo de la aplicacin, habilidad y conocimiento del diseador, etc.
Iterativo e incremental.Es prctico dividir al proyecto en pequeos mini proyectos. Estos mini proyectos o iteraciones incrementan la funcionalidad del sistema para cada mini
proyecto se realizan 5 flujos de trabajo requisitos, anlisis, diseo, implementacin y prueba.
Por supuesto una iteracin no necesariamente es aditiva puede ser que se necesite reemplazar iteraciones en las primeras fases por otras mucho mas
robustas.
Ventajas de las iteraciones.
Reduce el costo de los incrementos a una sola iteracin

Reduce el riesgo de no sacar al mercado el producto en un tiempo calendario

Resultados claros a corto plazo

Los clientes rara vez definen los requisitos a un inicio.

FASES DEL PROCESO UNIFICADO
Inicio.- La fase de inicio responde a La pregunta cuanto va a costar el producto y en que tiempo estimado tendremos una primera versin del software?
Cuales son los casos de uso esenciales para los usuarios ms importantes? Cul ser esbozo o la arquitectura o del producto?
Se presenta un modelo de caso uso simplificado que contenga los casos de uso ms crtico en una arquitectura provisional que muestra los subsistemas
ms importantes.
Fase de elaboracin.- En esta fase se identifican la mayora de los
casos de uso y se especifica en detalle se disea la arquitectura del
sistema a travs de modelos que representan al sistema entero esto
implica que hay una vista arquitectnica del modelo del caso de uso,
del modelo anlisis del modelo de diseo de implementacin y de
despliegue. Al finalizar esta fase el director del proyecto esta en
condiciones de planificar las actividades y estimar los recursos
necesarios para terminar el proyecto.
Fase de construccin.- El producto se crece hasta convertirse en un
sistema completo preparados para ser empleado a la comunidad de
usuarios, puede que no este completamente libre de defectos. Muchos
de esos defectos se descubrirn y solucionaran durante la fase de
transicin.
Fase de transicin.Esta fase cubre el periodo de entrega del producto a la comunidad de
usuarios. Se capacita al personal o usuario finales de la aplicacin, se
crean los manuales o ayudas del sistema.
MODELOS RESULTANTES DE UN CICLO DE DESARROLLO.-

Ing. Ernesto Soto Roca

10

Planificacin Temporal.
La planificacin temporal tiene como objetivo evitar el retraso en la entrada del sistema. Un sistema de software general debe cumplir plazos o fechas de
entrega impuestas por departamentos fuera del equipo de desarrollo en consecuencia pueden ser fechas irrealistas.
Por qu se retrasa la entrega de un producto?
Por la falta de conocimiento del tamao real del sistema. Es decir no contamos con datos histricos que nos permitan hacer estimaciones de la magnitud
del problema, duracin del proyecto, esfuerzo y personas requeridas.
La subestimacin de la productividad de los desarrolladores.
Fechas que responden a una necesidad sin tomar en cuenta un ciclo del proceso del desarrollo
Que debemos hacer para que un proyecto no se retrase
Se deben realizar estimaciones en base a datos histricos que me permitan aclarar la magnitud y el tamao del proyecto.
Se debe trabajar con procesos evolutivos, que permiten al desarrollador la entrega del producto a travs de incrementos. Siempre y cuando la fecha
propuesta, requisitos poco claros no permitan hacer una estimacin real del tamao del proyecto.
Se debe informar al cliente que la construccin del sistema esta regido por la utilizacin de una metodologa en consecuencia el producto ser entregado
en forma gradual.
Principios de la planificacin temporal.Durante las primeras etapas de la planificacin del proyecto se desarrolla una planificacin temporal macroscopica es decir se toman en cuenta las
principales actividades de la ing. de software y las funciones del producto a las que se aplican a medida que el proyecto va progresando cada entrada en la
planificacin temporal microscpica se defina en una planificacin temporal detallada.
Los principios fundamentales de la planificacin Temporal son:
1.
Compartimentacin
2.
Interdependencia
3.
Validacin de Esfuerzo
4.
Asignacin de Esfuerzo
5.
Resultados definidos
6.
Responsabilidades definidas
7.
Hitos definidos
Compartimentacin.- Tiene por finalidad la divisin del producto y el proceso en tareas mucho ms sencillas
Interdependencia.- Cada una de las tareas, fases, modelos del producto estn interrelacionadas entre si es decir siguen una traza de desarrollo
claramente definida
Asignacin de esfuerzos.- Cada una de las tareas, fases o modelos dependiendo de la estructura organizativa del equipo de desarrollo debe tener un
responsable definido, se le debe asignar una fecha de inicio y una fecha de culminacin de cada actividad.
Validacin de esfuerzo.- No se debe sobrecargar al personal, es decir se deben tener mtricas de productividad individual por desarrollador de acuerdo a
datos histricos de proyectos similares.
Responsabilidad Definidas.- Se debe tener un responsable en funcin a las fases o tareas como modelos que componen el producto con el objetivo de
aprovechar las potencialidades de las personas. No olvidemos que el software es el resultado de una actividad intensamente humana.
Resultados definidas.- Un proyecto de software debe ser claramente definido en funcin a sus fronteras del sistema es decir debe tener un objetivo
general evitando cualquier ambigedad en los resultados.
Hitos formales o definidos.- Los hitos formales son reuniones tcnicas formales de revisin de cada uno de los modelos que se han producido,
aumentados o corregidos en una iteracin o incremento.
Ejemplo.
Realizar una planificacin temporal para un sistema de informacin para la empresa distribuidora de repuestos agrcola Renacer la empresa tiene
planificado empezar las ventas para el 21/12/2005 en consecuencia necesita el sistema de ventas probado para dicha fecha.
Para el efecto contrata a la empresa desarrolladora de software x que cuenta con tres desarrolladores de planta. Dependiendo de la aceptacin de los
repuestos en el mercado agroindustrial planea ingresar al rubro de venta de maquinarias agrcolas a travs de crditos para los agroindustriales.

Ing. Ernesto Soto Roca

11

PLAN DE ITERACIONES
Flujos de trabajo

Modelado de
negocio
RequisitosAnlisis
Diseo
Implementacin
Gestin del
proyecto
Prueba
Entorno

Donde:

Modelos o
artefactos

Inicio

Elaboracin

I1

E1 E2

Modelo del
dominio
Modelos de Caso
de Uso
Modelo de diseo
Modelo de
implementacin
Plan de proyecto

E3

Construccin

C1 C2

Transicin

T1 In

Plan de iteracin

Modelo de
pruebas
Marco de
desarrollo

Inicio
Iteracin I1:

Plan de proyecto

Elaboracin
Iteracin E1:
Iteracin E2:
Iteracin E3:

Modelo de negocio - Modelo del dominio.

Modelo de requisitos, Diseo e implementacin de casos de uso esenciales.
Modelo de requisitos, Diseo e implementacin de casos de uso secundario.

Construccin
Iteracin C1:
Iteracin C2:

Estabilizacin de los requisitos mas importantes

Estabilizacin de los requisitos secundarios

Planificacin Temporal

Ing. Ernesto Soto Roca

12

Sistemas de informacin I.

PATERNO

Actividad Acadmica 1
MATERNO

NOMBRE (S)

1. Defina sistema de informacin y sus principales componentes.

2.- Indique tres beneficios de los sistemas de soporte a la toma de decisiones. E Indique tres beneficios de los sistemas de OLTP.
4.- Que procesos entropicos y Homeostticos encuentras en tu Universidad.
6.- Completar el siguiente grafico con la curva de trabajo correspondiente para cada flujos Explique las diferencias entre una iteracin en fase de Inicio,
Elaboracin, Construccin y transicin.
Fases
Modelo de
negocio
Requisitos
Anlisis
Diseo
Implementacin
Pruebas

INICIO

I1

I.. I

ELABORACION

CONSTRUCCION

In-1

TRANSICION

In

Ing. Ernesto Soto Roca

13

UML.-(Lenguaje Unificado de modelado).

Antecedentes
En el periodo comprendido entre [1994-1998] se incrementaron varios mtodos orientado a objeto. Muchos usuarios de estos mtodos tenan problemas al
intentar encontrar un lenguaje de modelado que cubriera sus necesidades completamente, alimentando de esta forma la llamada guerra de mtodos. En lo
que se destacaron el mtodo de IVAR JACOBSON conocido como Ingeniera de software orientado a objeto (OOSE), el mtodo de JAMES RUMBAUGH
Tcnica modelado de objeto (OMT), el mtodo de Coad-Yourdon Shlaer-Mello. Cada uno de estos era un mtodo completo. Aunque tenan sus puntos
fuertes y debilidades.
De las tres metodologas de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan
hacia el modelado de los objetos que componen el sistema, su relacin y colaboracin. Por otro lado, la metodologa de IVAR JACOBSON es ms
centrada a usuario, ya que todo en su mtodo se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estndar desde el OMG
El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus
mtodos. A finales de 1995, Ivar Jacobson y su compa na Objectory se incorporaron a Rational en su unificacin, aportando el mtodo OOSE.
Para aquel entonces en lenguaje tenia tres metas especficas
Modelar sistemas, desde el concepto hasta los artefactos ejecutables, utilizando tcnicas orientadas a objetos.
Cubrir las cuestiones relacionadas con el tamao inherente a los sistemas complejos y crticos.
Crear un lenguaje de modelado utilizable tanto en las personas como por las maquinas.
Una versin revisada de UML (la versin 1.1 se ofreci a Object Management Group (OMG) para sus estandarizacin en julio de 1997 y adoptado por
OMG. El 14 de noviembre de 1997.

Histrica de UML
1
UML
Definicin.
El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Lenguaje) es un lenguaje grfico para visualizar, especificar, construir y
documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo
son procesos de negocio y funciones de sistema, adems de cosas concretas como lo son escribir clases en un lenguaje determinado,
esquemas de base de datos y componentes de software reusables.
1.1 UML PARA VISUALIZAR.
Para muchos programadores, la distancia entre pensar en una implementacin y transformarla en cdigo es casi cero lo piensas lo codificas
incluso hay cosas que se modelan mejor directamente en cdigo. Pero hay unas cuestiones sobre un sistema software que no se pueden
entender a menos que se construyan modelos, que trasciendan el lenguaje de programacin textual. Por ejemplo la jerarqua de un modelo de
clases puede inferirse. Pero no capturarse completamente,
La distribucin fsica y posible migraciones de los
objetos en un sistema. Si el desarrollador escribi
cdigo y no dejo documentacin escrita sobre los
modelos que habra en su cabeza, esa informacin se
perder para siempre o, como muchos, ser solo
parcialmente reproducible a partir de la
implementacin, una vez que el desarrollador se haya
marchado.
1.2 UN LENGUAJE PARA ESPECIFICAR.
Construir modelos precisos, no ambiguos y completos de todos los modelos que componen un
sistema
1.3 UN LENGUAJE PARA COSTRUIR.
Los modelos de UML pueden conectarse en forma directa a una gran variedad de lenguajes de programacin. Esto significa que es posible
establecer correspondencia entre un modelo UML a un lenguaje de programacin como Java, C++ o visual Basic, incluso tablas en una base
de datos relacional. Esta correspondencia permite la ingeniera directa, la generacin de cdigo a partir de un modelo UML. De lo contrario
tambin se puede construir un modelo de UML a partir de una implementacin (Ingeniera Inversa) .

Ing. Ernesto Soto Roca

14

1.4 UN LENGUAJE PARA DOCUMENTAR.

En la ingeniera de software se producen varios artefactos adems de cdigo ejecutable. Plan de proyecto, anlisis diseo, implementacin ,

prototipos, versiones.
BLOQUES DE CONSTRUCCION DE UML.
UML esta compuesto de 3 bloques de construccin: Elementos, Relaciones, y Diagramas.

Elementos estructurales

Elementos

Relaciones

Diagramas

Clase
Interfaz
Colaboracin
Caso de uso
Clase activas, componentes y nodos

Elementos de comportamiento

Interaccin
Maquina de estado

Elementos de agrupacin

Paquete

Elementos de anotacin

Nota

Dependencia
Asociacin
Generalizacin
Realizacin
Diagramas Estticos
Diagramas de clase
Diagramas de objeto
Diagramas de componentes
Diagramas de despliegue
Diagramas dinmicos
Diagramas de caso de uso
Diagramas de secuencia
Diagramas de actividades
Diagramas de colaboracin
Diagramas de estado

2
ELEMENTOS ESTRUCTURALES.
Son las partes estticas de un modelo, y representan cosas que son conceptuales o materiales.
2.1
CLASE.Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de ella podemos
modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, es una descripcin de un conjunto de objeto que
comparten los mismos atributos, es representada por un rectngulo que posee tres divisiones:
En donde:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser prvate,
protected o public).
Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno
(dependiendo de la visibilidad: prvate, protected o public).

Ejemplo:
Una Cuenta Corriente que posee como caracterstica:
Balance
Puede realizar las operaciones de:
o Depositar
o Girar
o y Balance
Atributos:
Un atributo es una propiedad de una clase, identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de
la propiedad, una clase puede tener cualquier nmero de atributos o no tener ningunos. Representa alguna propiedad del elemento que se esta
modelando que es compartida por todos los objetos de esa clase.
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y visibilidad de ellos con el
entorno, estos son:
public: Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

prvate: Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar).

Ing. Ernesto Soto Roca

15

protected (#,): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la
clase adems de las subclases que se deriven (ver herencia).

Operaciones o mtodos:
Una operacin o un servicio es la implementacin de un servicio que puede ser requerido a cualquier objeto de la clase. Los mtodos u
operaciones de una clase son la forma en como sta interacta con su entorno, stos pueden tener las caractersticas:
public: Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

Prvate: Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden accesar).
Protected: Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase
adems de mtodos de las subclases que se deriven (ver herencia).

2.2 INTERFAZ.
Interfaz es una coleccin de operaciones que sirve para especificar un servicio de una clase o de un componente

<<Interface>>

Se puede dibujar una interfaz como una clase estereotipada, indicando sus
operaciones. Esto cuando se necesite visualizar los detalles del propio
servicio

SOCIO
Obtener_deudas()
Obtener cuotas()

Instancia :: Clase.
Cuando solo sea necesario especificar la presencia de una lnea de separacin en el sistema

Ejemplo: 1

Ejemplo: 2

M o d u lo
C a je r o

G e re n c ia

C lie n te
C o d _ C lie n t e : c h a r ( 1 0 )
C o d _ G ru p o : c h a r(1 0 )
M o n t o : in te g e r
E s ta d o : c h a r(1 0 )
1

M o d u lo
E n c a r g a d o d e A g e n c ia

C on yuge
C o d _ U s u a r io :
c h a r(1 0 )
R o l_ R e la c io n :
c h a r(3 0 )

C e n tr a l d e R ie s g o
N
A
A
C

o m b r e s :c h a r ( 5 0 )
p p :c h a r(1 0 )
p m :c h a r(1 0 )
I: C h a r ( 2 0 )

E n c a rg a d o
d e a g e n c ia

fr m F o rm a r G ru p o

C o n ta d o r

A sesor

G ru p o
C o d _ G ru p o : C h a r(1 0 )
N o m b re : c h a r(5 0 )
Z o n a : c h a r(3 0 )
C o d _ E m p le a d o : C h a r ( 1 0 )
C o r r e la tiv o : in t e g e r

u s u a rio
d e l s is t e m a

In g r e s o a l
s is te m a

S is t e m a d e
I n f o r m a c i n
d e C r d it o s

fr m N u e v o U s u a r io

M o d u lo
E n c a r g a d o d e S is t e m a s
E n c a rg a d o
d e S is te m a s

M o d u lo
U s u a rio

U s u a r io S is te m a T r a n s

M o d u lo
G e r e n c ia

M o d u lo
C o n t a b il id a d

u s u a r io

n u e v o ()
g ra b a r()
fo rm a rg ru p o ()
C a n c e la r ( )

C a je r o

R u b ro
C o d _ R u b ro :
C h a r(1 0 )
D e s c r ip c i n :
c h a r(5 0 )

*
1

C o d _ U s u a r io : c h a r ( 1 0 )
C iu d a d : c h a r ( 3 0 )
N o m b re s : c h a r(5 0 )
A p p : c h a r(3 0 )
A p m : c h a r(3 0 )
C I : C h a r(2 0 )
E C iv il : c h a r ( 1 0 )
S e x o : c h a r(1 0 )
F e c h a _ N a c im ie n t o : d a t e
D ir e c c i n : c h a r ( 5 0 )
D ir e c c io n _ E s p e c if ic a : c h a r ( 5 0 )
T e le f o n o : in t e g e r
C o d _ R e g io n a l : c h a r ( 1 0 )
C o d _ D p to : c h a r(1 0 )
C o d _ C iu d a d : c h a r ( 1 0 )
C o d _ A g e n c ia : c h a r ( 1 0 )
C o d _ Z o n a : c h a r(1 0 )
C o d _ R u b ro : C h a r(1 0 )
G u a rd a r()
C a n c e la r ( )

E m p le a d o

1
*

C o d _ E m p le a d o : c h a r ( 1 0 )
C a rg o : c h a r(3 0 )
N iv e l : in te g e r
Id e : c h a r(1 0 )
P a s s w o rd : c h a r(1 0 )
E s ta d o : C h a r(1 0 )

Zona

C
C
C
C
C
N
D

o d _ Z o n a : c h a r(1 0 )
o d _ R e g io n a l : c h a r ( 1 0 )
o d _ D p to : c h a r(1 0 )
o d _ C iu d a d : c h a r ( 1 0 )
o d _ A g e n c ia : c h a r( 1 0 )
o m b re _ Z o n a : c h a r(3 0 )
ir e c c io n _ Z o n a : c h a r ( 3 0 )

2.3 COLABORACION.
Una colaboracin es una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un
comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos.
La parte estructural de una colaboracin se representa mediante diagramas de clase y la parte de comportamiento se representa mediante un
diagrama de interaccin o de secuencia

2.4 CASOS DE USO.

Un caso de uso especifica el comportamiento de un sistema o de una parte del mismo, y es una descripcin de un conjunto de secuencias de
acciones, variantes que ejecuta un sistema para producir un resultado observable de valor para un actor.
Actor. Un actor representa un rol que es jugado por una persona, un dispositivo hardware, otro sistema que interacta con nuestro sistema.
Relacin de inclusin <<Include>> <<Usa>>.Se usa para evitar describir el mismos flujo de eventos repetidas veces, poniendo el comportamiento comn en un caso de uso aparte
Ejemplo:

<< include>>
Realizar
Solicitud

Verificar central
de riesgo

<< include>>
Asesor:Empleado

Registrar
cliente

Ing. Ernesto Soto Roca

16

Relacin de extensin <<Extend>>.Una relacin de extensin se utiliza para modelar la parte de un caso de eso que el usuario puede ver como comportamiento opcional del
sistema. De esta forma, se separa el comportamiento opcional del obligatorio. Tambin se puede utilizar una relacin de extensin para
modelar un subflujo separado que se ejecuta bajo ciertas condiciones, tambin se puede utilizar para modelar varios flujos que se pueden
insertar en un punto dado, controlado por las interacciones explicitas con un actor.
Ejemplo:
<< extend>>
Realizar
Pago

Efectivo

<< extend>>
Tarjeta de
credito

Carlos::Cliente

2.5 COMPONENTE
Los componentes se utilizan para modelar los elementos fsico que pueden hallarse en un nodo, tales como ejecutable, tablas, archivos y
documento. Normalmente un componente representa el empaquetamiento fsico de elementos que por el contrario son lgico, tales como
clases, interfaces y colaboraciones.

<<Interface>>
Observador
Abortar:int
Error:int

System::vgi.dll

ActualizarImagen():boolean

Observador
Realizacin (Una interfaz que el componente ofrece como servicios a otros componente)

2.6 NODO.
Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que, generalmente, tiene alguna
memoria y, a menudo, capacidad de procesamiento

ventas

S: Servidor
Velocida=200M
HZ
Memoria=256
mb

Ejemplo:

Encender ()
Apagar()

Ing. Ernesto Soto Roca

17

2.7 ELEMENTOS DE COMPORTAMIENTO.

Son las partes dinmicas de los modelos UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y el espacio
2.7.1 Interaccin.
Conjunto de mensajes intercambiados entre un conjunto de objeto.
En UML Los aspectos estticos se modelan mediante diagramas de clases, diagramas de objetos, estos diagramas permiten especificar,
construir, y documentar los elementos del sistema. (Clases, interfaces, componentes, nodos, casos de uso as como la forma en que estos
elemento se relacionan entre si).
Los aspectos dinmicos de un sistema se modelan mediante interacciones, mensajes enviados entre objetos

Mensaje

F:Forma

1:Retirar dinero ()

C:Usuario
Registrar usuario()

2: introducir PIN ()

Introducir datos()

2.7.2

Maquinas de estado.

Las maquinas de estado se utilizan para modelar aspectos dinmicos de un sistema la mayora de las veces, esto implica modelar la vida de
las instancias de una clase, un caso de uso, o un sistema completo.

Estado
2.8 ELEMENTOS DE AGRUPACIN.
2.8.1
Los Paquetes
Son las partes organizativas de los modelos UML. Al contrario que los componentes (que existen en tiempo de ejecucin), un
paquete es puramente conceptual, solo existe en tiempo de desarrollo. Sirven para organizar los elementos en grupo.

Reglas de
negocio

Frameworks

Nota

2.9 ELEMENTOS DE ANOTACIN

Son parte explicativa de los modelos UML. Es simplemente un smbolo para mostrar restricciones y comentarios.

Ing. Ernesto Soto Roca

18

2.10 RELACIONES
Una relacin es una conexin entre elementos: Entre las ms importantes tenemos Dependencia, Asociacin, Generalizacin y Interaccin.
2.10.1
Dependencia.
Una relacin de dependencia es una relacin que se usa cuando se quiere indicar que un elemento utiliza a otro, y cualquier
cambio en la especificacin del elemento puede afectar a otra que la utiliza, pero no necesariamente a la inversa.
Representacin.Ejemplo:
HIJO
FACTURA

DETALLE _ FACTURA
Producto char(70)
Unidad decimal (10,2)
Cantidad decimal(10,2)
Precio decimal(10,_2)

Cod_Factura int
Fecha datetime
Cliente char(50)
Nit integer

2.10.2

EMPLEADO
Cod_empleado int
Fecha_nacim

Nombre_hijo
Apm
Fecha_nacimiento

App
Apm

Generalizacin.
Las Generalizaciones se utilizan cuando se quieran mostrar relaciones padre/hijo o Superclase / subclase, donde la Superclase
generaliza los atributos comunes de la subclase o clases especializadas.
Se representa con una lnea continua terminada en flecha vaca apuntando al padre.

Cliente
Cod_cliente int
Nombre char(50)
Direccin char(50)

Natural
Fecha_Nacimiento
App char(50)

Ing. Ernesto Soto Roca

Empresa
nit
representante_legal

Diagrama de clases describiendo diferentes tipos de Mueble, Asiento y Mesa, con sus
respectivas subclases.

19

2.10.3

Asociacin.
Las asociaciones se utilizan cuando se quieren representar relaciones estructurales, especifica que los objetos de un elemento
estn conectados con los elementos de otro.
2.10.3.1
Rol.Mujer
MATRIMONIO
PERSONA
Rol.-Es lo que representa la clase de un extremo de la asociacin a
la clase del otro extremo

Nombre
App
Apm

Hombre
Trabaja
EMPRESA
EMPLEADO
JEFE
2.10.3.2
Multiciplidad.La multiciplidad seala cuantos objetos pueden conectarse a travs de una instancia de una asociacin, describe un rango de
valores explcitos de la asociacin.
1..0,1..1,1..*, *..*
PERSONA

2.10.3.3

Asociaciones reflexivas.

Diagrama de clases describiendo una asociacin reflexiva para la clase

Persona.

Ing. Ernesto Soto Roca

20

2.10.3.4

Agregacin.-

La relacin de agregacin se utiliza para modelar relacin todo/parte en la cual una clase representa una cosa grande (el todo) que
consta de elementos mas pequeos (las partes). Modela relacin del tipo Tiene un,Forma parte de, esta compuesto de
(El objeto base utiliza al incluido para su funcionamiento). Es un tipo de relacin dinmica, en donde el tiempo de vida del
objeto incluido es independiente del que lo incluye.

Ejemplo:
*

UNIVERSIDAD

*
ADMINISTRATIVOS

*
ESTUDIANTES

2.10.3.5

Composicin

La composicin es una forma de agregacin, con una fuerte relacin de pertenencia y vidas coincidente de la parte con el todo. En
una agregacin compuesta un objeto puede formar parte de solo una parte compuesta a la vez. (El Objeto base se construye a
partir del objeto incluido). Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye.

Ing. Ernesto Soto Roca

21

UNIVERSIDAD

ADMINISTRATIVOS

1
Ejemplo.
ESTUDIANTES

En donde se destaca que:

Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).

Cuando se destruye el Objeto Almacn tambin son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.

La composicin se destaca por un rombo relleno.

La agregacin se destaca por un rombo transparente.

La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado. Cuando no
existe este tipo de particularidad la flecha se elimina .

Ing. Ernesto Soto Roca

22

2.10.3.6
Clase asociacin.
La asociacin puede tener propiedades.

Ejemplo.

PERSONA

0.* EMPRESA
1

CONTRATO

2.11 DIAGRAMAS.
Un diagrama es una representacin grafica de un conjunto de elementos, se utilizan para ver al sistema de diferentes perspectivas. Como
ningn sistema puede ser comprendido completamente desde una nica perspectiva UML utiliza 9 diagramas que permiten centrase en
diferentes aspectos del sistema independientemente.

2.11.1

Clasificacin de Diagramas

Se dispone de dos tipos diferentes de diagramas los que dan una vista esttica del sistema y los que dan una visin dinmica.

Diagramas estticos
o Estructurales

1. Diagramas de clase
2. Diagramas de objeto
3. Diagramas de componentes
4. Diagramas de despliegue implementacin

Diagramas dinmicos
o de Comportamiento

1. Diagrama de casos de uso

2. Diagrama de secuencia
3. Diagrama de actividad
4. Diagrama de colaboracin
5. Diagrama de estado

La practica de crear diagramas para visualizar sistemas desde perspectivas o vistas diferentes no est limitado a la industria de la
construccin. En el contexto del software, existen cinco vistas complementarias que son las ms importantes para visualizar, especificar,
construir y documentar la arquitectura del software. En el UML las vistas existentes son:

Ing. Ernesto Soto Roca

23

2.12 DIAGRAMAS ESTTICOS

2.12.1
Diagramas de clase.
Este diagrama sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de
uso y de contenido.
Representa un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas

Ejemplo 1.
Una Persona del cual se desea almacenar un Nombre, Direccin,
y Nmero del Seguro Social. Puede trabajar en algn proyecto y
ganar un salario. Una Compaa tiene un Nombre, Direccin,
Nmero de Telfono, y Producto Primario. Una Compaa contrata
y despide Personas. El contrato de trabajo depende de la persona y
de la compaa. Hay dos tipos de Personas: Trabajadores y
Administradores. Cada Trabajador est involucrado en varios
Proyectos; cada Administrador es responsable de varios proyectos.
En un proyecto pueden trabajar varios trabajadores y un solo
administrador. Cada proyecto tiene un Nombre, Presupuesto, y una
Prioridad Interna para asegurar recursos. Adems una Compaa
est compuesta de mltiples Departamentos; cada departamento
dentro de una compaa se identifica de forma nica por su
Nombre.
Un departamento usualmente tiene un administrador. La mayora
de los administradores manejan un departamento; y algunos
administradores no estn asignados a ningn departamento. Cada
departamento manufactura varios productos; mientras que cada
producto est hecho por un solo departamento. Un producto tiene Nombre, Costo, y Peso.

2.12.2

Diagramas de objeto.

Un diagrama de objeto es esencialmente una instancia una instancia de un diagrama de clase o la parte esttica de un diagrama de
interaccin, en un diagrama de objeto podremos encontrar objetos y enlaces

DIAGRAMA DE CLASE

2.12.3

DIAGRAMA DE OBJETO

Diagrama de Componentes

Un diagrama de componentes muestra las organizaciones y dependencias lgicas entre componentes software, sean stos componentes de
cdigo fuente, binarios o ejecutables. Los elementos de modelado dentro de un diagrama de componentes sern componentes y paquetes. En
cuanto a los componentes, slo aparecen tipos de componentes, ya que las instancias especficas de cada tipo se encuentran en el diagrama de
despliegue.
Cada componente en el diagrama debe ser documentado con un diagrama de componentes ms detallado, un diagrama de clases, o un
diagrama de casos de uso.
Un paquete en un diagrama de componentes representa una divisin fsica del sistema. Los paquetes se organizan en una jerarqua de capas
donde cada capa tiene una interfaz bien definida. Un diagrama de componentes se representa como un grafo de componentes software unidos
por medio de relaciones de dependencia (generalmente de compilacin).
Normalmente los diagramas de componentes se utilizan para modelar cdigo fuente, versiones ejecutables, bases de datos fsicas, entre otros.
Cdigo fuente: En el modelado de cdigo fuentes se suelen utilizar para representar las dependencias entre los ficheros de cdigo fuente, o
para modelar las diferentes versiones de estos fichero. Para ello se deben identificar el conjunto de archivos de cdigo fuente de inters y
estereotiparlos como archivos file, agruparlos en paquetes, utilizar valores etiquetados para la informacin de versiones y modelar las
dependencias de compilacin.
Cdigo ejecutable: Se utiliza para modelar la distribucin de una nueva versin a los usuarios. Para tal propsito se identifican el conjunto
de componentes ejecutables que intervienen, se utilizan estereotipos para los diferentes tipos de componentes (ejecutables, bibliotecas, tablas,
archivos, documentos, etc.), se consideran las relaciones entre dichos componentes que la mayora de las veces incluirn interfaces que son
exportadas (realizadas) por ciertos componentes e importadas (utilizadas) por otros.
Bases de datos fsica: UML permite el modelado de bases de datos fsicas as como de los esquemas lgicos de bases de datos.
As si tenemos en cuenta las dependencias asociadas al proceso de compilacin un componente podra ser:
Cdigo fuente: que depende de otros componentes (no necesariamente cdigo fuente) que deben estar disponibles durante la compilacin
del componente.
Ing. Ernesto Soto Roca

24

Cdigo objeto binario: como por ejemplo una librera, que puede depender de algn cdigo objeto con el que se linkea.
Cdigo ejecutable: que puede depender de otros programas ejecutables con los que interaccionan en tiempo de ejecucin.
El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo las dependencias entre los componentes de
software, los componentes de cdigo binario, y los componentes ejecutables. En el Diagrama de Componentes se modela componentes del
sistema, a veces agrupados por paquetes, y las dependencias que existen entre componentes (y paquetes de componentes).

Ing. Ernesto Soto Roca

25

2.12.4 Diagramas de Implementacin /Despliegue

Los Diagramas de Implementacin se usan para modelar la configuracin de los elementos de procesado en tiempo de ejecucin (run-time
processing elements) y de los componentes, procesos y objetos de software que viven en ellos.
Los Diagramas de Implementacin se usan para modelar slo componentes que existen como entidades en tiempo de ejecucin; no se usan
para modelar componentes solo de tiempo de compilacin o de tiempo de enlazado. Puedes tambin modelar componentes que migran de
nodo a nodo u objetos que migran de componente a componente usando una relacin de dependencia con el estereotipo 'becomes' (se
transforma)

Figura: Modelando la Distribucin del Sistema con el Diagrama de Implementacin

Ing. Ernesto Soto Roca

26

2.13 DIAGRAMAS DINMICOS

2.13.1
Diagrama de Casos de Usos.
Se emplea para visualizar el comportamiento del sistema, una parte de l o de una sola clase; y como se relaciona con su entorno. De sta
forma se puede conocer como responde sa parte del sistema ante un estmulo del ambiente. El diagrama de uso es muy til para definir
como debera ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como estn
implementadas las partes que define.
Un caso de uso especifica un requerimiento funcional.
Elementos

Actor

2.13.2

Caso de uso

Diagrama de Secuencia

Este diagrama (tambin llamado diagrama de interaccin) muestra las interacciones entre un conjunto de objetos (clases, actores), ordenadas
segn el tiempo en que tienen lugar. Es decir, muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a
representar. Es imposible representar en un solo diagrama la secuencia de todas las llamadas posibles del sistema, es por ello que se escoge
un punto de partida. El diagrama se compone con los objetos que forman parte de la secuencia, estos se sitan en la parte superior de la
pantalla, normalmente a la izquierda se sita el que inicia la accin. De estos objetos sale una lnea que indica su vida en el sistema. Esta
lnea simple se convierte en una lnea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando l esta activo.
El objeto puede existir slo durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la ejecucin de la interaccin.
En este tipo de diagramas tambin intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita
(llama a) una operacin del objeto destino. El diagrama de secuencia puede ser obtenido de dos partes, desde el Diagrama Esttico de Clases
o desde el de Casos de Usos.
Elementos
Los componentes de un diagrama de interaccin son:
Lnea de vida

Un objeto (o actor) se representa como una lnea vertical punteada con un rectngulo de encabezado y con rectngulos a travs de la lnea
principal que denotan la ejecucin de mtodos (activacin). El rectngulo de encabezado contiene el nombre del objeto y el de su clase.
Activacin
Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin, bien sea por s mismo o por medio de
delegacin a alguno de sus atributos. Se denota como un rectngulo delgado sobre la lnea de vida del objeto.
Mensajes

El envo de mensajes entre objetos se denota mediante una lnea slida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo
ejecuta. Representa la llamada de un mtodo (operacin) de un objeto en particular.

Tambin es posible visualizar llamadas a mtodos desde el mismo objeto en estudio.

El presente diagrama es til para observar la vida de los objetos en el sistema, identificar llamadas a realizar o posibles errores del modelo
esttico, que imposibiliten el flujo de informacin o de llamadas entre los componentes del sistema.

2.13.3

Diagrama de Colaboracin

Este diagrama muestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos
organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra
las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas
de colaboraciones expresan informacin similar, pero en una forma diferente.
Elementos
Los elementos que intervienen en stos diagramas son: objetos, enlaces y flujos de mensajes.
Objeto
Un objeto se representa con un rectngulo, que contiene el nombre y la clase del objeto. Un objeto es una instancia de una clase que participa
como una interaccin, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la
actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.
Enlace:
Un enlace es una instancia de una asociacin en un diagrama de clases. Se representa como una lnea continua que une a dos objetos en este
diagrama. Esta acompaada por un nmero que indica el orden dentro de la interaccin y por un estereotipo que indica que tipo de objeto
recibe el mensaje. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica
que puede existir un intercambio de mensajes entre los objetos conectados.
Flujo de mensajes

Ing. Ernesto Soto Roca

27

Expresa el envo de un mensaje. Se representa mediante una flecha dirigida cercana a un enlace. Los mensajes que se envan entre objetos
pueden ser de distintos tipos, tambin segn como se producen en el tiempo; existen mensajes simples, sincrnicos, balking, timeout y
asncronos.
Durante la ejecucin de un diagrama de colaboracin se crean y destruyen objetos y enlaces.

2.13.4

Diagrama de estado

Representan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a
estmulos recibidos. Representa lo que podemos denominar en conjunto una mquina de estados. Un estado en UML es cuando un objeto o
una interaccin satisfacen una condicin, desarrolla alguna accin o se encuentra esperando un evento.
Cuando un objeto o una interaccin pasa de un estado a otro por la ocurrencia de un estmulo o evento se dice que ha sufrido una transicin,
existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Adems una transicin puede ser interna si el
estado del que parte el objeto o interaccin es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del
estado, no de la transicin.

Ing. Ernesto Soto Roca

28

2.13.5

Diagrama de actividad

Son similares a los diagramas de flujos de otras metodologas OO. En realidad se corresponden con un caso especial de los diagramas de
estado donde los estados son estados de accin (estados con una accin interna y una o ms transiciones que suceden al finalizar esta accin,
o lo que es lo mismo, un paso en la ejecucin de lo que ser un procedimiento) y las transiciones vienen provocadas por la finalizacin de las
acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin de un caso de uso o de un mtodo
(que tiene el mismo significado que en cualquier otra metodologa OO). Los diagramas de actividad se utilizan para mostrar el flujo de
operaciones que se desencadenan en un procedimiento interno del sistema.
Transiciones
Calles - Swinlane

Bifurcacion

Ejemplo 1.

Estado de Accion

Ing. Ernesto Soto Roca

29

CASO DE ESTUDIO
SISTEMA DE INFORMACIN DE FACTURACIN PARA EL SERVICIOS DE AGUA POTABLE QUE BRINDA LA
COOPERATIVA DE SERVICIOS PUBLICOS SEMCAP LTDA

Ing. Ernesto Soto Roca

30

1.
MODELO DE NEGOCIO.
El modelado de negocio tiene como finalidad presentar un modelo de la empresa, cuales son las actividades principales que realiza y
quienes la realizan: Para tal objetivo se realizan las siguientes actividades:
13. Identificacin de los procesos de negocio
14. Identificacin de los usuarios, departamentos o elementos de la organizacin implicados en el proceso de negocio.
15. Establecer las acciones necesarias para realizar el proceso de negocio.
16. Diagrama de actividades que represente el proceso de negocio
17. Listado de las actividades.
18. Informacin generada o utilizada en cada actividad.
19. Reglas de negocio.
1.1. Identificacin de los procesos de negocio.
Un proceso de negocio es un objetivo estratgico de la organizacin. Con la descomposicin en procesos de negocio pretendemos
identificar las actividades de alto nivel que desarrolla la empresa. En este punto simplemente listamos los procesos que observamos en
la organizacin para luego abordarlo uno a uno. La funcionalidad estar repartida en varios proceso de negocio.
Facturacin
1.2. Identificacin de los usuarios, departamentos o elementos de la organizacin implicados en el proceso de negocio.
Estos usuarios pueden ser: Sistemas de informacin, Interfaces de Dispositivos hardware, Personas que realizan tareas operacionales
en el sistema.
1.
2.
3.

Presidente Administrativo.
Asistente Administrativo.
Encargado de Sistemas.

4. Cajero.
5. Contador.

Donde:
Usuarios del sistema se considera como usuario del sistema a toda persona que va a tener una relacin ya sea como
Empleado, socio con el sistema de facturacin de la cooperativa.
Presidente administrativo. Es la persona responsable de la administracin del la cooperativa, por ser el presidente del consejo
de administracin.
Asistente Administrativo. Persona responsable de tareas operacionales-administrativa de la cooperativa de la cooperativa.
Cajero. Es un empleado de la Cooperativa responsable de una de la caja que fue abierta por el Presidente administrativo.
Contador. Es un sistema contable de la cooperativa con el cual se relaciona mediante archivo de formato simple (texto) y
reportes contables.
Encargado de sistema Es la persona que tiene como responsabilidad realizar tareas de mantenimiento y administracin del
sistema computacional
1.3. Establecer las acciones necesarias para realizar el proceso de negocio.
Se describe en forma informal las interacciones entre los roles necesarios para que se cumpla el proceso de negocio con xito y los
responsables de dichas funciones.
4.

5.

6.

7.

8.

Presidente Administrativo.

Realizar Apertura del sistema

Abrir Caja

Aprobar Revertir Solicitudes en gerencia administrativa.

Reposicin de dinero.

Cierre definitivo de caja

Cierre del sistema.

Asistente Administrativo.

Registrar Socio

Registrar Solicitudes de aportaciones

Registrar lecturacion
Encargado de Sistemas.

Realizar backup del sistema

Edicin de parmetros

Tipo de cambio

Tipo de transaccin
Cajero

Realizar recuperaciones

Facturas de consumo.

Reconexiones

Trasferencias de aportaciones

Cierre preliminar de caja

Reportes:

Transacciones

Planilla caja consolidada

Contador

Listado de ingresos mensuales

Cuentas por pagar

Ing. Ernesto Soto Roca

31

1.4.

Diagrama de actividades que represente el proceso de negocio.

Diagrama de actividades sistema de facturacin

1.5. Listado de las actividades.
Realizar apertura del sistema: Funcin Iniciada por el Presidente administrativo tiene como objetivos registrar fluctuaciones en el tipo de
cambio en moneda extranjera (dlares) y bolivianos.
Abrir caja: Funcin Iniciada por el Presidente administrativo tiene como objetivo habilitar las cajas para que los cajeros puedan realizar
transacciones como ser: Ingresos (Facturas, Reconexiones, Transferencia de aportaciones).
Aprobar revertir solicitudes en Presidente administrativo Funcin Iniciada por el Presidente administrativo, tiene como objetivo la
aprobacin de la solicitud en segunda instancia por el Presidente administrativo. La reversin se realiza cuando solicitudes de aportaciones
han sido aprobado por el asistente administrativo. La aportacin regresa al asistente administrativo como primera instancia de aprobacin.
Reposiciones de dinero del Administrativo: Funcin Iniciada por el Presidente administrativo a solicitud de uno de los cajeros tiene como
objetivo controlar que el dinero circulante dentro de la Cooperativa este dentro de los parmetros necesarios.
Cierre definitivo de caja: Funcin Iniciada por el Presidente administrativo tiene como objetivo hacer el cierre definitivo la una caja
cerradas preliminarmente por el cajero, y hacer la reposicin del dinero a bveda.
Realiza el cierre del sistema. Funcin Iniciada por el Presidente administrativo, tiene como objetivo el cierre del sistema se realiza cuando
se han cerrado todas las cajas y se ha hecho la reposicin a bveda. Se actualizan consolidan todas las transacciones.
Registrar Socio: Funcin Iniciada por el Asistente administrativo, tiene como objetivo dar de alta a un Socio natural o juridicos de la
Cooperativa.
Realizar solicitudes: Funcin Iniciada por el Asistente administrativo, tiene como objetivo registra una solicitud de nuevo socio y su
aprobacin en primera instancia.
Registrar Lecturacion. Funcin Iniciada por el Asistente administrativo, tiene como objetivo registrar la lecturacion del consumo de agua
mensual del medidor (consumo = Lectura actual- lectura anterior) para fu respectiva facturacin.
Realizar recuperaciones Funcin Iniciada por el cajero, tiene como objetivo registrar los ingresos como ser por conceptos de facturacin,
reconexiones, transferencias de aportaciones.
Cierre preliminar de caja: Funcin Iniciada por el cajero tiene como objetivo Cerrar su caja para que luego el Presidente administrativo
pueda ver el planilla consolidada, y proceda con el cierre definitivo de la caja.
Listados de cajas y detalle de transacciones. Funcin Iniciada por el cajero, tiene como objetivo la impresin de reportes como:
Detalle de transacciones
Planilla de caja consolidada.
Realizar backup. Funcin Iniciada por el encargado de sistema realiza tareas de backup de los diferentes mdulos y base de datos.
Edicin de parmetros de clculos. Funcin Iniciada por el encargado de sistema realiza tareas de edicin de los diferentes parmetros de
calculo como ser tipo de cambio, tipos de aportacin.

Ing. Ernesto Soto Roca

32

1.6. Informacin generada o utilizada en cada actividad.

En este punto se debe registrar toda informacin que se maneja en la actividad, con un lenguaje cercano al usuario.

Realizar Apertura del sistema.

TC = {Fecha_Apertura, VCompra, VVenta}
Abrir Caja
CAJA= {Cod_caja, Monto_apertura_Bs, Fecha_Apertura, Estado, Cod_empleado}
Aprobar Revertir Solicitudes en gerencia administrativa.
APORTACIN = {...Estado= (2, 3)} donde:
2=Registrada y aprobada por el asistente adm.
3=Aprobada por el Presidente administrativo

Reposicin de dinero.
TRANSACCION= {Cod_Transaccion, Origen= (Bobeda, Caja), destino= (Caja, Bobeda), Tipo_Transaccion =(32,33.),

Cierre definitivo de caja

HCAJA= {Cod_caja, Monto_apertura_Bs, Fecha_Apertura, Estado, Cod_empleado}
HTRANSACCION= {Origen, Destino, Tipo_Transaccion, Fecha_Transaccion, Monto, Cod_Caja}
Registrar Socio.
SOCIO= {Cod_Socio, Direccin}
P_NATURAL= {Cod_Socio, Doc_Identidad, App, Apm, Fecha_Nacimiento}
P_JURIDICA= {Cod_socio, nit, Razon_Social, Rpte_legal,

Fecha_Transaccion, Monto, Cod_Caja}

Registrar Solicitudes de aportaciones

APORTACIN = {Cod_Aportacion, Fecha_Incripcion, Plazo_Meses, Estado, Cod_tipo_Aportacion,

Registrar lecturacion
FACTURA = {Cod_Factura, Cod_Aportacion, Lectura_Anterior, Lectura_Actual, Fecha_Emision, Monto_consumo,
Fecha_pago, Consumo_agua, Precio_M3, Estado_pagado, Mes_Pago, Ao_Pago, Monto_consumo, Tipo_cambio}
Realizar recuperaciones
FACTURA ={Cod_Factura, Cod_Aportacion, Fecha_pago, Estado_pagado }
TRANSACCION = {Cod_Transaccion, Origen= Pago=factura, destino= Caja, Tipo_Transaccion =1,

CutaInicial_Aportacion, CuotaInicial_Accesorio, Zona, Barrio, Calle, Lote}

Fecha_Transaccion, Monto, Cod_Caja}

Reconexiones
RECONEXIONES= {Cod_reconexion, Cod_aportacion, Monto, Estado, Mes_pago, Ao_Pago, Fecha_pago}

Trasferencias de aportaciones
TRANFERENCIA= { Cod_aportacion, Fecha_tranferencia, Estado, Motivo}
Cierre preliminar de caja
CAJA ={Cod_reconexion, Cod_aportacion, Monto, Estado, Mes_pago, Ao_Pago, Fecha_pago}

1.7. Reglas de negocio.

Las reglas de negocio son una serie de restricciones de la organizacin a la hora de realizar una actividad.

El valor de compra de dlar debe ser menor al de la venta.

No se acepta socio menores a 18 aos.

Si no existe lecturacion o consumo de agua de factura como consumo mnimo.

Ing. Ernesto Soto Roca

33

2.
MODELO DE REQUISITOS.
En el modelos de requisitos identificamos las tareas que ha a implementar el sistema de informacin, haciendo una descripcin de estos
requisitos y se crea un diseo conceptual que represente fielmente el proceso de negocio. Para tal objetivo se realizan tres actividades:
1.
Identificacin de los casos de Uso.
2.
Descripcin de los casos de uso.
3.
Crear el modelo conceptual.
2.1.
Identificacin de los casos de Uso.
A partir de los diagramas de actividades del modelo de negocio construimos un diagrama de caso de uso, asociando los estados de accin a
una clase o un caso de uso y el agente que lo realiza como el actor del caso de uso.

Modelo de caso de uso en fase de requisitos.

2.2.
Descripcin de los casos de uso.
Para la descripcin de casos de uso se usan plantillas que pueden ser definidas de diferentes maneras, siempre y cuando se utilice la misma
durante todo el proyecto, y todos los miembros del equipo de desarrollo sepan como interpretarla. Ene este caso utilizaremos la siguiente
plantilla.

Caso de uso
Objetivo
Actores
Precondiciones
Pasos

:
:
:
:
:

Variaciones
Extensiones

:
:

Nombre del caso de uso.

Descripcin informal de los objetivos del caso de uso.
Actores que intervienen en el caso de uso, principales y secundarios.
Condiciones que debe cumplirse para que pueda realizarse el caso de uso.
Secuencia de pasos necesarios para que el caso de uso se desarrolle con xito y
Las interacciones de los actores (A) y las acciones del sistema (S).
Variaciones en la secuencia de pasos
Puntos de extensin del caso de uso

Ing. Ernesto Soto Roca

34

2.3.

Crear el modelo conceptual.

Modelo conceptual del sistema de facturacin en fase de requisitos

Ing. Ernesto Soto Roca

35

3.

MODELO DE ANALISIS.

En este modelo se implementaran los artefactos que sern un punto de partida para el modelo de diseo. Para realizar dicho
modelo se deben seguir lo siguientes pasos:
1.
2.
3.
4.
3.1.

Identificacin de los actores definitivos del sistema.

Identificacin de los casos de uso y sus extensiones.
Se crea un modelo de casos de uso (Actualizando el modelo de CDU. del Modelo de requisitos con sus relaciones de Usa y
Extend).
Se crea un diagrama de secuencia y de colaboracin para cada caso de USO.
Identificacin de los actores del sistema.

Presidente administrativo. Es la persona responsable de la administracin del la cooperativa, por ser el presidente del consejo
de administracin.
Asistente Administrativo. Persona responsable de tareas operacionales-administrativa de la cooperativa de la cooperativa.
Cajero. Es un empleado de la Cooperativa responsable de una de la caja que fue abierta por el Presidente administrativo.
Contador. Es un sistema contable de la cooperativa con el cual se relaciona mediante archivo de formato simple (texto) y
reportes contables.
Encargado de sistema Es la persona que tiene como responsabilidad realizar tareas de mantenimiento y administracin del
sistema computacional.
3.2.
Identificacin de los casos de uso y sus extensiones.
1.
Realizar apertura del sistema: Funcin Iniciada por el Presidente administrativo tiene como objetivos registrar fluctuaciones en el
tipo de cambio en moneda extranjera (dlares) y bolivianos.
2.

Abrir caja: Funcin Iniciada por el Presidente administrativo tiene como objetivo habilitar una

3.

Aprobar revertir solicitudes en Presidente administrativo Funcin Iniciada por el Presidente administrativo, tiene como objetivo la
aprobacin de la solicitud en segunda instancia por el Presidente administrativo. La reversin se realiza cuando las aportaciones no
cumplen con los requisitos (Radio o cobertura, Socios menores de edad, socios de otras Cooperativas). La solicitud de aportacin
regresa al Asistente administrativo como primera instancia de aprobacin.

4.

Reposiciones de dinero del Administrativo: Funcin Iniciada por el Presidente administrativo a solicitud de uno de los cajeros tiene
como objetivo controlar que el dinero circulante dentro de la Cooperativa este dentro de los parmetros necesarios.

5.

Cierre definitivo de caja: Funcin Iniciada por el Presidente administrativo tiene como objetivo hacer el cierre definitivo la una caja
cerradas preliminarmente por el cajero, y hacer la reposicin del dinero a bveda.

6.

Realiza el cierre del sistema. Funcin Iniciada por el Presidente administrativo, tiene como objetivo el cierre del sistema se realiza
cuando se han cerrado todas las cajas y se ha hecho la reposicin a bveda. Se actualizan consolidan todas las transacciones.

7.

Registrar Socio: Funcin Iniciada por el Asistente administrativo, tiene como objetivo dar de alta a un Socio natural o juridicos de la
Cooperativa.

8.

Realizar solicitudes: Funcin Iniciada por el Asistente administrativo, tiene como objetivo registra una solicitud de nuevo socio y su
aprobacin en primera instancia.

9.

Para la facturacin de servicios de agua potable se consideran los siguientes aspectos: Sus diferentes tipos de socio, cada socio puede
tener una o varias aportacin con un costo de 100 Sus. Por aportacin y 45 de accesorio: Aporte inicial de 20 Sus por aportacin. y 10
dlares de cuota inicial por accesorio. El saldo se Programada en un plazo 48 cuotas mensuales. Entre los tipos de aportaciones
tenemos:

10.

Registrar Lecturacion. Funcin Iniciada por el Asistente administrativo, tiene como objetivo registrar la lecturacion del consumo de
agua mensual del medidor (consumo = Lectura actual- lectura anterior) para fu respectiva facturacin.

11.

Realizar recuperaciones Funcin Iniciada por el cajero, tiene como objetivo registrar los ingresos como ser por conceptos de
facturacin, reconexiones, transferencias de aportaciones.

12.

Cierre preliminar de caja: Funcin Iniciada por el cajero tiene como objetivo Cerrar su caja para que luego el Presidente
administrativo pueda ver el planilla consolidada, y proceda con el cierre definitivo de la caja.

13.

Listados de cajas y detalle de transacciones. Funcin Iniciada por el cajero, tiene como objetivo la impresin de reportes como:

14.

Detalle de transacciones, Planilla de caja consolidada.

Realizar backup. Funcin Iniciada por el encargado de sistema realiza tareas de backup de los diferentes mdulos y base de datos.

15.

Edicin de parmetros de clculos. Funcin Iniciada por el encargado de sistema realiza tareas de edicin de los diferentes
parmetros de calculo como ser tipo de cambio, tipos de aportacin.

NOTAS: Los socios, pueden ser persona natural o jurdica. De las personas naturales se registran sus datos personales, numero de identidad,
direccin. De las personas juritas el nombre de la empresa, RUC. Y se ambas se consideran como una sola unidad en los aspectos jurdicos
y de control del sistema.

Ing. Ernesto Soto Roca

36

Solicitud de socio. En una solicitud de nuevo socio estn los siguientes datos: fecha de registro, zona ,barrio, calle y numero de lote. Tipo o
clase de aportacin, cuota inicial del certificado de aportacin, y cuota inicial de accesorios, ambos con un mismo plazo.
Las cuotas son calculadas con la siguiente formula de anualidad:

Anualidad

(C * ((1 + i) ^ t) * i)
16. ((1 + i) ^ t) - 1)

t = plazo (Semanal, bisemanal, mensual, trimestral, semestral, anual)

i = inters = ((inters anual / 100) / 360) * plazo
Se empieza con saldo capital igual a capital: Saldo Capital = C
Pagos Los pagos de las facturas debe ser realizado en caja. Se facturan los siguientes tem: consumo de agua, cuota aportacin, cuota
accesorio, y 1 Bs. De cuota mortuoria mensual.
Caja las cajas son abiertas por el Presidente administrativo al empezar el da y numero de cajas depende de la cantidad de socios a ser
atendido. Se cierran al finalizar la jornada de trabajo preliminarmente cierra el cajero, el cierre definitivo lo realiza el encargado pasando el
dinero a bveda.
Una vez cerrada la caja no puede surgir ninguna transaccin ms en el sistema.
3.3.
Extend).

Se crea un modelo de casos de uso (Actualizando el modelo de CDU. del Modelo de requisitos con sus relaciones de Usa y

Modelo de caso de uso en fase de Analisis.

3.4.

Se crea un diagrama de secuencia y de colaboracin para cada caso de USO.

Diagrama de colaboracin del caso de uso

Registrar Aportacin
Ing. Ernesto Soto Roca

37