ANTOLOGÍA

ANÁLISIS Y MODELADO DE SISTEMAS DE

INFORMACIÓN

M. en A.T.I Alex Ramírez Galindo

Agosto 2022
 ÍNDICE

1. El modelo del proceso de software .......................................................................................................... 1

1.1. Conceptualización de tecnologías orientadas a objetos ................................................................... 1
1.2. Metodologías emergentes de desarrollo de software. ....................................................................... 5
1.3. Métodos de desarrollo de software orientado a objetos ...................................................................16
1.4. El proceso de desarrollo unificado – RUP. ........................................................................................18
1.5. Lenguaje unificado de modelado (ULM) ............................................................................................25
2. Proceso de análisis para el desarrollo de sistemas de información ................................................28
2.1 Ingeniería de requerimientos ...............................................................................................................28
2.2 Modelo de casos de uso ......................................................................................................................29
2.3 Modelo del negocio. .............................................................................................................................34
2.4 Modelo del dominio. .............................................................................................................................36
3. Diseño de sistemas de información ........................................................................................................40
3.1 Modelo de datos ...................................................................................................................................40
3.2 Modelo de clases ..................................................................................................................................44
3.3 Diagrama de secuencia .......................................................................................................................48
3.4 Modelo de interfaces ............................................................................................................................49
4. Modelo de implementación de sistemas de información....................................................................51
4.1 Modelo de componentes ......................................................................................................................51
4.2 Modelo de despliegue ..........................................................................................................................55
4.3 Planeación del desarrollo de sistemas de información. ....................................................................59
Referencias bibliográficas ................................................................................................................................63
 Introducción

Las organizaciones a nivel mundial cada día incorporan más sistemas de información
para controlar y hacer más eficientes sus procesos productivos y de negocio, lo que
convierte a los sistemas de información en una parte estratégica dentro de las mismas,
por lo que es importante comprender cada una de las etapas que forman el desarrollo
eficaz y eficiente de un sistema de información.

Las principales aportaciones que esta asignatura brinda al perfil profesional son:

1. Aplica conocimientos científicos y tecnológicos en el área informática para la solución

de problemas con un enfoque multidisciplinario.
2. Formula, desarrolla y gestiona el desarrollo de proyectos de software para
incrementar la competitividad en las organizaciones, considerando las normas de calidad
vigentes.
3. Aplica herramientas computacionales actuales y emergentes para optimizar los
procesos en las organizaciones.
4. Diseña e implementa Bases de Datos para el almacenamiento, recuperación,
distribución, visualización y manejo de la información en las organizaciones.
5. Realiza consultorías relacionadas con la función informática para la mejora continua
de la organización.
6. Se desempeña profesionalmente con ética, respetando el marco legal, la pluralidad
y la conservación del medio ambiente.
7. Participa y dirige grupos de trabajo interdisciplinarios, para el desarrollo de proyectos
que requieran soluciones innovadoras basadas en tecnologías y sistemas de
información.

Su importancia radica en la prioridad de hacer un buen análisis y diseño del proyecto,

para facilitar las siguientes fases en la construcción e implementación, a fin de evitar en
lo posible la ingeniería inversa, dando la mayor flexibilidad y efectividad al sistema.
 1. El modelo del proceso de software

1.1. Conceptualización de tecnologías orientadas a objetos

1
2
3
4
1.2. Metodologías emergentes de desarrollo de software.

La metodología hace referencia al conjunto de procedimientos racionales utilizados para

alcanzar un objetivo que requiera habilidades y conocimientos específicos. La
metodología es una de las etapas específicas de un trabajo o proyecto que parte de una
posición teórica y conlleva a una selección de técnicas concretas o métodos acerca del
procedimiento para el cumplimiento de los objetivos. Es el conjunto de métodos que se
utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina
los pasos a seguir y cómo realizarlos para finalizar una tarea.

Metodología Tradicional

Desarrollar un buen software depende de un gran número de actividades y etapas,

donde el impacto de elegir la metodología para un equipo en un determinado proyecto
es trascendental para el éxito del producto. Las metodologías tradicionales son
denominadas, a veces, de forma despectiva, como metodologías pesadas. Centran su
atención en llevar una documentación exhaustiva de todo el proyecto, la planificación y
control del mismo, en especificaciones precisas de requisitos y modelado y en cumplir
con un plan de trabajo, definido todo esto, en la fase inicial del desarrollo del proyecto.
Estas metodologías tradicionales imponen una disciplina rigurosa de trabajo sobre el
proceso de desarrollo del software, con el fin de conseguir un software más eficiente.
Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez
que está todo detallado, comienza el ciclo de desarrollo del producto software. Se
centran especialmente en el control del proceso, mediante una rigurosa definición de
roles, actividades, artefactos, herramientas y notaciones para el modelado
y documentación detallada. Además, las metodologías tradicionales no se adaptan
adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja
en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.
Otra de las características importantes dentro de este enfoque, son los altos costes al
implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es volátil.

5
Metodologías Agiles

Este enfoque nace como respuesta a los problemas que puedan ocasionar las
metodologías tradicionales y se basa en dos aspectos fundamentales, retrasar las
decisiones y la planificación adaptativa. Basan su fundamento en la adaptabilidad de los
procesos de desarrollo. Un modelo de desarrollo ágil, generalmente es un proceso
Incremental (entregas frecuentes con ciclos rápidos), también Cooperativo (clientes y
desarrolladores trabajan constantemente con una comunicación muy fina y constante),
Sencillo (el método es fácil de aprender y modificar para el equipo) y finalmente
Adaptativo (capaz de permitir cambios de último momento). Las metodologías
ágiles proporcionan una serie de pautas y principios junto a técnicas pragmáticas que
hacen que la entrega del proyecto sea menos complicada y más satisfactoria tanto para
los clientes como para los equipos de trabajo, evitando de esta manera los caminos
burocráticos de las metodologías tradicionales, generando poca documentación y no
haciendo uso de métodos formales. Estas metodologías ponen de relevancia que la
capacidad de respuesta a un cambio es más importante que el seguimiento estricto de
un plan.

Algunas metodologías emergentes son:

6
7
8
9
10
11
12
13
14
15
1.3. Métodos de desarrollo de software orientado a objetos

La popularidad de las tecnologías orientadas a objetos ha generado varios métodos de

AOO desde finales de los 80 y durante los 90. Cada uno de ellos introduce un proceso
para el análisis y diseño de un producto o sistema, un conjunto de modelos que
evoluciona fuera del proceso y una notación que posibilita al ingeniero del software crear
cada modelo de una manera consistente. Entre los más ampliamente utilizados se
encuentran:

 El método de Booch.
 El método de Rumbaugh.
 El método Jacobson
 El método de Coad y Yourdon.
 El método de Wirfs-Brock.

Estos métodos se basan en ciertos modelos.

Según Coad y Yourdon, el análisis orientado a objetos está basado en un modelo de

cinco capas:

1. Capa clase/objeto.
2. Capa de estructura.
3. Capa de atributos.
4. Capa de servicios
5. Capa de tema.

16
Podemos visualizar el proceso completo de análisis y diseño como formando el desarrollo
y ensamble de estas cinco capas en un paquete de diseño laminado. La figura ilustra
cómo se entrelazan estas cinco capas.

1. Capa Clase/Objeto. Esta capa indica la clase y objetos.

2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos,
tales como las relaciones uno a muchos y la herencia. Se identifican dos
estructuras completamente distintas:

o Estructuras de clasificación
o Estructuras de composición

3. Capa de Atributos. Esta capa detalla los atributos de las clases. Se especifican
las relaciones de modalidad y multiplicidad.

4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto
(servicios y métodos).

5. Capa de Tema. Esta capa divide el diseño en unidades de implementación o

asignaciones de equipos. Son de tamaño tratable en cuanto contendrán solo entre
aproximadamente 5 y 9 objetos.

Hay 5 tipos generales de objetos que pueden descubrirse durante el análisis. Los objetos
a veces representan cosas tangibles como vehículos, dispositivos y libros. Algunas veces
los objetos representan papeles actuados por personas u organizaciones. Los papeles
incluyen objetos como cliente, propietario o departamento. Los objetos también pueden
ser derivados de incidentes o eventos, tales como vuelo, accidente o reunión. Los
incidentes suceden típicamente en un momento específico. Otros objetos pueden indicar
interacciones tales como una venta o un matrimonio. Las interacciones tienen una
cualidad de transacción o contrato.

Cuando una clase aparece sin objetos, puede ser solamente una clase base, debido a
que la única razón para tal clase “sin objetos” es que sea un medio para agrupar atributos
y servicios que serán heredados por varias otras clases.

17
Proceso del análisis orientado a objetos

El proceso comienza con la distinción de los objetos es decir cómo se va a usar

el sistema, cómo se desenvuelve con otros procesos y programas y, si coordina o
controla otras aplicaciones. De allí comienza el modelado de software usando diferentes
técnicas:

 Caso de uso
 Modelado de clases
 Definición de estructuras jerárquicas
 Definición de temas y subsistemas

También se hace el modelado de clase-responsabilidad-colaborador donde las clases se

definen con su documentación atributos y operaciones y las colaboraciones entre ellas.
Luego se hace el modelo objeto relación para relacionar las clases entre ellas. Posterior
a esto se hace el modelo objeto comportamiento donde se representan los
comportamientos individuales y globales

1.4. El proceso de desarrollo unificado – RUP.

El Proceso Unificado es un proceso de desarrollo de software: “conjunto de actividades

necesarias para transformar los requisitos del usuario en un sistema software”.

RUP es un marco genérico que puede especializarse para una variedad de tipos de
sistemas, diferentes áreas de aplicación, tipos de organizaciones, niveles de aptitud y
diferentes tamaños de proyectos.

RUP está basado en componentes. El software está formado por componentes

interconectados a través de interfaces.

RUP está dirigido por casos de uso, centrado en la arquitectura, y es iterativo e

incremental.

18
RUP es el resultado de varios años de desarrollo y uso práctico en el que se han unificado
técnicas de desarrollo a través del UML, y trabajo de muchas metodologías utilizadas por
los clientes. La versión que se ha estandarizado vió la luz en 1998 y se conoció en sus
inicios como Proceso Unificado de Rational 5.0; de ahí las siglas con las que se identifica
a este proceso de desarrollo.

Características esenciales de RUP

Proceso dirigido por los Casos de Uso: El proceso utiliza casos de uso para manejar el
proceso de desarrollo desde la Incepción hasta el Despliegue.

Proceso Iterativo e Incremental: El proceso reconoce que es práctico dividir grandes

proyectos en proyectos más pequeños o mini-proyectos. Cada mini-proyecto comprende
una iteración que resulta en un incremento. Una iteración puede abarcar la totalidad de
los flujos del proceso. Las iteraciones son planificadas con base a los casos de uso.

Proceso Centrado en la Arquitectura: El proceso busca entender los aspectos estáticos y

dinámicos más significativos en términos de arquitectura de software. La arquitectura se
define en función de las necesidades de los usuarios y se determina a partir de los Casos
de Uso base del negocio.

Proceso Dirigido por los Casos de Uso

Proceso Iterativo e Incremental

El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran

a los usuarios y clientes

En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a

menor escala

Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones

precedentes.

Las actividades se encadenan en una mini cascada con un alcance limitado por los
objetivos de la iteración

19
Cada iteración comprende:

 Planificar la iteración (estudio de riesgos)

 Análisis de los Casos de Uso y escenarios
 Diseño de opciones arquitectónicas
 Codificación y pruebas. La integración del nuevo código con el existente de
iteraciones anteriores se hace gradualmente durante la construcción

Proceso Centrado en la Arquitectura

Arquitectura de un sistema es la organización o estructura de sus partes más relevantes.

Una arquitectura ejecutable es una implementación parcial del sistema, construida para
demostrar algunas funciones y propiedades.

RUP establece refinamientos sucesivos de una arquitectura ejecutable construida como

un prototipo evolutivo.

Fases del Ciclo de Vida

El ciclo de vida consiste en una serie de ciclos, cada una de las cuales produce una nueva
versión del producto.

Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un
número de iteraciones.

Las fases son:

 Fase de Iniciación o Estudio de oportunidad

 Fase de Elaboración
 Fase de Desarrollo o Construcción
 Fase de Transición

Fase de iniciación

Durante la fase inicial se concibe la idea central del producto, se arma el documento de
visión. En esta fase, se revisa y confirma nuestro entendimiento sobre los objetivos
centrales del negocio. Queremos entender los argumentos comerciales en favor de

20
porqué el proyecto debe intentarse. La fase de incepción establece la viabilidad del
producto y delimita el alcance del proyecto.

Define el ámbito y objetivos del proyecto

Se define la funcionalidad y capacidades del producto

Durante la fase de inicio se desarrolla una descripción del producto final y se presenta el
análisis del negocio. Esta fase responde las siguientes preguntas:

¿Cuáles son las principales funciones del sistema para los usuarios más importantes?

¿Cómo podría ser la mejor arquitectura del sistema?

¿Cuál es el plan del proyecto y cuánto costará desarrollar el producto?

En esta fase se identifican y priorizan los riesgos más importantes. El objetivo de esta fase
es ayudar al equipo de proyecto a decidir cuáles son los verdaderos objetivos del proyecto.
Las iteraciones exploran diferentes soluciones posibles, y diferentes arquitecturas
posibles. Puede que todo el trabajo físico realizado en esta fase sea descartado. Lo único
que normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el
equipo.

Los artefactos que típicamente sobreviven a esta fase son:

Un enunciado de los mayores requerimientos planteados generalmente como casos de

uso.

Un boceto inicial de la arquitectura.

Una descripción de los objetivos del proyecto.

Una versión muy preliminar del plan del proyecto.

Un modelo del negocio.

La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida. Este hito es alcanzado
cuando el equipo de proyectos y los stakeholders llegan a un acuerdo sobre:

Cuál es el conjunto de necesidades del negocio, y qué conjunto de funciones satisfacen

estas necesidades.

21
 Una planificación preliminar de iteraciones.

Una arquitectura preliminar.

Fase de elaboración

Durante la fase de elaboración la mayoría de los Casos de Uso son especificados en

detalle y la arquitectura del sistema es diseñada. Esta fase se focaliza en las “debilidades”
del proyecto. Se identifican los riesgos significativos y se preparan el calendario, el equipo
de trabajo y el costo del proyecto.

 Tanto la funcionalidad como el dominio del problema se estudian en profundidad

 Se define una arquitectura básica
 Se planifica el proyecto considerando recursos disponibles

Durante la fase de elaboración se especifican en detalle la mayoría de los casos de

uso del producto y se diseña la arquitectura.

Las iteraciones en la fase de elaboración:

 Establecen una firme comprensión del problema a solucionar.

 Establece la fundación arquitectural para el software.
 Establece un plan detallado para las siguientes iteraciones.
 Elimina los mayores riesgos.

El resultado de esta fase es la línea base de la arquitectura.

En esta fase se construyen típicamente los siguientes artefactos:

 El cuerpo básico del sw en la forma de un prototipo arquitectural.

 Casos de prueba.
 La mayoría de los casos de uso (80%) que describen la funcionalidad del sistema.
 Un plan detallado para las siguientes iteraciones.

22
La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de Vida.

Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un

acuerdo sobre:

 Los casos de uso que describen la funcionalidad del sistema.

 La línea base de la arquitectura.
 Los mayores riesgos han sido mitigados.
 El plan del proyecto.

Al alcanzar este hito debe poder responderse a preguntas como:

 ¿Se ha creado una línea base de la arquitectura? ¿Es adaptable y robusta?

¿Puede evolucionar?
 ¿Se han identificado y mitigado los riesgos más graves?
 ¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para respaldar
una agenda, costes y calidad realista?
 ¿Proporciona el proyecto, una adecuada recuperación de la inversión?
 ¿Se ha obtenido la aprobación de los inversores?

Fase de desarrollo

Durante la fase de construcción, el foco del producto se mueve de la arquitectura de base

a un sistema lo suficientemente completo como para llevarlo al usuario. El baseline de
arquitectura crece en complejidad y se convierte en un sistema completo, de la misma
manera, se refina el diseño para llevarlo a código fuente.

El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de

análisis, diseño e implementación.

Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada
de manera incremental conforme se construye (se permiten cambios en la estructura).

 Gran parte del trabajo es programación y pruebas.

 Se documenta tanto el sistema construido como el manejo del mismo.
 Esta fase proporciona un producto construido junto con la documentación.

23
Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece
hasta convertirse en el sistema completo.

Al final de esta fase, el producto contiene todos los casos de uso implementados, sin
embargo, puede que no esté libre de defectos.

Los artefactos producidos durante esta fase son:

 El sistema software
 Los casos de prueba
 Los manuales de usuario
La fase de construcción finaliza con el hito de Capacidad Operativa Inicial.

Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo
sobre:

 El producto es estable para ser usado.

 El producto provee alguna funcionalidad de valor.
 Todas las partes están listas para comenzar la transición.

Fase de Transición

En la fase de transición el objetivo es garantizar que los requisitos se han cumplido, con
la satisfacción de las partes interesadas. Esta fase a menudo se inicia con una versión
beta de la aplicación. Otras actividades incluyen la preparación del ambiente, se
completan, se identifican y corrigen defectos. La fase de transición termina con un cierre
dedicado al aprendizaje de lecciones, las cuales quedan para futuros ciclos.

 Se libera el producto y se entrega al usuario para un uso real.

 Se incluyen tareas de marketing, empaquetado atractivo, instalación,
configuración, entrenamiento, soporte, mantenimiento, etc.
 Los manuales de usuario se completan y refinan con la información anterior.
 Estas tareas se realizan también en iteraciones.

24
La fase de transición cubre el período durante el cual el producto se convierte en la versión
beta.

Las iteraciones en esta fase continúan agregando características al software. Sin

embargo, las características se agregan a un sistema que el usuario se encuentra
utilizando activamente.

Los artefactos construidos en esta fase son los mismos que en la fase de construcción. El
equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad
del sistema desarrollado en la fase anterior.

La fase de transición finaliza con el hito de Lanzamiento del Producto. Este hito se alcanza
cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre:

 Se han alcanzado los objetivos fijados en la fase de Inicio.

 El usuario está satisfecho.

1.5. Lenguaje unificado de modelado (ULM)

UML se define como un lenguaje gráfico para visualizar, especificar, construir y

documentar los artefactos de un sistema con gran cantidad de software. Proporciona una

forma estándar de diagramar planos de un sistema, abarcando las partes conceptuales

(funciones del sistema, y en principio también procesos industriales), y los objetos
concretos (clases escritas en lenguajes de programación específico, esquemas de bases
de datos, componentes de software reutilizables).

El problema del modelamiento de sistemas automatizados a través de lenguajes de

software abierto como UML se aborda en el trabajo de Nickel, donde se propone la
integración de diagramas UML con esquemas SDL (Lenguaje de Diagramación
Específico), utilizados en ingeniería eléctrica y mecánica.

25
Cada vez que se quiere soportar el diseño e implementación de una solución
automatizada se debe contar con la documentación adecuada tanto para el desarrollo,
como para su posterior mantenimiento o eventuales modificaciones.

Resulta además conveniente contar con representaciones visuales del sistema sobre el
que se desea operar, ya que la visualización adecuada permite comprender mejor lo que
está creando.

De otra parte es importante que tanto desarrolladores, como consultores, clientes y

usuarios de los sistemas tengan puntos de convergencia en la interpretación estructural
y funcional de los eslabones de un sistema; esto se hace posible mediante la utilización
de notaciones de diseño que todos los actores involucrados en el sistema
(diseñadores y usuarios), deben aceptar como pautas, de la misma forma que los
planos de ingeniería se convierten en guías para los ensambladores. El UML
constituye ese tipo de notación para diseño.

UML es un lenguaje de modelado universal, por lo que cada vez más, es empleado para
la descripción de arquitecturas. En este caso, se usa para la descripción de la Arquitectura
de Componentes Genéricos, y en particular, para especificar la estructura interna de los
elementos arquitectónicos mediante los diagramas de clases y de secuencia.

La formalización de estos diagramas permite establecer qué es para cada uno de estos
tipos de modelos, relaciones de inclusión y refinamiento y a partir de esto probar la
consistencia interna de cada uno de los elementos, así como la verificación de las
interconexiones entre dichos elementos.

En el artículo “Constructing an Ontology for Multi Agent System for a software Engineering
Perspective: A Case Study”, los autores presentan una estrategia para la construcción de
los diagramas colaborativos que estructuran diferentes jerarquías en un sistema, de
manera similar a como se estructuran las cadenas de producción en los sistemas
automatizados.

26
La principal ventaja de UML es que constituye un lenguaje de propósito general, aunque
esto en ocasiones puede llegar a convertirse en una desventaja, porque no se pueden

representar en toda su dimensión y detalle las situaciones o características propias de

dominios específicos.

En el artículo “Principios de una metodología para integración empresarial bajo enfoque

helénico”, los autores muestran de una forma clara como a través de UML, se puede hacer
el modelamiento de las instancias de gestión y supervisión de los procesos en una planta
de automatización industrial, coordinando todos los elementos encaminados a dar
respuesta a los requerimientos de los clientes.

UML es un lenguaje universal que permite a los desarrolladores centrarse en soluciones

automatizadas de los aspectos más relevantes del proceso creativo, al igual que se
destacan las relaciones de causa y efecto entre las variables y los parámetros de una
planta, su comportamiento dinámico y su comportamiento en el tiempo. Al ver las
interacciones de los elementos del sistema como vínculos que deben cumplir una función
específica, pueden entonces ser identificadas para convertirlas en objetos de diseño o
subrutinas que se pueden ejecutar en diferentes tecnologías como las de

microcontroladores, PLC (Controladores lógicos Programables) o incluso en

computadores personales.

El modelamiento en UML de escenarios tanto convencionales como anómalos, se le

denomina Casos de Uso; la caracterización estructural y funcional de un eslabón o bucle
se realiza mediante el diagrama de clases; y finalmente las interacciones entre los bucles
son descritas por el diagrama de secuencias de acuerdo a la metodología UML

27
 2. Proceso de análisis para el desarrollo de sistemas de información

2.1 Ingeniería de requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un
sistema es llamado ingeniería de requerimientos. La meta de la ingeniería de
requerimientos (IR) es entregar una especificación de requisitos de software correcta y
completa.
Algunos otros conceptos de ingeniería de requerimientos son:
“Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el
problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a
comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente
quiere y cómo interactuarán los usuarios finales con el software”.

“La ingeniería de requerimientos es el proceso de desarrollar una especificación de

software. Las especificaciones pretender comunicar las necesidades del sistema del
cliente a los desarrolladores del sistema”.
En síntesis, el proceso de ingeniería de requerimientos se utiliza para definir todas
las actividades involucradas en el descubrimiento, documentación y mantenimiento
de los requerimientos para un producto de software determinado, donde es muy
importante tomar en cuenta que el aporte de la IR vendrá a ayudar a determinar la
viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando
posteriormente por un subproceso de obtención y análisis de requerimientos, su
especificación formal, para finalizar con el subproceso de validación donde se verifica que
los requerimientos realmente definen el sistema que quiere el cliente.

Importancia de la ingeniería de requerimientos

Según la autora Lizka Johany Herrera en su documento de la ingeniería de

requerimientos, los principales beneficios que se obtienen de la Ingeniería de
Requerimientos son (2003: 3):
 Permite gestionar las necesidades del proyecto en forma estructurada: Cada
actividad de la IR

28
  consiste de una serie de pasos organizados y bien definidos.
 Mejora la capacidad de predecir cronogramas de proyectos, así como sus
resultados: La IR proporciona un punto de partida para controles subsecuentes y
actividades de mantenimiento, tales como estimación de costos, tiempo y recursos
necesarios.
 Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un
mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente
aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor
importancia en el ciclo de desarrollo de software y de las primeras en llevarse a
cabo.
 Mejora la calidad del software: La calidad en el software tiene que ver con cumplir
un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad,
desempeño, etc.).
 Mejora la comunicación entre equipos: La especificación de requerimientos
representa una forma de consenso entre clientes y desarrolladores. Si este
consenso no ocurre, el proyecto no será exitoso.
 Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente
a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del
problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Actividades de la ingeniería de requerimientos

Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice que
dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo para
completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para
el desarrollo de un proyecto de software realizar una especificación y administración
adecuada de los requerimientos de los clientes o usuarios.
Las cuatro actividades son: extracción, análisis, especificación y validación, y serán
explicadas a continuación cada una de ellas.
2.2 Modelo de casos de uso

29
El modelo de Casos de Uso es una colección de escenarios de éxito y errores que describe
a las entidades del sistema a través de la realización de objetivos
También se le conoce como Modelo de Comportamiento y corresponde a la F del
esquema FURPS+.

Actores
 Los actores modelan cualquier entidad externa que necesite
 intercambiar información con el sistema
 No hay que confundir a un actor con un usuario
 Un usuario es la persona que utiliza el sistema
 En la mayoría de los casos un usuario es un actor.

Un Actor es algo con un comportamiento dentro del sistema, una persona, un sistema o
una organización.
 Actores Principales
 Actores de Apoyo
 Actores Pasivos

Tipos de Actores

 Principal. Es aquel que satisface objetivos de usuario a través del uso del sistema
 Apoyo. Proporciona un servicio

30
  Pasivo. Interesado en el comportamiento del caso de uso, pero no tiene mayor
interacción

Un caso de uso constituye un flujo completo de eventos que especifica la interacción que
tiene lugar entre el actor y el sistema.

Cada que se ejecuta un caso de uso, se puede ver como una instancia de sí mismo. Los
nombres de los casos de uso deben corresponder a acciones. El modelo de caso de uso
se basa en diagramas similares a los de transición de estados. Cada caso de uso
representa un estado en el sistema.

Extensiones de Casos de Uso.

Las extensiones permiten tener una visión más elaborada del funcionamiento del sistema
Una extensión es una división de un flujo principal en uno o más subflujos.
Si las diferencias entre las acciones a realizar son pequeñas, se pueden crear sub flujos
a partir de un flujo principal.

Si las diferencias son grandes, se deben crear nuevos casos de uso.

Para relacionar estos casos de uso se utilizan las relaciones de:
 Extensión
 Inclusión
 Generalización

Características de la Extensión

Se considera a la asociación de extensión como una interrupción en el caso de uso original

que ocurre donde el nuevo caso de uso se va a insertar.
Para cada caso de uso que vaya a insertarse en otro caso de uso se debe especificar la
posición en el caso de uso original, donde se insertará. Esta relación se indica con
extiende (extend).

31
Inclusión

La inclusión se define como una sección de un caso de uso que es parte obligatoria del
caso de uso básico.
El caso de uso donde se insertará la funcionalidad depende del caso de uso a ser incluido,
por lo que, si no existe, no puede realizarse el caso básico de manera completa. Esta
relación se etiqueta con incluye (include).

Generalización

Esta relación apoya la reutilización de los casos de uso. Los casos de uso extraídos se
conocen como casos de uso abstractos y servirán solo para describir partes que son
comunes a otros casos de uso.

Los casos de uso que serán instanciados se denominan casos de uso concretos. La
representación es la misma que la de herencia en las clases

32
Identificar Relaciones

El criterio principal es ver que tanto se acoplan las funcionalidades de los casos de uso.
Si el caso de uso a ser extendido es útil por sí mismo, la relación debe ser descrita
utilizando una extensión.

Si los casos de uso son fuertemente acoplados y la inserción debe tomar lugar para poder
tener un curso completo, la relación debe ser escrita mediante la inclusión.

Cuando dos casos de uso comparten funcionalidad común, se debe utilizar la

generalización.

Documentación.

A continuación, se coloca de forma resumida una tabla con los elementos que deberán
documentarse un caso de uso.

33
 2.3 Modelo del negocio.

Un sistema, por pequeño que sea, generalmente es complicado. Por eso se necesita
dividirlo en piezas si se pretende comprenderlo y gestionar su complejidad. Esas piezas
se pueden representar a través de modelos que permitan abstraer sus características
esenciales. De ahí, que en el campo del software también resulte útil la creación de
modelos que organicen y presenten los detalles importantes de problemas reales que se
vinculan con el sistema informático a construir.

Estos modelos deben cumplir una serie de propiedades, entre ellas la de ser coherentes
y relacionados. Uno de los modelos útiles previo al desarrollo de un software es el modelo
del negocio.

El modelado del negocio es una técnica para comprender los procesos del negocio de la
organización. Los propósitos que se persiguen al realizarse el modelado del negocio, son:

entender la estructura y la dinámica de la organización, entender los problemas actuales

e identificar mejoras potenciales, asegurarse de que los clientes, usuarios finales y
desarrolladores tengan una idea común de la organización y derivar los requerimientos
del sistema a partir del modelo de negocio que se obtenga. Para alcanzar estos objetivos,
este flujo de trabajo describe cómo desarrollar la visión de la nueva organización que se
pretende alcanzar, y sobre la base de esta visión, definir los procesos, roles y
responsabilidades de esa organización en el modelo de casos de uso del negocio y el
modelo de objetos del negocio.

Procesos de negocio

El modelo del negocio describe el negocio en términos de casos de usos del negocio, que
corresponde a lo que generalmente se le llama procesos.

El modelo de casos de uso del negocio es un modelo que describe los procesos de un
negocio (casos de uso del negocio) y su interacción con elementos externos (actores),1
tales como socios y clientes, es decir, describe las funciones que el negocio pretende
realizar y su objetivo básico es describir cómo el negocio es utilizado por sus clientes y

34
socios. Implica la determinación de los actores y casos de uso del negocio. Con esta
actividad se pretende: Identificar los procesos en el negocio, definir las fronteras del
negocio que van a modelarse, Definir quién y qué interactuarán con el negocio y crear
diagramas del modelo de casos de uso del negocio.

Un actor del negocio es cualquier individuo, grupo, entidad, organización, máquina o

sistema de información externos; con los que el negocio interactúa. Lo que se modela
como actor es el rol que se juega cuando se interactúa con el negocio para beneficiarse
de sus resultados.

Un proceso de negocio es un grupo de tareas relacionadas lógicamente que se llevan a

cabo en una determinada secuencia y manera y que emplean los recursos de la
organización para dar resultados en apopo a sus objetivos.

Un caso de uso del negocio representa a un proceso de negocio, por lo que se

corresponde con una secuencia de acciones que producen un resultado observable para
ciertos actores del negocio. Desde la perspectiva de un actor individual, define un flujo de
trabajo completo que produce resultados deseables.

Identificación de procesos de negocio

Para identificar los procesos de negocio es muy importante tener en cuenta que deben
generar un valor para el negocio o mitigar los costos del negocio. En este artículo se
proponen 3 vías para identificar procesos de negocio. Ellas son:

1. Clasificación de los procesos de negocio.

2. Identificación de funciones.

3. A partir de los objetivos estratégicos.

A continuación, se describe en qué consiste cada mecanismo de identificación, con

ejemplos de aplicaciones reales que contribuyen a su comprensión.
1. Clasificación de los procesos de negocio.

35
Para encontrar casos de uso del negocio se pueden clasificar los procesos de negocio en
tres categorías:

 Núcleo: Considerar qué valor reciben los actores del negocio primarios y más
importantes: los clientes. Buscar los procesos del negocio respondiendo a la
pregunta: ¿cuáles son los servicios básicos que un cliente recibe del negocio?
 Soporte: Contiene las actividades que no benefician al cliente directamente. Para
identificarlos se pueden buscar actividades como las siguientes: desarrollo y
mantenimiento de personal, de las tecnologías de información y de la oficina,
seguridad y
 actividades legales.
 Gerencial: Estos procesos se encuentran buscando los procesos que tienen que
ver con el manejo del negocio en su conjunto. Normalmente se relacionan con el
actor propietario.

2.4 Modelo del dominio.

Su utilidad radica en ser una forma de inspiración para el diseño de los objetos software.
Es entrada para muchos de los artefactos que se construyen en un proceso software
Un modelo de dominio muestra las clases conceptuales significativas en un dominio del
problema. Se centra en las abstracciones relevantes, vocabulario del dominio e
información del dominio.
Es el artefacto clave del análisis orientado a objetos. En UML se utilizan los diagramas de
clases para representar los modelos de dominio.

Un modelo de dominio es una representación de las clases conceptuales del mundo real,
no de componentes software. No se trata de un conjunto de diagramas que describen
clases software, u objetos software con responsabilidades.

El modelo de dominio muestra las clases conceptuales o vocabulario del dominio.

Informalmente una clase conceptual es una idea, cosa u objeto. Formalmente, una clase
conceptual puede considerarse en términos de su símbolo, intensión y extensión.

36
Símbolo: palabras o imágenes que representan una clase conceptual
Intensión: la definición de una clase conceptual
Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual

Objetivo crear un modelo de dominio de clases conceptuales significativas del dominio de

interés.
Se van añadiendo clases al modelo del dominio a medida que se revisan los escenarios
identificados en los casos de uso.
Es mejor especificar en exceso un modelo de dominio con muchas clases conceptuales
de grano fino que especificar por defecto.
El modelo no es mejor por tener pocas clases conceptuales.
Es normal obviar clases conceptuales durante la identificación inicial para descubrirlas
más tarde (incluso en diseño) al considerar atributos y asociaciones.
No se deben excluir clases conceptuales porque los requisitos no indican necesidad obvia
de registrar información sobre ella o porque la clase conceptual no tenga tributos.
Estrategias para identificar clases conceptuales
Utilizar una lista de categorías de clases conceptuales
Identificar frases nominales
Patrones de análisis

37
Modelo de Dominio o Conceptual: Puede utilizarse para capturar y expresar el
entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema.
El modelo de dominio es utilizado por el analista como un medio para comprender el sector
de negocios al cual el sistema va a servir.

El modelo de dominio puede ser tomado como el punto de partida para el diseño del
sistema. Cuando se realiza la programación orientada a objetos, el funcionamiento interno
del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos
del modelo de dominio constituye una primera versión del sistema.

Cuando hacer Modelo de Dominio o Conceptual

Si no se logra lo planteado en el modelo del negocio entonces identifico conceptos, se les

da definiciones a estos conceptos y se trata de unir o relacionar en otro modelo distinto
que es el de dominio. Este modelo permitirá mostrar de manera visual los principales
conceptos que se manejan, ayudando a los usuarios, desarrolladores e interesados; a
utilizar un vocabulario común para poder entender el contexto en que se desarrolla el
sistema. Además, contribuirá a identificar personas, eventos, transacciones y objetos
involucrados en el sistema.

Clases

Se obtienen de la base de del conocimiento de unos pocos expertos del dominio o

posiblemente del conocimiento de asociado con sistemas similares al que estamos
desarrollando.
Las clases tienen atributos, pero normalmente ninguna o muy pocas operaciones.
Puede hacer la traza de las clases hasta la experiencia de los expertos del dominio. No
hay forma evidente de hacer la traza entre el modelo de dominio y los casos de usos del
sistema.

38
A continuación, se explica en qué consiste cada una de las clases que conforman el
modelo de dominio

Definición de las clases del modelo de dominio

Exportador: Usuario que posee privilegios para exportar un curso. Administrador: Usuario
que posee privilegios para exportar un curso y configurar el bloque C2E-Book Moodle:
Sistema de Gestión de Aprendizaje, donde el Exportador puede acceder al bloque C2E-
Book para exportar cursos a formato de libro electrónico interactivo.

Curso: Conjunto de contenidos referentes a una materia.

Bloque C2E-Book: Herramienta que permitirá exportar un curso de la plataforma de

teleformación Moodle a formato de libro electrónico interactivo.

Paquete EPUB: Conjunto de ficheros (empaquetados) que componen el formato de libro

electrónico interactivo EPUB.
Actividades: Constituye la parte activa y colaborativa de un curso donde el estudiante tiene
que hacer algo más que leer un texto. Debates y discusiones, resolución de problemas
propuestos, redacción de trabajos, talleres, cuestionarios en línea, entre otros.

39
Recursos: Representa los contenidos y materiales del curso. Son todo tipo de textos,
libros, apuntes, presentaciones de diapositivas, enlaces a páginas web externas entre
otros, pensados para que los estudiantes los lean y estudien sobre ellos.

3. Diseño de sistemas de información

3.1 Modelo de datos

Si los requerimientos del software incluyen la necesidad de crear, ampliar o hacer interfaz
con una base de datos, o si deben construirse y manipularse estructuras de datos
complejas, el equipo del software tal vez elija crear un modelo de datos como parte del
modelado general de los requerimientos.
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente
un modelo de datos permite describir:

 Las estructuras de datos de la base: El tipo de los datos que hay en la base y la
forma en que se relacionan.
 Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los
datos para reflejar correctamente la realidad deseada.
 Operaciones de manipulación de los datos: típicamente, operaciones de
agregado, borrado, modificación y recuperación de los datos de la base.

El modelado de datos responde a una serie de preguntas específicas importantes para

cualquier aplicación de procesamiento de datos. ¿Cuáles son los objetos de datos
primarios que va a procesar el sistema?, ¿Cuál es la composición de cada objeto de datos
y qué atributos describe el objeto?, ¿Dónde residen actualmente los objetos? ¿Cuál es la
relación entre los objetos y los procesos que los transforman?
Para responder estas preguntas, los métodos de modelado de datos hacen uso del
Diagrama de Entidad-Relación (DER). Permite que un ingeniero del software identifique
objetos de datos y sus relaciones mediante una notación gráfica. En el contexto del
análisis estructurado, el DER define todos los datos que se introducen, se almacenan, se
transforman y se producen dentro de una aplicación.

40
El DER es específicamente útil para aplicaciones en donde los datos son complejos.

Simbología:

Ejemplo:
Representación tabular de objetos de datos

Modelado de flujo de información

La información se transforma a medida que fluye por un sistema basado en computadora.

El sistema acepta entradas en una gran variedad de formas; aplica elementos de
hardware, software y humanos para transformar la entrada en salida, y produce salida en
una gran variedad de formas. La entrada puede ser una señal de control transmitida por

41
un controlador, una serie de números escritos por un enlace de una red o un archivo
voluminoso de datos recuperado de un almacenamiento secundario.

La transformación puede ser, desde una sencilla comparación lógica, hasta un complejo
algoritmo numérico o un mecanismo de reglas de un sistema experto.
El análisis estructurado es una técnica del modelado del flujo y del contenido de la
información. La representación del modelado de flujo de datos puede hacerse a través de
un Diagrama de Flujo de Datos.

El modelado del flujo de datos es una actividad fundamental del análisis estructurado.
El modelado orientado al flujo da una indicación de la forma en la que las funciones de
procesamiento transforman los objetos de datos.

Aunque algunos ingenieros de software perciben el modelado orientado al flujo como una
técnica obsoleta, sigue siendo una de las notaciones más usadas actualmente para hacer
el análisis de los requerimientos.

Los diagramas de flujo de datos se utilizan para complementar los diagramas UML y
amplían la perspectiva de los requerimientos y del flujo del sistema.

El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de la

información y las transformaciones que se aplican a los datos al moverse desde la entrada
hasta la salida; ya que adopta un punto de vista del tipo entrada-proceso-salida para el
sistema.

Se puede usar el diagrama de flujo de datos para representar un sistema o un software a

cualquier nivel de abstracción. De hecho, los DFD’s pueden ser divididos en niveles que
representen un mayor flujo de información y un mayor detalle funcional. Por consiguiente,
el DFD proporciona un mecanismo para el modelado funcional, así como el modelado del
flujo de información.

42
Un DFD de nivel 0, también denominado modelo fundamental del sistema o modelo de
contexto, representa al elemento de software completo como una sola burbuja con datos
de entrada y de salida representados por flechas de entrada y de salida, respectivamente.
Al dividir el DFD de nivel 0 para mostrar más detalles, es cuando empezamos a crear los
DFD’s por niveles.

Ward y Mellor amplían la notación básica del análisis estructurado para que se adapte a
las siguientes demandas impuestas por los sistemas de tiempo real:

 Flujo de información que es recogido o producido de forma continua en el tiempo.

 Información de control que pasa por el sistema y el procesamiento de control
asociado.
 Ocurrencias múltiples de la misma transformación que se encuentran a menudo en
situaciones de multitarea.
 Estados del sistema y mecanismos que producen transición de estados en el
sistema

43
 3.2 Modelo de clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
consentimiento.
Un diagrama de clases está compuesto por los siguientes elementos:

 Clase: atributos, métodos y visibilidad.

 Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos

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, una clase 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 private, 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:
private, protected o public).

44
Atributos y Métodos

 Atributos: 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.
 private (-,): 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).

 Métodos: 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.
 private (-,): 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.

Relaciones entre Clases

Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden

interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la

cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relación y éstas pueden ser:

45
  uno o muchos: 1..* (1..n)
 0 o muchos: 0..* (0..n)
 número fijo: m (m denota el número).

Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Super
Clase, por ende, la Subclase además de poseer sus propios métodos y atributos, poseerá
las características y atributos visibles de la Super Clase (public y protected), ejemplo:

Agregación

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la aplicación,
tenemos dos posibilidades:

 Por Valor: (Rombo relleno). Es un tipo de relación estática, en donde el tiempo de

vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye.
Este tipo de relación es comúnmente llamada Composición (el Objeto base se
construye a partir del objeto incluido, es decir, es "parte/todo").

46
  Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del
objeto incluido es independiente del que lo incluye. Este tipo de relación es
comúnmente llamada Agregación (el objeto base utiliza al incluido para su
funcionamiento).

Un Ejemplo es el siguiente:

Asociación

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran
entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un
objeto no depende del otro.

Ejemplo:

Dependencia o Instanciación (uso)

Representa un tipo de relación muy particular, en la que una clase es instanciada (su
instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene
una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la

47
creación del Objeto Ventana está condicionado a la instanciación proveniente desde el
objeto Aplicación):

3.3 Diagrama de secuencia

El diagrama de secuencias hace parte de los diagramas de interacción de la especificación

UML que describen los aspectos dinámicos de un sistema y muestran la interacción entre
los objetos de un sistema y los mensajes enviados entre ellos, Ordenados según su
secuencia en el tiempo.

Los diagramas de secuencias son útiles para diversos:

• El modelado de escenarios de uso. Un escenario de uso es una descripción de una

posible forma en que un sistema se utiliza. La lógica de un escenario de uso puede ser
parte de un caso de uso, por ejemplo, una secuencia alternativa o un paso completo a
través de un caso de uso, tal como la lógica que describe la secuencia normal de la acción
o una parte de ella. Un escenario de uso también puede ser un paso a través de la lógica
contenida en varios casos de uso.

• El modelado de la lógica de los métodos. Los diagramas de secuencias se pueden utilizar

para explorar la lógica de una operación, función o procedimiento complejos, ya que ofrece
una forma de observar las invocaciones a las operaciones definidas en las clases.

• La detección de cuellos de botella en un diseño orientado a objetos. Al observar los

mensajes enviados a un objeto y cuánto se tardan en ejecutar el método invocado, es
posible concluir que es necesario cambiar el diseño con el fin de distribuir la carga dentro
del sistema.

Los principales elementos del diagrama de secuencias especificados por Fowler y Scott
para la versión 2.0 y que siguen siendo válidos en la Superestructura UML se pueden
apreciar en la siguiente tabla.

48
 3.4 Modelo de interfaces

El Desarrollo basado en modelos de la interfaz de usuario, en inglés Model-based User

Interface Development (MB-UID), es una técnica que permite especificar todos los
aspectos relacionados con la interfaz de usuario empleando un conjunto de modelos
abstractos. Estos modelos son empleados para dirigir todo el proceso de construcción de
la interfaz de usuario y permiten generar de forma automática código, documentación,
pruebas, etc.

Modelos

Tradicionalmente no ha existido un consenso sobre el conjunto de modelos a emplear,

pero de forma recurrente aparecen los siguientes modelos en la literatura:

 Modelo de dominio: Define los objetos accesibles a los usuarios a través de la

interfaz de usuario. Puede modelarse empleando un diagrama de clases o
cualquier otro similar. Los elementos que típicamente aparecen en el modelo de
dominio son clases o entidades con sus atributos y relaciones.

49
 Modelo de usuarios: Especifica una descomposición jerárquica de usuarios en
estereotipos que comparten un rol común. Los elementos que suelen aparecen en
este modelo son usuarios, grupos, sus características y relaciones.
 Modelo de tareas: Describe el conjunto de tareas que los usuarios pueden realizar.
Este modelo suele tener una estructura jerárquica y normalmente se compone de
objetivos, acciones, precondiciones y postcondiciones. Suele expresarse en una
notación denominada ConcurTaskTrees (CTT).
 Modelo de presentación: Normalmente se divide en dos submodelos:
 Modelo de presentación abstracta: Incluye una descripción abstracta de la
estructura y comportamiento de los elementos visuales de la interfaz de usuario.
Está compuesto de Objetos de Interacción Abstractos (Abstract Interaction Objects)
e Interfaces de Usuario Abstractas (Abstract User Interfaces).
 Modelo de presentación concreta: Describe en detalle los elementos visuales de la
interfaz de usuario incluyendo, colores, fuentes y Objetos de Interacción Concretos
(Concrete Interaction Objects).

50
 4. Modelo de implementación de sistemas de información

4.1 Modelo de componentes

Los diagramas de componentes se utilizan para modelar los componentes que ayudan a
hacer funcionalidades, representando la forma en la que estos se organizan y sus
dependencias.

El diagrama de componentes es uno de los principales diagramas UML. Está clasificado

como diagrama de estructura y, como tal, representa de forma estática el sistema de
información. Habitualmente se utiliza después de haber creado el diagrama de clases,
pues necesita información de este diagrama como pueden ser las propias clases.

Este diagrama proporciona una vista de alto nivel de los componentes dentro de un
sistema. Los componentes pueden ser un componente de software, como una base de
datos o una interfaz de usuario; o un componente de hardware como un circuito, microchip
o dispositivo; o una unidad de negocio como un proveedor, nómina o envío.

Algunos usos de este tipo de diagrama es el siguiente:

 Se utilizan en desarrollo basado en componentes para describir sistemas con

arquitectura orientada a servicios.
 Mostrar la estructura del propio código.
 Se puede utilizar para centrarse en la relación entre los componentes mientras se
ocultan los detalles de las especificaciones.
 Ayudar a comunicar y explicar las funciones del sistema que se está construyendo
a los interesados o stakeholders.

Para su construcción se debe plantear en primer lugar identificar los componentes que
utilizará el sistema de información, así como las distintas interfaces. Una forma típica y
común para una primera aproximación en sistemas sencillos es utilizar un componente
central al que los demás componentes se unen, y que se utiliza como componente gestor
del sistema.

51
 Primera aproximación al diagrama de componentes

Elementos del diagrama de componentes

El diagrama de componentes está formado por tres elementos: Componente, Interfaz y

Relación de dependencia.
Componente
Un componente es un bloque de unidades lógicas del sistema, una abstracción
ligeramente más alta que las clases. Se representa como un rectángulo con un rectángulo
más pequeño en la esquina superior derecha con pestañas o la palabra escrita encima
del nombre del componente para ayudar a distinguirlo de una clase.
Un componente puede representar dos tipos de elementos: componentes lógicos (como
por ejemplo componentes de negocio o proceso) o componentes físicos (como
componentes .NET, EJB…). Por ejemplo, en una aplicación desarrollada en java habrá,
con total seguridad, varios componentes “.java”, que son componentes lógicos del
sistema.
Es representado a través de un rectángulo que tiene, a su vez, dos rectángulos a la
izquierda, tal y como se muestra en la siguiente imagen:

Notación de componente

52
Otra notación, utilizada en las últimas versiones de UML consiste en un rectángulo con un
rectángulo más pequeño en la esquina superior derecha con pestañas.

Otra notación de componente

También es posible utilizar el diagrama de paquetes para hacer un conjunto de varios
módulos. Con esto se consigue representar la unión de esos módulos para un fin concreto.

Paquete con varios componentes

Ejemplos de componentes podrían ser los siguientes: Gestión de E/S, Animal, Persona,
Gestión de incidencias, Gestor de workflow.

Ejemplos de componentes
Lo ideal es que los componentes estén diseñados de forma que tengan una gran cohesión
y un bajo acoplamiento, para favorecer su reutilización.
Interfaz

53
La interfaz está siempre asociada a un componente y se utiliza para representar la zona
del módulo que es utilizada para la comunicación con otro de los componentes.
Se representa con una línea que tiene al final un circulo no relleno:

Notación de una interfaz

Otros módulos pueden conectarse a una interfaz. Esto se hace cuando un componente
requiere o utiliza al otro componente mediante su interfaz, que son las operaciones
externas que ofrece el componente. Se representa con una línea que termina en un
semicírculo que rodea la interfaz del otro componente. En el diagrama se vería de la
siguiente manera:

Utilización de interfaz
Relación de dependencia
Aunque puedes mostrar más detalles sobre la relación entre dos componentes utilizando
la notación de interfaces (interfaz proporcionada y la interfaz requerida), también puedes
usar una flecha de dependencia para mostrar la relación entre dos componentes. Es una
relación más general.
La relación de dependencia representa que un componente requiere de otro para ejecutar
su trabajo. Es diferente a la interfaz, pues esta identifica que un componente ofrece una
serie de operaciones. En cualquier caso, en ocasiones para simplificar el diagrama no se
usan las interfaces, sino que solamente se utilizan relaciones de dependencia.

54
Una relación de dependencia se representa mediante una flecha discontinua que va desde
el componente que requiere de otro componente hasta el requerido.

Notación de una relación de dependencia

Las relaciones de dependencia pueden unir, además de componentes con otros
componentes, componentes con interfaces.

4.2 Modelo de despliegue

El diagrama de despliegue es otro de los diagramas de estructura del conjunto de los

diagramas de UML. Es utilizado para representar la distribución física (estática) de los
componentes software en los distintos nodos físicos de la red.

Suele ser utilizado junto con el diagrama de componentes (incluso a veces con el
diagrama de paquetes) de forma que, juntos, dan una visión general de cómo estará
desplegado el sistema de información. El diagrama de componentes muestra que
componentes existen y como se relacionan mientras que el diagrama de despliegue es
utilizado para ver cómo se sitúan estos componentes lógicos en los distintos nodos físicos.

Como prácticamente todos los diagramas de UML, puede ser utilizado para representar
aspectos generales o muy específicos, siendo utilizado de forma más común para
aspectos generales.

Sus principales características son las siguientes:

 Permite identificar los nodos en los que trabajará o utilizarán el sistema de

información, identificando a su vez agentes externos e internos que interactúen con

55
 el sistema.
 Permite representar de forma clara la arquitectura física de la red, así como la
distribución del componente software. UML no tiene un tipo de diagramas
específico para mostrar la arquitectura de la red, así que se utiliza este tipo de
diagrama que cumple efectivamente este cometido, aunque se le suele hacer
alguna modificación gráfica.
 Lo más normal es utilizarlo para dar una visión global, pero es posible utilizarlo para
representar partes específicas de la implementación.

Notación

El diagrama de componentes utiliza, principalmente, dos tipos de elementos: Nodos y

conexiones.

Nodos
Los nodos se definen como elementos utilizados para representar un elemento físico que
interactúa de alguna manera con el sistema o bien forma parte del mismo.
Se representa utilizando un cubo tridimensional, tal y como representa la siguiente figura:

Notación de un nodo

Algunos ejemplos de nodos podrían ser los siguientes: Servidor web, Servidor DNS,
Servidor de Aplicaciones, PC Usuario, Base de datos.
Los nodos también pueden ser representados utilizando iconos personalizados con la
finalidad de clarificar el contenido del diagrama. Algunos de estos iconos de uso extendido
son:
Un muro para representar un Firewall.
Un icono de un PC para representar el equipo de un usuario.

56
Un circulo con flechas para identificar a un router.
Una nube para representar una WAN (aunque no es propiamente un nodo)
Un cilindro para representar una base de datos.
Un nodo a su vez puede tener nodos incluidos en su interior, dando a conocer que son
sistemas separados incluidos dentro del mismo nodo físico. De esta forma se
compondrían los nodos compuestos.

Notación de un nodo con subnodos

Por ejemplo, un nodo llamado Servidor de base de datos podría tener en su interior dos
bases de datos separadas de sistemas de información distintos. Podría ser representado
de la siguiente forma:

Ejemplo de nodo compuesto

Conexión
La conexión representa una asociación entre dos nodos, a través de la cual estos nodos
son capaces de transmitir información en forma de mensajes o señales.
Se representa utilizando una línea continua que une los dos nodos que se asocian.

Notación de una conexión

57
Es común incluir en las conexiones una etiqueta que represente a través de que medio se
realiza la conexión. Por ejemplo: Internet, WAN.
También, si es relevante, se suele poner al lado de los nodos el número de nodos que
participan en la asociación. Por ejemplo, un servidor web al que se conectan usuarios a
través de una red WAN y que se prevé una conexión de 100 usuarios tendría la siguiente
representación:

Notación de conexión Cliente-Servidor

Diagramas de arquitectura de red

Como ya se ha mencionado, el estándar UML no tiene un tipo de diagrama para describir

la arquitectura de red y, por lo tanto, no proporciona elementos específicos relacionados
con la red. El diagrama de despliegue podría usarse para este propósito, generalmente
con algunas modificaciones adicionales. El diagrama de arquitectura de red generalmente
mostrará nodos de red y rutas de comunicación entre ellos.
Este es un ejemplo de diagrama de despliegue que actúa como diagrama de red. Como
ves, se utilizan distintos iconos para que se entienda mejor:

Ejemplo de diagrama de red

58
Ejemplo de diagrama de despliegue

La siguiente muestra un ejemplo sobre este tipo de diagrama donde se muestran un total
de 6 nodos y algunos de sus componentes:

Ejemplo de diagrama de despliegue

4.3 Planeación del desarrollo de sistemas de información.

La planificación de los sistemas de información tiene como propósito la revisión del estado
actual de la organización, la identificación de la situación estratégica deseada y la
planificación de los proyectos y cambios en la organización necesarios para alcanzar dicho
estado deseado, típicamente en un periodo de 3 o 5 años.

Esta actividad debe involucrar a todos los actores relevantes de la organización para
conseguir la alineación de los objetivos de los sistemas de información con los
organizativos.

A pesar de que el proceso de creación del plan de sistemas no es trivial, como tampoco
lo es su posterior despliegue, el objetivo se puede definir de una manera sencilla: se trata

59
de analizar el estado actual de las tres dimensiones básicas de los sistemas de
información, identificar su situación futura deseada y determinar las acciones necesarias
para alcanzar dicha situación futura:

Las fases propuestas para la redacción de un plan estratégico de sistemas son:

Tabla 1

FASE 1. Determinar la estrategia y contexto actual de la organización

La primera fase del proyecto consiste en asegurar que cubrirá de manera efectiva las
necesidades de la organización, y conocer esta suficientemente para poder determinar
posteriormente sus requisitos de los sistemas de información.
El primer paso será validar el plan de proyectos y establecer los antecedentes.

FASE 2. Identificar los requisitos de negocio para los sistemas de información

La segunda fase del proyecto, una vez identificado el contexto y revisada la información
disponible sobre la estrategia y planificación de la organización, es determinar cuáles son
los requisitos concretos de negocio a los que pueden contribuir estos sistemas.
Para identificar dichos requisitos con una visión amplia y estratégica, deben revisarse las
necesidades del negocio desde varios niveles del análisis:

60
Análisis FODA del negocio.
Requisitos de contexto y operativos.

FASE 3. Determinar el estado actual de los sistemas de información

Una vez que se ha revisado el negocio y se han obtenido sus requisitos, la siguiente fase
es determinar el estado actual de los sistemas de información, para poder analizar
posteriormente la efectividad del soporte ofrecido a partir de sus tres aspectos básicos:
Estado de la infraestructura técnica.
Estado de las aplicaciones.
Estado de la organización.

FASE 4. Análisis de necesidades de los sistemas de información

Una vez conocidos los requisitos que el negocio demanda de los sistemas de información
y determinado el estado actual de estos, se debe realizar su análisis para identificar cuáles
son los puntos fuertes a mantener y las debilidades a mejorar.
Para ello, puede realizarse un análisis a los siguientes niveles:
Análisis estratégico de los sistemas de información.
Benchmarking de las prácticas de la competencia y del estado de la industria IT.
Soporte ofrecido a los compontes de negocio.
Evaluación de coste/beneficio de las aplicaciones y los sistemas.
El análisis identificará acciones de mejora, determinadas en base a las oportunidades
identificadas anteriormente, y se agruparán en los tres aspectos de los sistemas de
información anteriormente vistos:
Aplicaciones.
Infraestructura.
Organización y procesos.

FASE 5. Definir la estrategia y plan de sistemas de información

61
La última fase de un proyecto de planificación estratégica de sistemas es la definición de
la estrategia y plan de sistemas.

FASE 6. Desarrollar el programa de despliegue

Una vez finalizado y aprobado el plan estratégico de sistemas, se debe desplegar y ello
se planifica y gestiona de manera similar a cualquier otro programa o proyecto grande.
Lanzamiento del programa.
Seguimiento y evaluación del programa.
Una vez completada la planificación anual, la actividad principal es el seguimiento de los
indicadores operativos y de los proyectos en curso, así como la toma y supervisión de las
acciones correctivas que se abran en base a las desviaciones identificadas. En paralelo
se mantiene la relación con el cliente interno, que es el resto de la organización,
gestionando la demanda de peticiones generales y de proyectos no previstos en el plan
de sistemas.

62
 Referencias bibliográficas

Anónimo, I. (s.f). Conceptualización de tecnología orientada a objetos. Recuperado el 05

de agosto de 2022. Disponible en: https://vdocuments.mx/download/11-
conceptualizacion-de-tecnologia-orientada-a-objetos.

Arias B. (2016). Lenguaje de modelamiento unificado (UML) para modelamiento de

embotelladora. Recuperado el 08 de agosto de 2022. Disponible en:
https://www.redalyc.org/articulo.oa?id=84950584006

Anónimo (2017). Modelo de Casos de Uso y Representación en UML. Recuperado el 10

de agosto de 2022. Disponible en:
https://academicos.azc.uam.mx/jfg/diapositivas/adsi/Unidad_5.pdf

Anónimo. (s.f.). Modelo de dominio. Recuperado el 13 de agosto de 2022. Disponible en:

https://www.ecured.cu/Modelo_de_dominio

Anónimo. (s.f.). Modelo de datos. Recuperado el 15 de agosto de 2022. Disponible en:

https://virtual.itca.edu.sv/Mediadores/stis/24__modelado_de_datos_de_flujo_de_informacin
__y_comportamiento.html

Anónimo (s.f.). Diagrama de componentes. Recuperado el 16 de agosto de 2022.

Disponible en: https://diagramasuml.com/componentes/

Chávez M. (2005). Ingeniería de requisitos. Recuperado el 08 de agosto de 2022.

Disponible en: https://www.redalyc.org/articulo.oa?id=66612870011

Esguerra F. (s.f.). Modelado de clases. Recuperado el 15 de agosto de 2022. Disponible

en:https://www.emagister.com/uploads_user_home/Comunidad_Emagister_5401_Modelad
o_de_Clases.pdf

63
Hernández A. (2005). Identificación de procesos de negocio. Recuperado el 13 de agosto
de 202. Disponible en: https://www.redalyc.org/pdf/3604/360433558004.pdf

Islas L. (s.f). Proceso unificado de modelado. Recuperado el 07 de agosto de 2022.

Disponible en: http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro10/

Maida E. (2015). Metodologías emergentes de desarrollo de software. Recuperado el 05

de agosto de 2022. Disponible en:
https://repositorio.uca.edu.ar/bitstream/123456789/522/1/metodologias-desarrollo-
software.pdf

Zapata C y Garcés L. (2008). Generación del diagrama de secuencias de UML 2.1.1 desde
esquemas preconceptuales. Recuperado el 16 de agosto de 2022. Disponible en:
https://www.redalyc.org/pdf/1492/149212844007.pdf

64