Fundamentos de Sistemas, Modelado de Software y UML

1. Concepto de Sistema

Un sistema es un conjunto de partes relacionadas entre sí que contribuyen a un objetivo en común.

Ejemplos:

• Una persona.
• El equipo de aire acondicionado, etc.

2. Modelo

Un modelo es un artefacto construido por un diseñador que tiene por objetivo explicar relaciones sistemáticas complejas.

Los modelos permiten visualizar el sistema antes de que esté construido. Se pueden representar mediante texto, gráficos, diagramas o símbolos que tienen un significado específico.

3. Subsistema

Son las partes o componentes que conforman un sistema. A su vez, los subsistemas pueden componer un sistema de rango mayor.

4. Macrosistema

Un macrosistema es un sistema de mayor rango que está compuesto por varios subsistemas. En algunas conceptualizaciones, los subsistemas más básicos o iniciales que forman parte de un sistema mayor podrían denominarse ‘microsistemas’, mientras que el sistema que los engloba es el macrosistema.

5. Tipos de Sistemas de Información

• Sistema de Información Transaccional (OLTP)

  • Orientados a las tareas operativas repetitivas de las empresas.
  • Acción del usuario: Transacción.
  • Ejemplos:
    • Sistemas contables, financieros, de recursos humanos, de planillas, etc.
  • Conjunto de instrucciones que se ejecutan en bloque. Si falla alguna de las operaciones, se revierten todas las demás (atomicidad).
  • Estos sistemas están asociados a bases de datos relacionales altamente normalizadas.

• Sistema de Información Analítico (OLAP)

  • Son sistemas de información orientados al estudio gerencial de los datos almacenados en bases de datos de un sistema OLTP.

• Diferencias entre OLTP y OLAP

  OLTP (Procesamiento de Transacciones en Línea)	OLAP (Procesamiento Analítico en Línea)
  Orientado a trabajos operativos. Múltiples usuarios en línea (concurrencia alta). Bases de datos relacionales. Actualización por transacción (lecturas y escrituras frecuentes). Altamente normalizadas.	Orientado al nivel gerencial y toma de decisiones. Menor número de usuarios (principalmente gerentes y analistas). Bases de datos multidimensionales (o Data Warehouses). Actualización por lotes (bloques); consultas complejas y lecturas intensivas. Desnormalizadas o esquemas específicos (estrella, copo de nieve).

6. Elementos de un Sistema

• Entradas

  Son la materia prima o los datos que inician un proceso dentro del sistema. Pueden ser:

  • Aleatorias

    Se generan al azar, es decir, no siguen un algoritmo de generación predefinido.

    Ejemplos:

    • Una venta.
    • La inscripción de un alumno.

  • Secuenciales

    Las salidas de un sistema son utilizadas como entrada para otro sistema.

    Ejemplos:

    • Las ventas (salida de un sistema de ventas) se convierten en entrada para el sistema contable.
    • Búsqueda de cliente (salida de un sistema de CRM) utilizada por un servicio web.
    • Datos del personal (salida de RRHH) utilizados por el sistema de ventas para asignar comisiones.

  • Retroactivas (Retroalimentación)

    Las salidas del sistema se reintroducen como entradas en el mismo sistema para su ajuste o control.

    Ejemplos:

    • El historial crediticio (salida de evaluaciones previas) se usa para futuras evaluaciones crediticias.

• Proceso

  • Proceso de Caja Negra

    Solo interesa conocer los parámetros que recibe y los resultados que arroja, sin necesidad de entender su funcionamiento interno.

    Alto nivel de abstracción para el usuario.

    Ejemplos:

    • Un componente de software.
    • Una clase (desde la perspectiva del usuario de la clase).
    • Un equipo de música.
    • Un televisor.

  • Proceso de Caja Blanca

    Se realiza un seguimiento detallado de cada una de las actividades internas del proceso.

    Ejemplos:

    • El diseño e implementación detallado de una clase de software.
    • Desarmar un dispositivo y analizar sus circuitos internos.
    • Análisis del procesamiento interno de un algoritmo.

• Salidas

  • Sistema Rico en Proceso

    Realiza un volumen considerable de procesamiento interno, no necesariamente generando una gran cantidad de información de salida.

  • Sistema Rico en Información

    Genera o maneja abundantes datos, a menudo almacenados en bases de datos, como resultado de sus procesos.

7. Fenómenos de un Sistema

• Entropía

  Es el desgaste o desorden natural que sufre todo sistema, ya sea por su uso, el paso del tiempo, condiciones ambientales o por los cambios introducidos en su modelo.

• Neguentropía

  Son los mecanismos propios del sistema que contrarrestan los efectos de la entropía, manteniendo o aumentando su organización y orden.

  Ejemplos:

  • Hardware:
    • Mantenimiento preventivo.
  • Software:
    • Seguridad en la base de datos, aplicación y sistema operativo.
    • Funciones de copia de seguridad (backup) y restauración.
    • Políticas, procesos y funciones claramente definidas.

• Homeostasis

  Es la capacidad de un sistema para mantener su estabilidad interna y equilibrio dinámico a pesar de los cambios externos. Cuando los efectos de la entropía amenazan con superar la neguentropía, el sistema puede necesitar importar energía o información del exterior para mantener su estabilidad.

  Ejemplos:

  • En un ser vivo: consumir alimentos (energía) o antibióticos (para combatir una infección).
  • En un sistema informático: recuperar copias de seguridad tras un fallo.
  • Aplicar técnicas avanzadas para eliminar un virus persistente.

• Sinergia

  Plantea el principio de que “el todo es mayor que la suma de sus partes”. La interacción cooperativa entre los componentes del sistema produce un resultado conjunto superior al que se obtendría con los componentes actuando de forma aislada.

  Ejemplos:

  • El cuerpo humano.
  • Un motor de vehículo.
  • Un equipo de trabajo motivado y bien coordinado.

8. Proceso Unificado de Desarrollo de Software (PU)

Definición

Es un conjunto de actividades necesarias para transformar los requerimientos del cliente en un producto de software.

9. Características del Proceso Unificado

• Dirigido por Casos de Uso

  Los casos de uso son el hilo conductor del proceso de ingeniería. Se identifican, especifican, verifican, analizan, diseñan, implementan y prueban.

  Definición de Caso de Uso

  Un caso de uso describe una secuencia de acciones que realiza el sistema para producir un resultado observable de valor para un actor (usuario o sistema externo).

• Centrado en la Arquitectura

  Los casos de uso representan la parte funcional del sistema, mientras que la arquitectura define la forma y estructura del producto.

  Arquitectura del Software

  • Distribución de los componentes del software (ej. orientado a objetos, cliente-servidor, por capas, orientada a servicios).
  • Diseño de las interfaces de usuario (formularios).
  • Patrones de diseño y programación del software.
  • Uso de componentes y frameworks.

• Iterativo e Incremental

  El PU es una metodología evolutiva que desarrolla el producto a través de iteraciones. Cada iteración produce un incremento funcional del producto.

  Iteración: Es un miniproyecto que aplica un ciclo de vida de ingeniería completo (requisitos, análisis, diseño, implementación, prueba) con objetivos definidos a corto plazo.

  Una iteración sirve para desarrollar una nueva funcionalidad del software o para refinar artefactos ya existentes.

• Gestión de Riesgos

  Se gestionan los riesgos a través de la realización de cada caso de uso, implementando una estrategia proactiva en la evaluación y mitigación de riesgos a lo largo del ciclo de vida.

10. Fases del Proceso Unificado

• Fase de Inicio

  • Se define el alcance del proyecto y se realiza un estudio de viabilidad (dominio de la información).
  • Se realiza la planificación inicial del proyecto.

  Los artefactos principales visibles en esta fase son el plan de proyecto y el modelo de negocio (caso de negocio).

• Fase de Elaboración

  • Se identifican y detallan la mayoría de los requisitos.
  • Se define y valida la arquitectura base del sistema.
  • Se implementan los casos de uso y artefactos más críticos del producto, mitigando los riesgos principales.

• Fase de Construcción

  El producto se desarrolla de forma incremental hasta convertirse en una versión operativa completa, lista para ser probada por la comunidad de usuarios. Se completan todas las funcionalidades.

• Fase de Transición

  • Cubre el despliegue del producto desde el entorno de desarrollo al entorno de producción y su entrega a la comunidad de usuarios.
  • Se corrigen los errores encontrados durante las pruebas beta y de aceptación por parte de los usuarios finales.
  • Se capacita a los usuarios y se elaboran los manuales de usuario y la documentación final.

11. Lenguaje Unificado de Modelado (UML)

Es un lenguaje gráfico estándar que ha sido creado para visualizar, construir, especificar y documentar los artefactos de un sistema de software.

• Visualizar

  Permite representar gráficamente el sistema a través de modelos antes de su construcción, facilitando la comunicación y comprensión entre los interesados.

• Construir

  Los modelos UML pueden guiar la construcción del código (ingeniería directa) y, en algunos casos, generarse a partir del código existente (ingeniería inversa), facilitando la coherencia entre diseño e implementación.

• Especificar

  Al ser un lenguaje formal para artefactos de ingeniería, ayuda a crear modelos precisos, completos y sin ambigüedades, detallando las características y el comportamiento del sistema.

• Documentar

  Todos los modelos UML construidos forman parte esencial de la documentación del sistema, cubriendo decisiones arquitectónicas, diseño, requisitos y otros aspectos del proyecto.

12. Bloques de Construcción de UML

• Elementos

  • Estructurales

    Son los nombres o sustantivos de los modelos UML. Representan las partes estáticas del modelo.

    • Clase
    • Interfaz
    • Colaboración
    • Caso de uso
    • Componente
    • Nodo
    • Actor

  • De Comportamiento

    Son los verbos de los modelos UML. Representan las partes dinámicas del modelo.

    • Interacción (Mensajes)
    • Máquinas de estado (Estados, Transiciones)

  • De Agrupamiento

    Son los mecanismos para organizar los elementos en un modelo.

    • Paquetes

  • De Anotación

    Son mecanismos para añadir comentarios o explicaciones a los modelos.

    • Nota

• Relaciones

  Conectan los elementos entre sí.

  • Asociación
  • Dependencia
  • Agregación
  • Composición
  • Clase de Asociación
  • Asociación Reflexiva
  • Generalización (Herencia)
  • Realización (Especialización de interfaz)

• Diagramas

  Son vistas gráficas de conjuntos de elementos. Se dividen generalmente en estructurales y de comportamiento.

  • Diagramas Estructurales (o Estáticos)

    • Diagrama de Clases
    • Diagrama de Objetos
    • Diagrama de Componentes
    • Diagrama de Despliegue (Implementación)
    • Diagrama de Paquetes
    • Diagrama de Estructura Compuesta

  • Diagramas de Comportamiento (o Dinámicos)

    • Diagrama de Casos de Uso
    • Diagrama de Secuencia
    • Diagrama de Comunicación (Colaboración)
    • Diagrama de Estados (Máquina de Estados)
    • Diagrama de Actividades
    • Diagrama de Tiempos
    • Diagrama Global de Interacciones

13. La Clase

Una clase es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y semántica. Es una plantilla para crear objetos.

14. Relaciones en Diagramas de Casos de Uso

• Relación de Extensión (<<extend>>)

  Se presenta una relación de extensión (extend) cuando:

  • Un caso de uso base puede ser extendido por otro caso de uso (extensor) que añade comportamiento opcional o excepcional bajo ciertas condiciones (punto de extensión).
  • Es útil cuando se desea agregar funcionalidad a un caso de uso ya existente sin modificarlo directamente, o para manejar escenarios alternativos o infrecuentes.

  Ejemplo:

  

• Relación de Inclusión (<<include>>)

  • Se utiliza para factorizar un comportamiento común que es utilizado (incluido) obligatoriamente por dos o más casos de uso base. El caso de uso incluido no es opcional.
  • Ayuda a simplificar casos de uso complejos descomponiéndolos en partes más pequeñas y reutilizables, evitando la duplicación de descripciones de funcionalidad.

  Ejemplo: