TEORÍA 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 interacción 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 común.

MODELO.

Los modelos son constructor diseñados por un observador que persigue identificar y mensurar relaciones sistémicas complejas. Todo sistema real tiene la
posibilidad de ser representado en más de un modelo. La decisión, en este punto, depende tanto de los objetivos del modelador como de su capacidad
para distinguir las relaciones relevantes con relación a tales objetivos. La esencia de la modelística sistémica es la simplificación.

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 sinérgico en tanto el examen de sus partes en forma aislada no puede explicar o predecir su comportamiento. La sinergia es,
en consecuencia, un fenómeno que surge de las interacciones entre las partes o componentes de un sistema (conglomerado). Este concepto
responde al postulado aristotélico que dice que "el todo no es igual a la suma de sus partes". La totalidad es la conservación del todo en la
acción recíproca de las partes componentes (teleología). En términos menos esencialistas, podría señalarse que la sinergia es la propiedad
común 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 adaptación al contexto.

Es el nivel de adaptación permanente del sistema o su tendencia a la supervivencia dinámica. Los sistemas altamente homeostáticos sufren
transformaciones estructurales en igual medida que el contexto sufre transformaciones, ambos actúan como condicionantes del nivel de
evolución.

LA ENTROPÍA Es el grado de desorden de una organización. Es la perdida permanente de vida útil.

La entropía de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. Los
sistemas altamente entrópicos tienden a desaparecer por el desgaste generado por su proceso sistémico. Los mismos deben tener rigurosos
sistemas de control y mecanismos de revisión, reelaboración y cambio permanente, para evitar su desaparición a través del tiempo.

En un sistema cerrado la entropía siempre debe ser positiva. Sin embargo en los sistemas abiertos biológicos o sociales, la entropía puede ser
reducida o mejor aun transformarse en entropía negativa, es decir, un proceso de organización más completa y de capacidad para transformar
los recursos. Esto es posible porque en los sistemas abiertos los recursos utilizados para reducir el proceso de entropía se toman del medio
externo. Asimismo, los sistemas vivientes se mantienen en un estado estable y pueden evitar el incremento de la entropía y aun desarrollarse
hacia estados de orden y de organización creciente.

NEGUENTROPIA. Los sistemas vivos son capaces de conservar estados de organización improbables (entropía). Este fenómeno
aparentemente contradictorio se explica porque los sistemas abiertos pueden importar energía extra para mantener sus estados estables de
organización e incluso desarrollar niveles más altos de improbabilidad. La negentropía, entonces, se refiere a la energía que el sistema
importa del ambiente para mantener su organización y sobrevivir (Johannsen. 1975).
Neguentropia: Ya esta definido, si luego de la aplicación de mecanismos neguentrópicos, persiste el problema, se activan los mecanismos
homeostáticos.
Mecanismos homeostáticos.: Son los mecanismos encargados de corregir el problema no resuelto por la neguentropía, llevando la
conducta ó los resultados a los valores normales. Estos mecanismos son viables y eficientes dentro de ciertos rangos de desviación posible.
Algedonia: Son los mensajes que envían los mecanismos homeostáticos al sistema central (cerebro) para
Indicar que estos son incapaces de superar el problema

1
Ejemplo.

La empresa ONG. Solidaridad brindaba a sus inicios servicios de préstamos de

dinero, para realizar las tareas operacionales de la empresa utilizaba a un inicio un
sistema de información de cartera con módulos de otorgación de préstamos y otro
de evaluación financiera del cliente. En el año 2018 la ONG. Cambia de razón social
y pasa a ser FFP. Con los servicios de Prestamos, caja de ahorro, y DPF. Para
poder brindar estos servicios se requiere la adaptación del sistema actual con la
implementación de dos nuevos módulos Caja de ahorro y DPF. La implementaron
de estos nuevos módulos ocasiona un cambio del modelo de datos y el sistema
empieza a tener fallas de funcionamiento. Que son corregidos en base a
Programación. Como el volumen de información generada creció el sistema
desarrollado en Visual FoxPro empieza a disminuir su performance “Lento”. En
consecuencia la empresa toma la decisión de emprender el desarrollo de un nuevo
proyecto de sistema de información de cartera Caja de ahorro, y DPF.

1.- Identificar los sistemas de información existente en la empresa.

2.-Identificar fenómenos de: Entropía, Sinergia, Fenómenos Homeostáticos,
Neguentropia.

2
ELEMENTOS DE UN SISTEMA.
Entradas.
Las entradas son los ingresos del sistema que pueden ser recursos
materiales, recursos humanos o información. 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 importación de los recursos (energía, materia, información) 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

estadístico. Las entradas aleatorias representan entradas potenciales para un
sistema.

- Retroacción: es la reintroducción de una parte de las salidas del sistema en

sí mismo.

Importa energía y recursos del medio (recursos humanos, informáticos, financieros,

físicos, etc.).
Ley de Conservación: C.E >= C.S. · Donde : C.E.=Entrada C.S.=Salida

Cantidad de energía de un sistema = C.S. − C.E.

Procesos.
El proceso es lo que transforma una entrada en salida, como tal puede ser una
máquina, un individuo, una computadora, un producto químico, una tarea realizada
por un miembro de la organización, etc. En la transformación de entradas en salidas
debemos saber siempre como se efectúa esa transformación. Con frecuencia el
procesador puede ser diseñado 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 transformación es demasiado compleja. Diferentes

3
combinaciones de entradas o su combinación en diferentes órdenes de secuencia
pueden originar diferentes situaciones de salida. En tal caso la función 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 estímulos, 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 información. Las mismas son el resultado del funcionamiento del sistema
o, alternativamente, el propósito 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, repitiéndose este ciclo indefinidamente.

Retroalimentación:
La retroalimentación 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
información.

La retroalimentación permite el control de un sistema y que el mismo tome medidas

de corrección en base a la información 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 límites coinciden con
discontinuidades estructurales entre estos y sus ambientes, pero corrientemente la
demarcación de los límites sistémicos queda en manos de un observador (modelo).
En términos operacionales puede decirse que la frontera del sistema es aquella línea
que separa al sistema de su entorno y que define lo que le pertenece y lo que queda
fuera de él (Johannsen. 1975:66).

4
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 proporción, influye sobre el
contexto; se trata de una relación mutua de contexto-sistema.

Tanto en la Teoría de los Sistemas como en el método científico, existe un concepto

que es común a ambos: el foco de atención, el elemento que se aísla para estudiar.

El contexto a analizar depende fundamentalmente del foco de atención que se fije.

Ese foco de atención, en términos de sistemas, se llama límite de interés.

Para determinar este límite se considerarían dos etapas por separado:

a) La determinación del contexto de interés.

b) La determinación del alcance del límite de interés entre el contexto y el sistema.

a) Se suele representar como un círculo que encierra al sistema, y que deja afuera
del límite de interés 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 sólo interesen algunas de estas relaciones, con lo que habrá un límite de
interés relacional.

Determinar el límite de interés es fundamental para marcar el foco de análisis,

puesto que sólo será considerado lo que quede dentro de ese límite.

Entre el sistema y el contexto, determinado con un límite de interés, existen infinitas

relaciones. Generalmente no se toman todas, sino aquellas que interesan al análisis,
o aquellas que probabilísticamente presentan las mejores características de
predicción científica.

SUBSISTEMAS:

En la misma definición 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.

5
Estos conjuntos o partes pueden ser a su vez sistemas (en este caso serían
subsistemas del sistema de definición), ya que conforman un todo en sí mismos y
estos serían 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 están organizadas para ejecutar las transacciones para
los cuales fueron hechos, como por ejemplo: mover dinero entre cuentas, un cargo o
abono, una devolución 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 número de usuarios. Normalmente, el número de
usuarios de un DSS es menor al de un OLTP. Es común encontrar que los sistemas
transaccionales son accesados por cientos de usuarios simultáneamente, mientras
que los DSS sólo 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 tamaño a los Data Warehouses, esto es debido a que un DSS puede
estar formado por información de varios OLTP´s.

Existen también diferencia en el diseño, mientras que el de un OLPT es

extremadamente normalizado, el de un DSS tiende a ser desnormalizado. El OLTP
normalmente está formado por un número mayor de tablas, cada una con pocas
columnas, mientras que en un DSS el número de tablas es menor, pero cada una de
éstas tiende a ser mayor en número de columnas.
Los OLTP son continuamente actualizados por los sistemas operacionales del día
con día, mientras que los DSS son actualizados en batch de manera periódica.
Las estructuras de los OLTP son muy estables, rara vez cambian, mientras las de los
Data Warehouses sufren cambios constantes derivados de su evolución. Esto se

6
debe a que los tipos de consultas a los cuales están sujetos son muy variados y es
imposible preverlos todos de antemano.
OLPT
- Orientada a transacciones
- Detallada
- Actualizada en línea
- Usuarios de nivel operativo
- Corre en base a repeticiones
- Orientado a operación
- Estructura estática
- Sin redundancia
- Alta probabilidad de acceso
- Información bruta (Datos)
- Actualizada en línea
- Muchas tablas con pocas columnas
DSS
- Orientada a Conceptos
- Sumariada
- Representa valores a un tiempo (snapshot)
- Usuarios de nivel gerencial
- Corre heurísticamente
- Poco sensitivo al desempeño
- Accesa conjuntos de unidades a la vez
- Orientado a análisis
- Estructura flexible
- Con mucha redundancia
- Modesta probabilidad de acceso
- Administrada por partes
- Información procesada (Información)
- Actualizada en Batch
- Pocas tablas con muchas columnas
7
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 metodología, paradigma que transforma las
entradas o requerimientos a través de un proceso sistemático disciplinado y
cuantificable en soluciones del problema.

Características del proceso Fases del proceso Flujos de trabajo

unificado
 Dirigido por caso de uso
 Centrado en la arquitectura
 Iterativo e incremental
 Fase de inicio  Modelo de negocio
 Fase de elaboración  Requisitos
 Fase de construcción  Análisis
 Fase de transición  Diseño
 Implementación
 Prueba

Dirigido por caso de uso.-

abrir caja

cajero
cierre caja

Gerente operacional
realizar recuperaciones

apertura del sistema

Un caso de uso es una pequeña funcionalidad del sistema que devuelve al usuario
un resultado importante. Representa la unidad atómica funcional a través 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 través de todo el proceso, los casos se analizan, diseñan se
implementan y se construyen los modelos de prueba.

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 aplicación, habilidad y conocimiento del diseñador, etc.

8
Iterativo e incremental.-
Es práctico dividir al proyecto en pequeños mini proyectos. Estos mini proyectos o
iteraciones incrementan la funcionalidad del sistema para cada mini proyecto se
realizan 5 flujos de trabajo requisitos, análisis, diseño, implementación y prueba.
Por supuesto una iteración 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 iteración
 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 versión del software? ¿Cuales son
los casos de uso esenciales para los usuarios más importantes? ¿Cuál será esbozo
o la arquitectura o del producto?
Se presenta un modelo de caso uso
simplificado que contenga los casos
de uso más crítico en una arquitectura
provisional que muestra los
subsistemas más importantes.
Fase de elaboración.- En esta fase
se identifican la mayoría de los casos
de uso y se especifica en detalle se
diseña la arquitectura del sistema a
través de modelos que representan al sistema entero esto implica que hay una vista
arquitectónica del modelo del caso de uso, del modelo análisis del modelo de
diseño de implementación 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 construcción.- 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 descubrirán y
solucionaran durante la fase de transición.
Fase de transición.-

9
Esta fase cubre el periodo de entrega del producto a la comunidad de usuarios. Se
capacita al personal o usuario finales de la aplicación, se crean los manuales o
ayudas del sistema.
MODELOS RESULTANTES DE UN CICLO DE DESARROLLO.-

Planificación Temporal.
La planificación 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 tamaño real del sistema. Es decir no contamos con
datos históricos que nos permitan hacer estimaciones de la magnitud del problema,
duración del proyecto, esfuerzo y personas requeridas.
La subestimación 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 históricos que me permitan aclarar
la magnitud y el tamaño del proyecto.
Se debe trabajar con procesos evolutivos, que permiten al desarrollador la entrega
del producto a través de incrementos. Siempre y cuando la fecha propuesta,
requisitos poco claros no permitan hacer una estimación real del tamaño del
proyecto.
Se debe informar al cliente que la construcción del sistema esta regido por la
utilización de una metodología en consecuencia el producto será entregado en forma
gradual.
Principios de la planificación temporal.-

10
Durante las primeras etapas de la planificación del proyecto se desarrolla una
planificación 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 planificación temporal
microscópica se defina en una planificación temporal detallada.
Los principios fundamentales de la planificación Temporal son:
1. Compartimentación
2. Interdependencia
3. Validación de Esfuerzo
4. Asignación de Esfuerzo
5. Resultados definidos
6. Responsabilidades definidas
7. Hitos definidos
Compartimentación.- Tiene por finalidad la división del producto y el proceso en
tareas mucho más sencillas
Interdependencia.- Cada una de las tareas, fases, modelos del producto están
interrelacionadas entre si es decir siguen una traza de desarrollo claramente definida
Asignación 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 culminación de cada
actividad.
Validación de esfuerzo.- No se debe sobrecargar al personal, es decir se deben
tener métricas de productividad individual por desarrollador de acuerdo a datos
históricos de proyectos similares.
Responsabilidad Definidas.- Se debe tener un responsable en función 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
función a sus fronteras del sistema es decir debe tener un objetivo general evitando
cualquier ambigüedad en los resultados.
Hitos formales o definidos.- Los hitos formales son reuniones técnicas formales de
revisión de cada uno de los modelos que se han producido, aumentados o
corregidos en una iteración o incremento.
Ejemplo.

11
Realizar una planificación temporal para un sistema de información para la empresa
distribuidora de repuestos agrícola “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 aceptación de los repuestos en el
mercado agroindustrial planea ingresar al rubro de venta de maquinarias agrícolas a
través de créditos para los agroindustriales.

12
 PLAN DE ITERACIONES
Flujos de trabajo Modelos o Inicio Elaboración Construcción Transición
artefactos
I1 E1 E2 E3 C1 C2 T1… In
Modelado de Modelo del
dominio * * *
negocio
Requisitos- Modelos de Caso
de Uso * * * *
Análisis
Diseño Modelo de diseño * * * * *
Implementación Modelo de
* * * * *
implementación
Gestión del Plan de proyecto
*
proyecto
Prueba Modelo de
* * * * *
pruebas
Entorno Marco de
desarrollo

Donde: Inicio
Iteración I1: Plan de proyecto
Elaboración Plan de iteración
Iteración E1: Modelo de negocio - Modelo del dominio.
Iteración E2: Modelo de requisitos, Diseño e implementación de casos de uso esenciales.
Iteración E3: Modelo de requisitos, Diseño e implementación de casos de uso secundario.
Construcción
Iteración C1: Estabilización de los requisitos mas importantes
Iteración C2: Estabilización de los requisitos secundarios

13
Planificación Temporal

14
 Actividad Académica 1

INGENIERIA DE SOFTWARE
1. Defina sistema de información 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 Homeostáticos encuentras en tu Universidad.
6.- Completar el siguiente grafico con la curva de trabajo correspondiente para cada flujos Explique las diferencias entre una
iteración en fase de Inicio, Elaboración, Construcción y transición.

Fases INICIO ELABORACION CONSTRUCCION TRANSICION

Modelo de
negocio
Requisitos
Análisis
Diseño
Implementación
Pruebas
I1 I.. I… In-1 In

15
UML.-(Lenguaje Unificado de modelado).
Antecedentes
En el periodo comprendido entre [1994-1998] se incrementaron varios métodos
orientado a objeto. Muchos usuarios de estos métodos tenían problemas al intentar
encontrar un lenguaje de modelado que cubriera sus necesidades completamente,
alimentando de esta forma la llamada guerra de métodos. En lo que se destacaron el
método de IVAR JACOBSON conocido como Ingeniería de software orientado a
objeto (OOSE), el método de JAMES RUMBAUGH Técnica modelado de objeto
(OMT), el método de Coad-Yourdon Shlaer-Mello. Cada uno de estos era un método
completo. Aunque tenían sus puntos fuertes y debilidades.

De las tres metodologías 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 relación y colaboración. Por
otro lado, la metodología de IVAR JACOBSON es más centrada a usuario, ya que
todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y
aceptando como estándar 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 métodos. A
finales de 1995, Ivar Jacobson y su compa nía Objectory se incorporaron a Rational
en su unificación, aportando el método OOSE.
Para aquel entonces en lenguaje tenia tres metas específicas
Modelar sistemas, desde el concepto hasta los artefactos ejecutables, utilizando
técnicas orientadas a objetos.
Cubrir las cuestiones relacionadas con el tamaño inherente a los sistemas complejos
y críticos.
Crear un lenguaje de modelado utilizable tanto en las personas como por las
maquinas.

Una versión revisada de UML (la versión 1.1 se ofreció a Object Management Group
(OMG) para sus estandarización en julio de 1997 y adoptado por OMG. El 14 de
noviembre de 1997.

16
 Histórica de UML
1 UML

Definición.
El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Lenguaje) es un
lenguaje gráfico 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,
además 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 implementación y
transformarla en código es casi cero lo piensas lo codificas” incluso hay cosas que
se modelan mejor directamente en código. Pero hay unas
cuestiones sobre un sistema software que no se pueden
entender a menos que se construyan modelos, que
trasciendan el lenguaje de programación textual. Por
ejemplo la jerarquía de un modelo de clases puede
inferirse. Pero no capturarse completamente,
La distribución física y posible migraciones de los objetos
en un sistema. Si el desarrollador escribió código y no dejo
documentación escrita sobre los modelos que habría en su
cabeza, esa información se perderá para siempre o, como
muchos, será solo parcialmente reproducible a partir de la implementación, una vez
que el desarrollador se haya marchado.

17
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 programación. Esto significa que es posible establecer
correspondencia entre un modelo UML a un lenguaje de programación como Java,
C++ o visual Basic, incluso tablas en una base de datos relacional. Esta
correspondencia permite la ingeniería directa, la generación de código a partir de un
modelo UML. De lo contrario también se puede construir un modelo de UML a partir
de una implementación (Ingeniería Inversa) .

1.4 UN LENGUAJE PARA DOCUMENTAR.

En la ingeniería de software se producen varios artefactos además de código
ejecutable. Plan de proyecto, análisis diseño, implementación, prototipos, versiones.
BLOQUES DE CONSTRUCCION DE UML.
UML esta compuesto de 3 bloques de construcción: Elementos, Relaciones, y
Diagramas.

Clase
Interfaz
Elementos estructurales Colaboración
Caso de uso
Clase activas, componentes y nodos

Elementos Interacción
Elementos de comportamiento Maquina de estado

Elementos de agrupación Paquete

Elementos de anotación Nota

Dependencia
Relaciones Asociación
Generalización
Realización

18
 Diagramas Estáticos
Diagramas de clase
Diagramas de objeto
Diagramas de componentes
Diagramas de despliegue
Diagramas Diagramas dinámicos
Diagramas de caso de uso
Diagramas de secuencia
Diagramas de actividades
Diagramas de colaboración
Diagramas de estado

2 ELEMENTOS ESTRUCTURALES.
Son las partes estáticas de un modelo, y representan cosas que son conceptuales o
materiales.
2.1 CLASE.-
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es
una instancia de una clase). A través de ella podemos modelar el entorno en estudio
(una Casa, un Auto, una Cuenta Corriente, etc.). En UML, es una descripción de un
conjunto de objeto que comparten los mismos atributos, es representada por un
rectángulo 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 prívate, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la
forma como interactúa el objeto con su entorno (dependiendo de la visibilidad:
prívate, protected o public).

Ejemplo:
Una Cuenta Corriente que posee como característica:
Balance
Puede realizar las operaciones de:
o Depositar

19
 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 número 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 características de una Clase pueden ser de tres tipos, los que
definen el grado de comunicación 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.
 prívate: Indica que el atributo sólo será accesible desde dentro de la clase
(sólo sus métodos lo pueden accesar).
 protected (#,): Indica que el atributo no será accesible desde fuera de la
clase, pero si podrá ser accesado por métodos de la clase además de las
subclases que se deriven (ver herencia).

Operaciones o métodos:
Una operación o un servicio es la implementación de un servicio que puede ser
requerido a cualquier objeto de la clase. Los métodos u operaciones de una clase
son la forma en como ésta interactúa con su entorno, éstos pueden tener las
características:
 public: Indica que el método será visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.
 Prívate: Indica que el método sólo será accesible desde dentro de la clase
(sólo otros métodos de la clase lo pueden accesar).
 Protected: Indica que el método no será accesible desde fuera de la clase,
pero si podrá ser accesado por métodos de la clase además de métodos
de las subclases que se deriven (ver herencia).

20
2.2 INTERFAZ.

Interfaz es una colección de operaciones que sirve para especificar un servicio de

una clase o de un componente

<<Interface>> Se puede dibujar una interfaz como una

SOCIO

Obtener_deudas() clase estereotipada, indicando sus

Obtener cuotas()
operaciones. Esto cuando se necesite
visualizar los detalles del propio servicio

Instancia :: Clase.
Cuando solo sea necesario especificar la presencia de una línea de separación en el
sistema

Ejemplo: 1 Ejemplo: 2 G ru p o C lie n te

C on yug e
C o d _ G ru p o : C h a r(1 0 ) C o d _ C lie n te : c h a r ( 1 0 ) C o d _ U s u a rio :
N o m b re : c h a r(5 0 ) C o d _ G ru p o : c h a r(1 0 ) c h a r(1 0 )
Z o n a : c h a r(3 0 ) M o n t o : in t e g e r C e n t ra l d e R ie s g o R o l_ R e la c io n :
C o d _ E m p le a d o : C h a r ( 1 0 ) E s ta d o : c h a r(1 0 ) c h a r(3 0 )
C o r r e la t iv o : in t e g e r N o m b re s :c h a r ( 5 0 )
A p p :c h a r(1 0 ) 1
1
A p m :c h a r(1 0 )
« M o d u lo » « M o d u lo » C I: C h a r ( 2 0 )
G e re n c ia C a je r o E n c a r g a d o d e A g e n c ia

*
fr m F o rm a r G r u p o
E n c a rg a d o U s u a r io S is t e m a T r a n s
d e a g e n c ia 1

« M o d u lo » C o d _ U s u a r io : c h a r ( 1 0 )
G e r e n c ia C iu d a d : c h a r( 3 0 )
S is t e m a d e E m p le a d o
C o n ta d o r
I n f o r m a c ió n N o m b re s : c h a r(5 0 )
d e C r é d it o s A p p : c h a r(3 0 )
In g r e s o a l C o d _ E m p le a d o : c h a r ( 1 0 )
s is te m a A p m : c h a r(3 0 )
u s u a rio
fr m N u e v o U s u a r io C I : C h a r(2 0 ) 1 C a rg o : c h a r(3 0 )
A sesor
d e l s is t e m a
E C iv il : c h a r( 1 0 ) N iv e l : in te g e r
« M o d u lo » S e x o : c h a r(1 0 ) Id e : c h a r(1 0 )
E n c a r g a d o d e S is t e m a s
F e c h a _ N a c im ie n t o : d a t e * P a s s w o rd : c h a r(1 0 )
n u e v o () D ir e c c ió n : c h a r ( 5 0 ) E s ta d o : C h a r(1 0 )
E n c a rg a d o g ra b a r() D ir e c c io n _ E s p e c if ic a : c h a r ( 5 0 )
d e S is te m a s
fo rm a rg ru p o () T e le f o n o : in t e g e r
« M o d u lo » « M o d u lo »
u s u a r io C a n c e la r ( ) C o d _ R e g io n a l : c h a r (1 0 )
U s u a rio C o n t a b il id a d C o d _ D p to : c h a r(1 0 ) Zona
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 a je r o
C o d _ R e g io n a l : c h a r ( 1 0 )
R u b ro
* C o d _ Z o n a : c h a r(1 0 )
*
1
C o d _ D p to : c h a r(1 0 )
C o d _ R u b r o : C h a r(1 0 )
C o d _ R u b ro : 1 C o d _ C iu d a d : c h a r ( 1 0 )
G u a rd a r()
C h a r(1 0 ) C a n c e la r ( ) C o d _ A g e n c ia : c h a r ( 1 0 )
D e s c r ip c ió n : N o m b re _ Z o n a : c h a r(3 0 )
c h a r(5 0 ) D ire c c io n _ Z o n a : c h a r (3 0 )

2.3 COLABORACION.

21
 Una colaboración 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 colaboración se representa mediante diagramas de clase y la parte de comportamiento se
representa mediante un diagrama de interacción 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 descripción 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 interactúa con
nuestro sistema.
Relación de inclusión <<Include>> <<Usa>>.-
Se usa para evitar describir el mismos flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso
aparte

Ejemplo: << include>> Verificar central

de riesgo
Realizar
Solicitud
<< include>>

Asesor:Empleado Registrar
cliente

Relación de extensión <<Extend>>.-

Una relación de extensión 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. También se puede utilizar una
relación de extensión para modelar un subflujo separado que se ejecuta bajo ciertas condiciones, también 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 Efectivo
Pago
<< extend>>

Tarjeta de
credito

Carlos::Cliente

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

<<Interface>>
System::vgi.dll Observador
Abortar:int
Error:int

ActualizarImagen():boolean

Observador

Realización (Una interfaz que el componente ofrece como servicios a otros componente)
2.6 NODO.

22
Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que, generalmente,
tiene alguna memoria y, a menudo, capacidad de procesamiento

S: Servidor

Velocida=200M
HZ
ventas Memoria=256
mb

Encender ()
Apagar()

Ejemplo:

23
2.7 ELEMENTOS DE COMPORTAMIENTO.

Son las partes dinámicas de los modelos UML. Estos son los verbos de un modelo y
representan comportamiento en el tiempo y el espacio
2.7.1 Interacción.
Conjunto de mensajes intercambiados entre un conjunto de objeto.
En UML Los aspectos estáticos 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 dinámicos 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 dinámicos de un sistema

la mayoría de las veces, esto implica modelar la vida de las instancias de una clase,
un caso de uso, o un sistema completo.

24
 Estado

2.8 ELEMENTOS DE AGRUPACIÓN.

2.8.1 Los Paquetes

Son las partes organizativas de los modelos UML. Al contrario que los
componentes (que existen en tiempo de ejecución), un paquete es puramente
conceptual, solo existe en tiempo de desarrollo. Sirven para organizar los
elementos en grupo.

Nota
Reglas de Frameworks
negocio

2.9 ELEMENTOS DE ANOTACIÓN

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

25
2.10RELACIONES

Una relación es una conexión entre elementos: Entre las más importantes tenemos
Dependencia, Asociación, Generalización y Interacción.
2.10.1 Dependencia.
Una relación de dependencia es una relación que se usa cuando se quiere
indicar que un elemento utiliza a otro, y cualquier cambio en la especificación
del elemento puede afectar a otra que la utiliza, pero no necesariamente a la
inversa.
Representación.-
Ejemplo:

FACTURA DETALLE _ FACTURA EMPLEADO HIJO

Cod_Factura int Producto char(70) Cod_empleado int Nombre_hijo

Fecha datetime Unidad decimal (10,2) Fecha_nacim Apm
Cliente char(50) Cantidad decimal(10,2) App Fecha_nacimiento
Nit integer Precio decimal(10,_2) Apm

2.10.2 Generalización.

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 línea continua terminada en flecha vacía apuntando al
padre.

26
 Cliente

Cod_cliente int
Nombre char(50)
Dirección char(50)

Natural Empresa

Fecha_Nacimiento nit
App char(50) representante_legal

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

27
2.10.3 Asociación.

Las asociaciones se utilizan cuando se quieren representar relaciones

estructurales, especifica que los objetos de un elemento están conectados
con los elementos de otro.
2.10.3.1 Rol.-
Mujer MATRIMONIO
PERSONA

Nombre
App
Apm Rol.-Es lo que representa la clase de un extremo de la
asociación a la clase del otro extremo

Hombre

PERSONA EMPRESA
Trabaja
EMPLEADO JEFE
2.10.3.2 Multiciplidad.-

La multiciplidad señala cuantos objetos pueden conectarse a través de una

instancia de una asociación, describe un rango de valores explícitos de la
asociación.
1..0,1..1,1..*, *..*

28
2.10.3.3 Asociaciones reflexivas.

Diagrama de clases describiendo una asociación reflexiva para la clase

Persona.

2.10.3.4 Agregación.-

La relación de agregación se utiliza para modelar relación todo/parte en la

cual una clase representa una cosa grande (el todo) que consta de elementos
mas pequeños (las partes). Modela relación del tipo “Tiene un”,”Forma parte
de”, “esta compuesto de”
(El objeto base utiliza al incluido para su funcionamiento). Es un tipo de
relación dinámica, en donde el tiempo de vida del objeto incluido es
independiente del que lo incluye.

Ejemplo:

UNIVERSIDAD
* *
ADMINISTRATIVOS

29

ESTUDIANTES
 *

2.10.3.5 Composición

La composición es una forma de agregación, con una fuerte relación de

pertenencia y vidas coincidente de la parte con el todo. En una agregación
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 relación estática, en donde el tiempo de vida del objeto incluido esta
condicionado por el tiempo de vida del que lo incluye.

30
 UNIVERSIDAD
1 * ADMINISTRATIVOS

Ejemplo.

ESTUDIANTES

En donde se destaca que:

 Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).
 Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.
 La composición se destaca por un rombo relleno.
 La agregación se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no

existe este tipo de particularidad la flecha se elimina .

31
 2.10.3.6 Clase asociación.
La asociación puede tener propiedades.

Ejemplo.

PERSONA EMPRESA
* 0.* 1

CONTRATO

2.11 DIAGRAMAS.
Un diagrama es una representación grafica de un conjunto de elementos, se utilizan para ver al sistema de diferentes
perspectivas. Como ningún 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 Clasificación de Diagramas

Se dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica.

Diagramas estáticos 1. Diagramas de clase

o Estructurales 2. Diagramas de objeto
3. Diagramas de componentes
4. Diagramas de despliegue implementación

1. Diagrama de casos de uso

Diagramas dinámicos 2. Diagrama de secuencia
o de Comportamiento 3. Diagrama de actividad
4. Diagrama de colaboración
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 construcción. En el contexto del software, existen cinco vistas complementarias que son las más importantes para visualizar,
especificar, construir y documentar la arquitectura del software. En el UML las vistas existentes son:

32
2.12DIAGRAMAS ESTÁTICOS
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,
Dirección, y Número del Seguro Social. Puede trabajar en
algún proyecto y ganar un salario. Una Compañía tiene un
Nombre, Dirección, Número de Teléfono, y Producto
Primario. Una Compañía contrata y despide Personas. El
contrato de trabajo depende de la persona y de la
compañía. 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. Además una Compañía está compuesta de múltiples Departamentos; cada departamento dentro de una
compañía se identifica de forma única por su Nombre.
Un departamento usualmente tiene un administrador. La mayoría de los administradores manejan un departamento; y algunos
administradores no están asignados a ningún 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 estática de un
diagrama de interacción, en un diagrama de objeto podremos encontrar objetos y enlaces

DIAGRAMA DE CLASE DIAGRAMA DE OBJETO

2.12.3 Diagrama de Componentes

Un diagrama de componentes muestra las organizaciones y dependencias lógicas entre componentes software, sean éstos
componentes de código fuente, binarios o ejecutables. Los elementos de modelado dentro de un diagrama de componentes
serán componentes y paquetes. En cuanto a los componentes, sólo aparecen tipos de componentes, ya que las instancias
específicas de cada tipo se encuentran en el diagrama de despliegue.
Cada componente en el diagrama debe ser documentado con un diagrama de componentes más detallado, un diagrama de
clases, o un diagrama de casos de uso.

33
Un paquete en un diagrama de componentes representa una división física del sistema. Los paquetes se organizan en una
jerarquía 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 compilación).

Normalmente los diagramas de componentes se utilizan para modelar código fuente, versiones ejecutables, bases de datos
físicas, entre otros.

Código fuente: En el modelado de código fuentes se suelen utilizar para representar las dependencias entre los ficheros de
código fuente, o para modelar las diferentes versiones de estos fichero. Para ello se deben identificar el conjunto de archivos
de código fuente de interés y estereotiparlos como archivos file, agruparlos en paquetes, utilizar valores etiquetados para la
información de versiones y modelar las dependencias de compilación.
Código ejecutable: Se utiliza para modelar la distribución de una nueva versión a los usuarios. Para tal propósito 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
mayoría de las veces incluirán interfaces que son exportadas (realizadas) por ciertos componentes e importadas (utilizadas)
por otros.
Bases de datos física: UML permite el modelado de bases de datos físicas así como de los esquemas lógicos de bases de
datos.
Así si tenemos en cuenta las dependencias asociadas al proceso de compilación un componente podría ser:
Código fuente: que depende de otros componentes (no necesariamente código fuente) que deben estar disponibles durante la
compilación del componente.
Código objeto binario: como por ejemplo una librería, que puede depender de algún código objeto con el que se linkea.
Código ejecutable: que puede depender de otros programas ejecutables con los que interaccionan en tiempo de ejecución.

“El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo las dependencias entre los
componentes de software, los componentes de código 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).”

34
2.12.4Diagramas de Implementación /Despliegue
Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de
ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos.
Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de
ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también
modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de
dependencia con el estereotipo 'becomes' (se transforma)

Figura: Modelando la Distribución del Sistema con el Diagrama de Implementación

35
2.13DIAGRAMAS DINÁMICOS
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 estímulo del ambiente. El diagrama de
uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben
comportarse y no como están implementadas las partes que define.
Un caso de uso especifica un requerimiento funcional.
Elementos

Actor Caso de uso

2.13.2 Diagrama de Secuencia

Este diagrama (también llamado diagrama de interacción) muestra las interacciones entre un conjunto de objetos (clases,
actores), ordenadas según 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 sitúan en la parte superior de la pantalla, normalmente a la izquierda se sitúa el que inicia la acción.
De estos objetos sale una línea que indica su vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando
representa que el objeto tiene el foco del sistema, es decir cuando él esta activo.
El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de
la interacción.
En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto
origen solicita (llama a) una operación del objeto destino. El diagrama de secuencia puede ser obtenido de dos partes, desde el
Diagrama Estático de Clases o desde el de Casos de Usos.
Elementos
Los componentes de un diagrama de interacción son:
Línea de vida

Un objeto (o actor) se representa como una línea vertical punteada con un rectángulo de encabezado y con rectángulos a
través de la línea principal que denotan la ejecución de métodos (activación). El rectángulo de encabezado contiene el nombre
del objeto y el de su clase.

Activación
Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por sí mismo o por
medio de delegación a alguno de sus atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.
Mensajes

El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el
objeto que lo ejecuta. Representa la llamada de un método (operación) de un objeto en particular.

También es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

36
El presente diagrama es útil para observar la vida de los objetos en el sistema, identificar llamadas a realizar o posibles errores
del modelo estático, que imposibiliten el flujo de información o de llamadas entre los componentes del sistema.

2.13.3 Diagrama de Colaboración

Este diagrama muestra la interacción 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 información 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 rectángulo, que contiene el nombre y la clase del objeto. Un objeto es una instancia de una
clase que participa como una interacción, 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 asociación en un diagrama de clases. Se representa como una línea continua que une a
dos objetos en este diagrama. Esta acompañada por un número que indica el orden dentro de la interacción 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
Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cercana a un enlace. Los mensajes que se
envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples,
sincrónicos, balking, timeout y asíncronos.
Durante la ejecución de un diagrama de colaboración se crean y destruyen objetos y enlaces.

37
2.13.4 Diagrama de estado
Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en
respuesta a estímulos recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en
UML es cuando un objeto o una interacción satisfacen una condición, desarrolla alguna acción o se encuentra esperando un
evento.
Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un estímulo o evento se dice que ha sufrido
una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una
transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un
cambio de estado y se representan dentro del estado, no de la transición.

38
2.13.5 Diagrama de actividad
Son similares a los diagramas de flujos de otras metodologías OO. En realidad se corresponden con un caso especial de los
diagramas de estado donde los estados son estados de acción (estados con una acción interna y una o más transiciones que
suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo que será un procedimiento) y las
transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. Siempre van
unidos a una clase o a la implementación de un caso de uso o de un método (que tiene el mismo significado que en cualquier
otra metodología 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

39
 CASO DE ESTUDIO
“SISTEMA DE INFORMACIÓN DE FACTURACIÓN PARA EL SERVICIOS DE AGUA POTABLE QUE BRINDA LA
COOPERATIVA DE SERVICIOS PUBLICOS SEMCAP LTDA”

40
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:
1. Identificación de los procesos de negocio
2. Identificación de los usuarios, departamentos o elementos de la organización 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. Información generada o utilizada en cada actividad.
7. Reglas de negocio.

1.1. Identificación de los procesos de negocio.

Un proceso de negocio es un objetivo estratégico de la organización. Con la descomposición 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 organización para luego abordarlo uno a uno. La funcionalidad estará repartida en varios
proceso de negocio.
Facturación

1.2. Identificación de los usuarios, departamentos o elementos de la organización implicados en el proceso de

negocio.
Estos usuarios pueden ser: Sistemas de información, Interfaces de Dispositivos hardware, Personas que realizan tareas
operacionales en el sistema.

1. Presidente Administrativo. 4. Cajero.

2. Asistente Administrativo. 5. Contador.
3. Encargado de Sistemas.

Donde:
Usuarios del sistema se considera como usuario del sistema a toda persona que va a tener una relación ya sea
como
Empleado, socio con el sistema de facturación de la cooperativa.
Presidente administrativo. Es la persona responsable de la administración del la cooperativa, por ser el presidente
del consejo de administración.
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
administración 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. Presidente Administrativo.
 Realizar Apertura del sistema
 Abrir Caja
 Aprobar Revertir Solicitudes en gerencia administrativa.
 Reposición de dinero.
 Cierre definitivo de caja
 Cierre del sistema.

41
5. Asistente Administrativo.
 Registrar Socio
 Registrar Solicitudes de aportaciones
 Registrar lecturacion
6. Encargado de Sistemas.
 Realizar backup del sistema
 Edición de parámetros
 Tipo de cambio
 Tipo de transacción
7. Cajero
 Realizar recuperaciones
 Facturas de consumo.
 Reconexiones
 Trasferencias de aportaciones
 Cierre preliminar de caja
 Reportes:
 Transacciones
 Planilla caja consolidada
8. Contador
 Listado de ingresos mensuales
 Cuentas por pagar

42
 1.4. Diagrama de actividades que represente el proceso de negocio.

Diagrama de actividades sistema de facturación

1.5. Listado de las actividades.
Realizar apertura del sistema: Función Iniciada por el Presidente administrativo tiene como objetivos registrar fluctuaciones
en el tipo de cambio en moneda extranjera (dólares) y bolivianos.
Abrir caja: Función 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 Función Iniciada por el Presidente administrativo, tiene como
objetivo la aprobación de la solicitud en segunda instancia por el Presidente administrativo. La reversión se realiza cuando
solicitudes de aportaciones han sido aprobado por el asistente administrativo. La aportación regresa al asistente administrativo
como primera instancia de aprobación.
Reposiciones de dinero del Administrativo: Función 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 parámetros
necesarios.
Cierre definitivo de caja: Función Iniciada por el Presidente administrativo tiene como objetivo hacer el cierre definitivo la una
caja cerradas preliminarmente por el cajero, y hacer la reposición del dinero a bóveda.
Realiza el cierre del sistema. Función 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 reposición a bóveda. Se actualizan consolidan todas las
transacciones.
Registrar Socio: Función Iniciada por el Asistente administrativo, tiene como objetivo dar de alta a un Socio natural o juridicos
de la Cooperativa.
Realizar solicitudes: Función Iniciada por el Asistente administrativo, tiene como objetivo registra una solicitud de nuevo
socio y su aprobación en primera instancia.
Registrar Lecturacion. Función 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 facturación.
Realizar recuperaciones Función Iniciada por el cajero, tiene como objetivo registrar los ingresos como ser por conceptos de
facturación, reconexiones, transferencias de aportaciones.
Cierre preliminar de caja: Función 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. Función Iniciada por el cajero, tiene como objetivo la impresión de reportes
como:
Detalle de transacciones
Planilla de caja consolidada.

43
Realizar backup. Función Iniciada por el encargado de sistema realiza tareas de backup de los diferentes módulos y base de
datos.
Edición de parámetros de cálculos. Función Iniciada por el encargado de sistema realiza tareas de edición de los diferentes
parámetros de calculo como ser tipo de cambio, tipos de aportación.

44
1.6. Información generada o utilizada en cada actividad.
En este punto se debe registrar toda información 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.
APORTACIÓN = {...Estado= (2, 3)…} donde: 2=Registrada y aprobada por el asistente adm.
3=Aprobada por el Presidente administrativo
 Reposición de dinero.
TRANSACCION= {Cod_Transaccion, Origen= (Bobeda, Caja), destino= (Caja, Bobeda), Tipo_Transaccion =(32,33.),
Fecha_Transaccion, Monto, Cod_Caja}
 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, Dirección}
P_NATURAL= {Cod_Socio, Doc_Identidad, App, Apm, Fecha_Nacimiento}
P_JURIDICA= {Cod_socio, nit, Razon_Social, Rpte_legal,

 Registrar Solicitudes de aportaciones

APORTACIÓN = {Cod_Aportacion, Fecha_Incripcion, Plazo_Meses, Estado, Cod_tipo_Aportacion,
CutaInicial_Aportacion, CuotaInicial_Accesorio, Zona, Barrio, Calle, Lote}
 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, Año_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,
Fecha_Transaccion, Monto, Cod_Caja}
 Reconexiones
RECONEXIONES= {Cod_reconexion, Cod_aportacion, Monto, Estado, Mes_pago, Año_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, Año_Pago, Fecha_pago}

1.7. Reglas de negocio.

Las reglas de negocio son una serie de restricciones de la organización a la hora de realizar una actividad.
 El valor de compra de dólar debe ser menor al de la venta.
 No se acepta socio menores a 18 años.
 Si no existe lecturacion o consumo de agua de factura como consumo mínimo.

45
2. MODELO DE REQUISITOS.
En el modelos de requisitos identificamos las tareas que ha a implementar el sistema de información, haciendo una descripción
de estos requisitos y se crea un diseño conceptual que represente fielmente el proceso de negocio. Para tal objetivo se realizan
tres actividades:
1. Identificación de los casos de Uso.
2. Descripción de los casos de uso.
3. Crear el modelo conceptual.
2.1. Identificación 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 acción 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. Descripción de los casos de uso.

Para la descripción 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 : Nombre del caso de uso.

Objetivo : Descripción informal de los objetivos del caso de uso.
Actores : Actores que intervienen en el caso de uso, principales y secundarios.
Precondiciones : Condiciones que debe cumplirse para que pueda realizarse el caso de uso.
Pasos : 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 : Variaciones en la secuencia de pasos
Extensiones : Puntos de extensión del caso de uso

46
47
2.3. Crear el modelo conceptual.

Modelo conceptual del sistema de facturación en fase de requisitos

48
3. MODELO DE ANALISIS.
En este modelo se implementaran los artefactos que serán un punto de partida para el modelo de diseño. Para
realizar dicho modelo se deben seguir lo siguientes pasos:
1. Identificación de los actores definitivos del sistema.
2. Identificación de los casos de uso y sus extensiones.
3. Se crea un modelo de casos de uso (Actualizando el modelo de CDU. del Modelo de requisitos con sus relaciones de
Usa y Extend).
4. Se crea un diagrama de secuencia y de colaboración para cada caso de USO.
3.1. Identificación de los actores del sistema.

Presidente administrativo. Es la persona responsable de la administración del la cooperativa, por ser el presidente
del consejo de administración.
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
administración del sistema computacional.
3.2. Identificación de los casos de uso y sus extensiones.
1. Realizar apertura del sistema: Función Iniciada por el Presidente administrativo tiene como objetivos registrar
fluctuaciones en el tipo de cambio en moneda extranjera (dólares) y bolivianos.
2. Abrir caja: Función Iniciada por el Presidente administrativo tiene como objetivo habilitar una
3. Aprobar revertir solicitudes en Presidente administrativo Función Iniciada por el Presidente administrativo, tiene como
objetivo la aprobación de la solicitud en segunda instancia por el Presidente administrativo. La reversión se realiza
cuando las aportaciones no cumplen con los requisitos (Radio o cobertura, Socios menores de edad, socios de otras
Cooperativas). La solicitud de aportación regresa al Asistente administrativo como primera instancia de aprobación.
4. Reposiciones de dinero del Administrativo: Función 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 parámetros
necesarios.
5. Cierre definitivo de caja: Función Iniciada por el Presidente administrativo tiene como objetivo hacer el cierre definitivo la
una caja cerradas preliminarmente por el cajero, y hacer la reposición del dinero a bóveda.
6. Realiza el cierre del sistema. Función 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 reposición a bóveda. Se actualizan consolidan todas las
transacciones.
7. Registrar Socio: Función Iniciada por el Asistente administrativo, tiene como objetivo dar de alta a un Socio natural o
juridicos de la Cooperativa.
8. Realizar solicitudes: Función Iniciada por el Asistente administrativo, tiene como objetivo registra una solicitud de nuevo
socio y su aprobación en primera instancia.
9. Para la facturación de servicios de agua potable se consideran los siguientes aspectos: Sus diferentes tipos de socio,
cada socio puede tener una o varias aportación con un costo de 100 Sus. Por aportación y 45 de accesorio: Aporte inicial
de 20 Sus por aportación. y 10 dólares de cuota inicial por accesorio. El saldo se Programada en un plazo 48 cuotas
mensuales. Entre los tipos de aportaciones tenemos:

49
10. Registrar Lecturacion. Función 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 facturación.
11. Realizar recuperaciones Función Iniciada por el cajero, tiene como objetivo registrar los ingresos como ser por
conceptos de facturación, reconexiones, transferencias de aportaciones.
12. Cierre preliminar de caja: Función 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. Función Iniciada por el cajero, tiene como objetivo la impresión de
reportes como:
Detalle de transacciones, Planilla de caja consolidada.
14. Realizar backup. Función Iniciada por el encargado de sistema realiza tareas de backup de los diferentes módulos y base
de datos.
15. Edición de parámetros de cálculos. Función Iniciada por el encargado de sistema realiza tareas de edición de los
diferentes parámetros de calculo como ser tipo de cambio, tipos de aportación.
NOTAS: Los socios, pueden ser persona natural o jurídica. De las personas naturales se registran sus datos personales,
numero de identidad, dirección. De las personas juritas el nombre de la empresa, RUC. Y se ambas se consideran como una
sola unidad en los aspectos jurídicos y de control del sistema.

Solicitud de socio. En una solicitud de nuevo socio están los siguientes datos: fecha de registro, zona ,barrio, calle y numero
de lote. Tipo o clase de aportación, cuota inicial del certificado de aportación, y cuota inicial de accesorios, ambos con un
mismo plazo.
Las cuotas son calculadas con la siguiente formula de anualidad:
(C * ((1 + i) ^ t) * i)
Anualidad =
16. ((1 + i) ^ t) - 1)

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

i = interés = ((interés 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
aportación, cuota accesorio, y 1 Bs. De cuota mortuoria mensual.
Caja las cajas son abiertas por el Presidente administrativo al empezar el día 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 bóveda.
Una vez cerrada la caja no puede surgir ninguna transacción más en el sistema.

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

50
 Modelo de caso de uso en fase de Analisis.

3.4. Se crea un diagrama de secuencia y de colaboración para cada caso de USO.

Diagrama de colaboración del caso de uso

Registrar Aportación

51