Este documento presenta una propuesta para la estructura de la fase de diseño de sistemas para el desarrollo de un sistema de información. Describe la arquitectura del sistema, incluyendo el propósito, objetivos y restricciones del diseño, la arquitectura lógica dividida en subsistemas, y la arquitectura física asignando componentes a hardware. También explica cómo diseñar cada subsistema con una vista de casos de uso, modelo de datos y especificación de casos de uso.

1. Instituto Universitario Politécnico Santiago Mariño
Sede Mérida
Escuela de Ingeniería de Sistemas
Asignatura: Sistemas de Información
Diseño de Sistemas
Presentación
Profesor: Luis Eladio Porras Camargo

2. Introducción
Esta presentación propone la estructura que podría llevar la fase de diseño de
sistemas para el desarrollo de un sistema de información.
Entre los objetivos que persigue esta propuesta se encuentran:
1. Describir todos los detalles del diseño de la arquitectura del sistema o aplicación
y de todos los componentes que la conforman.
2. Proporcionar todos los detalles técnicos requeridos para programar o producir
cada uno de los componentes de software de la aplicación o sistema.
3. Servir de insumo para la planificación y ejecución de las pruebas de unidad,
integración y aceptación que se realizará en la fase de Pruebas al sistema.
4. Servir como material de guía de aprendizaje para el estudiante, proporcionando
la información necesaria de cómo una solución ha sido diseñada y como va a ser
implementada.

3. Arquitectura del Sistema

4. Arquitectura del Sistema

5. Consiste en realizar una breve descripción del sistema, su ámbito
o contexto, sus características más relevantes, los procesos o
funciones principales, así como sus entradas y salidas más
importantes, sin incluir detalles de implementación. En forma
opcional, podría incluirse un diagrama de contexto o general
del sistema que muestre los componentes principales del
sistema y los sistemas externos que interactúan con él,
además de los flujos de datos que entran y salen del mismo.
Arquitectura del Sistema.
1. Propósito del sistema

6. Arquitectura del Sistema.
1. Propósito del sistema. Ejemplo
“El subsistema de Reservas es uno de los sistemas informáticos de la cadena hotelera KMG, cuyo propósito fundamental es
mantener en forma centralizada y unificada todas las reservas que se realizan en todos sus hoteles afiliados. Este
subsistema permitirá que todos los clientes de la empresa puedan realizar todas sus actividades por Internet y
especialmente sus reservas. Así mismo, los recepcionistas en cada uno de los hoteles operarán utilizando la misma interfaz
de usuario, una vez que un cliente llegue al hotel para hacer su check-in o decida modificar o cancelar una reservación o se
retire del hotel haciendo su respectivo check-out.
Este subsistema deberá ser capaz de apoyar todos los procesos y actividades para la reserva de habitaciones, entre ellos:
• El registro de una reserva realizada por un cliente o el recepcionista del hotel.
• La toma de una reserva (check-in) por parte de un cliente y la asignación de una habitación al nuevo huésped.
• Sugerencia de otros hoteles de la cadena cuando no existan habitaciones disponibles en el hotel que un cliente desea
reservar.
• La modificación o cancelación de una reserva previamente registrada.
• La notificación al cliente para confirmar una reserva cuando se han realizado cambios en la misma.
• La confirmación de una reserva mediante una notificación al cliente bien sea por email, fax, celular o beeper.
• La detección de reservas caducadas o reservas no tomadas.
• El cálculo de una comisión por penalización de aquellos clientes que no cancelaron a tiempo una reserva.
• La notificación al sistema de facturación para que éste realice la apertura de una cuenta a fin de registrar los consumos
realizados por sus huéspedes.
El subsistema tendrá como entrada:
• La información personal de sus clientes
• Los datos de una reserva, la cual será capturada a través de un formulario
El subsistema deberá producir la siguiente información como salida:
• El mensaje de confirmación de una reserva
• La factura o recibo de consumo de un cliente
• La comisión por penalización de una reserva no cancelada
• Información estadística de reservas tomadas, modificadas, canceladas y caducadas.

7. Describe los principales objetivos, limitaciones o restricciones que tienen un
gran impacto en el diseño del sistema.
Una gran mayoría de estos objetivos y restricciones lo determinan:
• La infraestructura tecnológica que posea la organización donde será
instalado este sistema, por ejemplo: manejador de base de datos a utilizar,
características mínimas que deben poseer los computadores a ser
instalados, características de la red que comunicará estos computadores y
el protocolo usado, etc.
• El software que será utilizado para la construcción del sistema y el
ambiente operativo donde éste será ejecutado.
• La reutilización de componentes de software existentes en la organización.
• Los requisitos de interfaz de usuario que se le impondrán al sistema.
• Los requisitos de desempeño, seguridad, confiabilidad y calidad impuestos
al sistema.
• El uso de estándares y normativas que deben ser tomadas en cuenta para
el desarrollo del sistema, entre otros.
Arquitectura del Sistema.
2. Objetivos y restricciones del diseño

8. A continuación se muestra un ejemplo de los objetivos y restricciones que se le imponen a un sistema, en
nuestro caso continuaremos con el subsistema de Reservas.
“La gerencia general de la cadena hotelera KMG desea mantener el control de todas las reservas que se hacen
en los distintos hoteles afiliados a su cadena. La empresa tiene como política no realizar reservas por
encima de su disponibilidad (overbooking). En este sentido, el sistema o recepcionista debería estar en
capacidad de sugerir a los clientes otros hoteles de la cadena, cuando no exista disponibilidad de
habitaciones en el hotel deseado.
Por otra parte, el sistema deberá permitir que las actividades para el registro, modificación, eliminación y
consulta de una reserva efectuada por un cliente o recepcionista pueda llevarse a cabo a través de la web.
Así mismo, deben proveerse los mecanismos para que las agencias de viajes puedan operar con el sistema,
mediante el uso de Web Services.
Debido a que los procesos de reserva, check-in y check-out presentan altas exigencias de desempeño, donde
las reservas por Internet deben realizarse en menos de 5 segundos, una vez llenado el formulario por
parte del cliente. Así mismo, el tiempo de respuesta para la realización de una reserva debe ser menor a 3
minutos cuando el cliente la realiza directamente por teléfono o en la recepción del hotel. De igual
manera, el tiempo de respuesta con las agencias de viajes para realizar una reserva debe ser de al menos 5
segundos.
Además, se desea reutilizar un sistema de facturación existente en la empresa, a fin de poder utilizar los
servicios que ofrece dicho sistema.
El sistema requerido deberá ejecutarse bajo la plataforma Microsoft Windows. Este podría utilizar como
navegador el Internet Explorer o algún navegador de software libre como el Mozilla Firefox. El sistema
utilizará el protocolo estándar de comunicación HTTP a través del canal de comunicación TCP/IP. Por otra
parte, el desarrollo de la interfaz gráfica se realizará en forma sencilla utilizando un editor HTML con
manejo de Forms, empleando el lenguaje de programación PHP para generar el contenido dinámico de las
páginas web y de la programación de la lógica de la aplicación.”
Arquitectura del Sistema.
2. Objetivos y restricciones del diseño. Ejemplo

9. Arquitectura del Sistema.
3. Arquitectura lógica
Aquí se presenta la estructura lógica global de la arquitectura del sistema, de
acuerdo a un patrón arquitectónico elegido. La arquitectura del sistema
se representa a través de un gráfico que muestra como la funcionalidad
del sistema ha sido dividida en subsistemas o componentes.
Una breve descripción de la asignación de la funcionalidad de cada
subsistema debe ser incluida, así como el detalle de los servicios
proporcionados por cada subsistema. Se debe incluir también, una
descripción del estilo o patrón arquitectónico utilizado para dar forma a la
arquitectura del sistema.
Uno de los patrones arquitectónicos más usados en la actualidad para el
desarrollo de aplicaciones de porte empresarial es el denominado
“arquitectura de 3 o más capas”. Este estilo arquitectural separa
lógicamente y en algunos casos físicamente, los aspectos de presentación
de la aplicación (interfaz de usuario), la lógica del negocios
(automatización del flujo trabajo) y la gestión de los datos (bases de
datos), tal como se muestra en la siguiente figura.

10. Arquitectura del Sistema.
3. Arquitectura lógica
La capa de presentación es la encargada de manejar
la interfaz del usuario, controlando la captura y
presentación de los datos y recibiendo los
eventos accionados por lo usuarios a través de
la interfaz. Esta capa se comunica únicamente
con la capa de lógica de negocios.
La capa de lógica de negocios tiene la
responsabilidad de manejar la funcionalidad
del sistema, implementando a través de
objetos de negocio (programas) las reglas de
negocio que deben cumplirse. Esta capa se
comunica con la capa de presentación para
recibir solicitudes y presentar resultados y con
la capa de datos, para solicitar al gestor de base
de datos que almacene o recupere datos.
La capa de datos (llamada en algunos casos capa de
persistencia) es la responsable del
almacenamiento y recuperación de los datos.
Se comunica únicamente con la capa de lógica
de negocios.

11. Arquitectura del Sistema.
3. Arquitectura lógica. Ejemplo
Un ejemplo de la descripción y estructura de la arquitectura para un
sistema de video juegos se muestra a continuación:
“El sistema empleará el estilo arquitectónico de capas y será organizado
en tres capas: la capa de interfaz, la capa de la aplicación y la capa de
almacenamiento.
La capa de interfaz contendrá la interfaz gráfica del usuario que le
permitirá a los usuarios interactuar con el sistema. Esta capa será
implementada usando el Java Media Framework y el Java Swing Package,
conteniendo el video player y todos sus menús.
La capa de la aplicación contendrá la lógica y reglas para almacenar datos
en la capa de la base de datos y también para recuperar éstos de
acuerdo con las necesidades de las usuario.
Finalmente, la capa de almacenamiento guardará los datos requeridos
por el sistema.
El estilo arquitectónico de tres-capas será usado porque no sólo separa la
interfaz del usuario de los datos almacenados, sino que también, provee
una capa de lógica de la aplicación. La capa de aplicación provee una
capa intermedia que permite que los datos almacenados en la base de
datos y los componentes GUI están débilmente acoplados. Esta
separación lógica permite que una capa pueda ser modificada sin alterar
el resto de las capas o introducir pequeños cambios en alguna de ellas.
Por ejemplo, la capa de la aplicación podría ser modificada si hay
cualquier cambio en el formato de los archivos de datos y sus atributos,
sin que esto afecte la capa de interfaz. Esta capa intermedia hace
posible que este sistema esconda a sus usuarios, la complejidad
inherente del procesamiento de sus datos y haga posible que éste
sistema sea mucho más fácil de mantener y de reutilizar.”

12. Arquitectura del Sistema.
3. Arquitectura Física
En esta etapa se describe la topología del sistema, mostrando como serán
asignados en forma física los diferentes subsistemas o componentes
(software) a los diferentes equipos de computación (hardware). Para
describir la asignación del software al hardware utilice los diagramas de
despliegue y de componentes de UML.
Ejemplo: la arquitectura
física del sistema de Video
Juegos

13. Arquitectura del Sistema.
3. Arquitectura Física. Ejemplo
Continuando con el ejemplo del
subsistema de Reservas:
“Esta arquitectura física
considera la distribución de la
aplicación en cuatro tipos de
nodos: Cliente, Recepción,
Server, LegacyServer.
El primer nodo representa a las
estaciones de trabajo de los
usuarios finales.
El nodo Recepción corresponde
a la estación de trabajo ubicada
en la recepción del hotel.
El nodo Server representa al
equipo en donde correrá el
servidor web y la aplicación del
Subsistema de Reservas.
El último nodo, LegacyServer,
representa a aquella
infraestructura informática
necesaria para correr los
sistemas legados, entre ellos el
sistema de facturación.”

14. Arquitectura del Sistema.
3. Arquitectura Física. Ejemplo
Se puede incluir adicionalmente bajo esta arquitectura, un diagrama de
despliegue en UML, que muestre como los componentes de software
(servicios, procesos, etc.) son distribuidos sobre el hardware, tal como se
indica en la siguiente figura

15. Diseño de los subsistemas
En esta etapa se describe cada uno de los subsistemas que
han sido determinados en la arquitectura lógica del
sistema. Para ello, se incluye una descripción de la
funcionalidad del subsistema a través de una vista de casos
de uso. Una descripción del modelo de datos que soporta,
mostrados mediante una vista de datos y la inclusión de
una serie de elementos de modelado que describen como
los casos de uso del sistema pueden ser realizados.

16. Diseño de los subsistemas.
1. Vista de uso del subsistema.
Esta vista muestra la funcionalidad del sistema como es
percibida por los usuarios finales, analista y encargados de
las pruebas.
Para esta vista se utilizan los diagramas de casos de uso de
UML, los cuales contienen los casos de uso más
representativos de este subsistema. Cuando los casos de
uso contenidos en estos diagramas son numerosos, estos
podrían ser agrupados de forma funcional utilizando los
paquetes (carpetas) de UML. Esta organización crea una
jerarquía de diagramas de casos de uso, los cuales por
razones de claridad, no deberían pasar de tres niveles.

17. Diseño de los subsistemas.
1. Vista de uso del subsistema. Ejemplo
Un ejemplo de
la vista de
casos de uso
para el
subsistema de
Reservas se
muestra en la
siguiente figura

18. Diseño de los subsistemas.
1. Vista de uso del subsistema. Ejemplo
Un ejemplo de la Vista de casos de uso para un sistema de Video Club podría ser:

19. Diseño de los subsistemas.
2. Vista de datos del subsistema
Esta vista muestra el subconjunto de clases de entidad que serán
utilizadas por este subsistema. Las clases de entidad se refieren a
aquellas clases que van a guardar datos en forma persistente a
través de un manejador de base de datos. En otras palabras,
representa la porción del modelo conceptual de datos que será
utilizada por este subsistema.
Para la construcción de esta vista se utilizan los diagramas de clases
de UML. En estos diagramas se muestran conceptos (objetos),
asociaciones entre conceptos (relaciones) y atributos de
conceptos (atributos).

20. Diseño de los subsistemas.
2. Vista de datos del subsistema. Ejemplo
Un ejemplo de la vista de datos relacionada con el sistema de Reservas sería

21. Diseño de los subsistemas.
3. Especificación de los casos de usos
En esta etapa se detalla como cada uno de los casos de uso
que pertenecen a este subsistema van a ser realizados. La
realización de un caso de uso permite expresar como el
comportamiento definido en un escenario, es distribuido en
función de los objetos o clases que colaboran entre si para
realizar una operación.

22. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
Para describir la realización de un caso de uso será necesario: una
descripción textual de los pasos realizados en ese caso de uso
(escenario), un diagrama de las clases que participan en ese
caso de uso y un diagrama de secuencia o de colaboración que
muestra como la clases interactúan. De manera opcional, se
puede mostrar los componentes de la interfaz gráfica de
usuario (pantallas, vistas o formularios) involucrados en la
realización del caso de uso y un diagrama de navegación a
través de la interfaz de usuario.

23. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
El primer paso para especificar un caso de uso consiste en
presentar el escenario del caso de uso, que mediante una
descripción textual muestra el flujo de eventos que ocurre
entre uno o más actores y el sistema, incorporando detalles
de la interfaz, sus atributos y nombres de las clases
utilizadas en la realización del caso de uso.

24. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso. Ejemplo
El escenario del caso de uso hacer reserva
se muestra a continuación:

25. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso. Ejemplo
El escenario de caso de
uso para un sistema de
Punto de Venta se
presenta en la siguiente
figura

26. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
El segundo paso para especificar un caso de uso consiste en presentar
diagrama de clases de diseño del caso de uso. Un diagrama de clases en
UML se presenta aquí, para mostrar las clases de diseño de software
que colaboran en la realización del caso de uso. Este diagrama muestra
la especificación de las clases software que intervienen en este caso de
uso, presentando sus atributos, métodos, asociaciones, interfaces y
operaciones, navegabilidad y dependencias.
Los tipos de clases de diseño que son incluidas en estos diagramas son las
clases de entidad, de interfaz y de control, denominadas así en el
Proceso Unificado (RUP). Las clases de identidad representan a aquellos
elementos del mundo real o conceptual a los que se les guardará
información perdurable en el sistema. Las clases de interfaz modelan la
interacción entre el sistema y sus diferentes usuarios, asociadas con la
entrada de datos y salida de información. Las clases de control o activas,
son utilizadas para controlar el flujo de operaciones que debe realizar el
sistema en respuesta a los eventos generados por un actor.
En algunos casos, se construye básicamente un Modelo de Diseño de
Objetos que corresponde a la capa del dominio o lógica de la aplicación,
el cual contiene las clases software que manejaran la lógica del negocio
y cuyos nombres son derivados de los conceptos del negocio.

27. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
El siguiente ejemplo ilustra un diagrama de clases de diseño para un sistema de
Punto de Venta

28. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
El tercer paso para especificar un caso de uso consiste en presentar un
diagrama de secuencia de UML, el cual se coloca aquí para
complementar la descripción textual (escenario) de un caso de uso.
Pudiera ser un elemento opcional cuando la realización del caso de uso
sea sencilla e involucre pocas clases o pocos métodos.
Un diagrama de secuencia se usa principalmente para mostrar en que
orden interactúan los objetos o clases en la realización de un caso de
uso, así como la secuencia de mensajes intercambiados por estos, para
llevar a cabo la funcionalidad descrita por el escenario.

29. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
La siguiente figura
muestra el
diagrama de
secuencia para el
caso de uso
procesar venta.
Este diagrama usa
estereotipos para
indicar los tipos de
objetos que
interactúan, por
ejemplo: los de
interfaz con el
estereotipo
<<UI>>, los de
control con el
estereotipo
<<controlador>> y
el resto de ellos,
sin estereotipo,
que hacen
referencia a los
objetos de
entidad.

30. Un ejemplo que hace uso de clases genéricas de software, creadas para el manejo de la interfaz, de la
lógica de la aplicación y del acceso a datos es mostrado en el siguiente diagrama de secuencia del
caso de uso registrar usuario de un sistema de Reservaciones Aéreas
Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso

31. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
El cuarto paso para especificar un caso de uso consiste en
mostrar los diferentes componentes de la interfaz gráfica
del usuario (pantallas, ventanas, formularios o vistas)
involucrados en la realización de este caso de uso.
Adicionalmente se podría incluir aquí, los formatos de
impresión asociados a este caso de uso o en general al
subsistema asociado.

32. Para el caso del subsistema de Reservas, los
componentes de la interfaz que permite
ingresar los datos de una reserva son
mostrados en las siguientes figuras.
Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso

33. Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso
El quinto paso para especificar un caso de uso es opcional
podría ser utilizada sólo cuando la realización del caso de
uso tenga cierta navegación compleja que sea necesario
describirla. En este caso, se utilizaría un diagrama de
estados de UML para mostrar dicha navegabilidad.

34. La siguiente figura
presenta un posible
diagrama de
navegación para el
caso de uso hacer
reserva, donde se
muestran los
diferentes
componentes de la
interfaz de usuario
presentes en la
realización de este
caso de uso.
Diseño de los subsistemas.
3. Especificación de los casos de usos.
a. Como especificar un caso de uso

35. Diseño de la Base de Datos
Esta etapa contiene los diseños de la base de datos que
determinan como los datos que van a ser incluidos en la
base de datos, están lógica y físicamente organizados. Para
ello, el diseño de la base de datos se establece en dos
niveles de detalle.
El primer nivel muestra el modelo conceptual de la base de
datos, representado a través de uno o más diagramas de
clases en UML o diagramas entidad-asociación, el cual es
independiente del entorno tecnológico utilizado. El
segundo nivel presenta el modelo implementable de la
base de datos, descrito mediante un diagrama físico de la
base datos que depende directamente del manejador de
base de datos utilizado.

36. Diseño de la base de Datos
1. Esquema conceptual de la BD
En esta etapa se presenta el esquema conceptual de la base de datos del sistema. Este
esquema es el producto de la integración de los diferentes diagramas (de clases en UML
o de entidad-asociación) de cada proceso de negocio o subsistema que haya sido
establecido. Los datos contenidos en este esquema son derivados directamente de los
requisitos funcionales del sistema.
Un diagrama de
clases en UML se
muestra aquí,
para representar
el modelo
conceptual de
datos del
subsistema de
Reservas.

37. Diseño de la base de Datos
2. Esquema implementable de la BD
En esta etapa se presenta el resultado de la conversión del esquema conceptual de la
base de datos a un esquema implementable (en nuestro caso, el modelo relacional),
donde se incluyen detalles de implementación física de acuerdo al manejador de base de
datos a usar.
La siguiente
figura muestra el
esquema
implementable
de la base de
datos del sistema
de Reservas, el
cual utiliza el
modelo
relacional y que
será ejecutado
sobre el gestor
de base de datos
Microsoft Access

38. Diseño de la base de Datos
3. Diccionario de datos
Este etapa es opcional. Si el contenido del diccionario de datos es
muy grande se recomienda generarlo en un documento aparte
con este contenido, el cual podría denominarse Modelo de Datos
del Sistema o Diccionario de Datos del Sistema.
El diccionario de datos debe presentar un listado organizado de
todas las estructuras de almacenamiento de la base de datos.
Describiendo cada una de las tablas que la componen y sus
campos asociados. Adicionalmente, cada campo es identificado
por un nombre de dato, descripción, tipo de dato, longitud y el
posible dominio de valores que podría tomar.