Antologia Análisis y Modelado de S.I
Antologia Análisis y Modelado de S.I
Agosto 2022
ÍNDICE
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
2
3
4
1.2. Metodologías emergentes de desarrollo de software.
Metodología Tradicional
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.
6
7
8
9
10
11
12
13
14
15
1.3. Métodos de desarrollo de software orientado a objetos
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.
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.
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).
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
Caso de uso
Modelado de clases
Definición de estructuras jerárquicas
Definición de temas y subsistemas
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.
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.
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.
Las actividades se encadenan en una mini cascada con un alcance limitado por los
objetivos de la iteración
19
Cada iteración comprende:
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.
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.
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?
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.
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:
21
Una planificación preliminar de iteraciones.
Fase de elaboración
22
La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de Vida.
acuerdo sobre:
Fase de desarrollo
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).
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.
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:
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.
24
La fase de transición cubre el período durante el cual el producto se convierte en la versión
beta.
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:
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.
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
27
2. Proceso de análisis para el desarrollo de sistemas de información
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”.
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.
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.
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.
Características de la Extensión
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.
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:
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.
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:
2. Identificación de funciones.
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.
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.
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
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.
Clases
38
A continuación, se explica en qué consiste cada una de las clases que conforman el
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.
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.
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.
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
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.
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:
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:
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:
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:
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.
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:
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:
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):
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
Modelos
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
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.
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.
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
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.
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:
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.
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.
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
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.
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:
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.
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:
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:
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:
Tabla 1
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.
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.
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.
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.
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
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
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