3 - Diseño

EL MERCADO
Programa: ANÁLISIS Y DESARROLLO DE SISTEMAS DE

INFORMACIÓN
Duración estimada de estudio (horas): 3 horas
Estructura de contenidos
Mapa Conceptual............................................................................2
Introducción..................................................................................3
1. Definición..................................................................................4
2. Tipos de mercado.......................................................................5
2.1. Según su ubicación geográfica..............................................5
2.2. Según los tipos de cliente....................................................6
2.3. Según el tipo de producto....................................................6
2.4. Según el tipo de competencia...............................................7
3. Segmentación del mercado..........................................................7
3.1. Características Generales.....................................................8
3.1.1. Homogéneo..............................................................8
3.1.2. Heterogéneo.............................................................8
3.1.3. Viabilidad Monetaria...................................................9
3.1.4. Capacidad Operativa..................................................9
3.2. Criterios de Segmentación................................................. 10
3.2.1. Segmentación por criterios geográficos....................... 10
3.2.2. Segmentación por criterios
socioeconómico-demográficos................................... 10
3.2.3. Segmentación por criterios psicográficos..................... 10
relacionados con el producto..................................... 11
Diagrama Criterios Modernos de segmentación...................... 12
3.3. Proceso de segmentación................................................... 13
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

El mercado
Mapa Conceptual
El mercado.
2
El mercado
Introducción
El término mercado se ha utilizado en los diversos entornos a través de

la historia para intercambiar, comerciar o mercadear bienes o servicios
entre diferentes grupos de personas.
El mercado es un concepto y actividad que ha estado

presentes desde la antigüedad donde las tribus lo
utilizaban como medio de supervivencia para satisfacer las
necesidades básicas y poseer cosas que ellos no producían,
a través del tiempo este ha evolucionado y de una forma
mas organizada sigue con la satisfacción de las necesidades
básicas, las secundarias y algunas triviales creadas por la
sociedad de consumo.
Siempre se ha asociado el
término mercado a diferentes
aspectos y actividades, algunos
no tan acertados, entre ellos uno
de los mas utilizados es el lugar físico
donde se realizan transacciones comerciales,
sin embargo la globalización y el aumento continuo de
la competitividad son los motores que han impulsado
el avance e innovación permanente en todo lo que a
mercado se refiere, para llegar a determinar que no es
un espacio necesariamente físico, que logra conjugan la
oferta y la demanda.
El éxito y logro de cualquier emprendimiento o proyecto

está fundamentado en un muy buen estudio y manejo
del mercado, ya que este es la fuente para satisfacer las
necesidades de los clientes que deben estar perfectamente
definidas teniendo en cuenta además que los bienes y
servicios deben estar pensados desde el requerimiento del
cliente.
3
El mercado
1. Definición
Según el Diccionario de Marketing, de Cultural S.A., el mercado son “todos

los consumidores potenciales que comparten una determinada necesidad
o deseo y que pueden estar inclinados a ser capaces de participar en un
intercambio, en orden a satisfacer esa necesidad o deseo”1.
En la antigüedad este intercambio comercial se daba a través del trueque,

posteriormente con la aparición del dinero se generaron espacios de
encuentro, el ejemplo típico son las plazas o ferias, con la evolución de
los procesos de negociación se establecieron reglas que dieron lugar a
diferentes empresas de acuerdo con las características de los productos y
procesos para dar respuesta a esas necesidades.
De manera general se puede definir el concepto de mercado

como la relación entre la oferta y la demanda, donde la
oferta está determinada por quienes suministran los
productos y servicios y la demanda corresponde al grupo
de consumidores con una necesidad particular.
Los esfuerzos principales cuando se habla

del mercado están encaminados al
reconocimiento de las características de
los compradores reales o potenciales de
un producto o servicio, para determinar
las acciones a seguir que permitan dar
respuestas a esas necesidades.
1 Diccionario de Marketing. Cultural S.A.
4
El mercado
2. Tipos de mercado
La categorización del mercado se hace necesaria en la medida en que

evolucionan las empresas, los productos y servicios. Sin embargo existen
diferentes formas de clasificarlas y a continuación se presentan algunas
de ellas, basadas en características particulares.
2.1. Según su ubicación geográfica
Corresponde a uno o más

Mercado Internacional paises consumidores del
producto o servicio
Abarca todo el territorio

Mercado Nacional Nacional
Corresponde a una zona

Mercado Regional geográfica determinada
De Intercambio Se desarrolla en áreas de

Comercial al Mayoreo influencia de las empresas
Se desarrolla alrededor de
Mercado Metropolitano
una ciudad
Corresponde a un
Mercado Local establecimiento o centro
comercial
5
El mercado
2.2. Según los tipos de cliente
Mercado del Consumidor

Los bienes y servicios se adquieren para uso personal
Mercado del Productor o Industrial

Se adquieren productos, materias primas y servicios para la
producción de nuevos bienes o servicios
Mercado del Revendedor

$ Personas o empresas que revenden bienes o servicio de otras
empresas
Mercado del Gobierno

Conformado por instituciones del sector público
2.3. Según el tipo de producto
Mercado de Productos o Bienes Mercado de Servicios
Corresponde a productos o bienes Actividades que se realizan para

producidos para su venta satisfacer la necesidad específica
6
El mercado
2.4. Según el tipo de competencia
Mercado de Competencia Perfecta

Existen muchos vendedores y compradores para productos con características
similares, no hay manipulación ni control de los precios
Mercado de Competencia Imperfecta

Al menos un vendedor es de tamaño considerable para afectar los precios
Mercado Monopolista
Solo hay una empresa que comercializa ese producto
Mercado de Monopsonio
Los compradores ejercen predominio para regular la demanda
3. Segmentación del mercado
La segmentación de mercados es un proceso que consiste en la división de

un mercado en grupos, de acuerdo con la identificación y caracterización
de los consumidores y permite identificar las estrategias de acceso a
esos diferentes grupos con el fin de suplir sus necesidades y que puedan
adquirir un bien o servicio.
La segmentación permite identificar aspectos comunes entre los

componentes del mercado objetivo, ya que se logran identificar deseos,
gustos y necesidades, entre otros aspectos.
Al segmentar adecuadamente el mercado se puede identificar los

requerimientos y necesidades del sector, para así comprender el
comportamiento del grupo de consumidores y mejorar los aspectos
comunicacionales y de retención de clientes.
En general se aplican técnicas estadísticas y una vez caracterizado se

seleccionan los segmentos a los que se dirigirán los productos y servicios
ofertados o se identificarán las oportunidades de negocio.
Adicionalmente, se encuentran, al interior de los grupos segmentados, los

nichos de mercado que son concentraciones de mercado con características
iguales muy específicas.
7
El mercado
3.1. Características Generales
Los segmentos o subgrupos resultantes deben contar con las siguientes

características:
3.1.1. Homogéneo.
Al interior de cada segmento el grupo de consumidores debe compartir

características muy similares en cuanto a sus necesidades, ubicación,
poder adquisitivo y comportamientos de compra.
3.1.2. Heterogéneo.
Cada segmento debe tener consumidores visiblemente distintos en cuanto

a sus necesidades y tendencias de compra entre otros.
8
El mercado
3.1.3. Viabilidad Monetaria.
Se requiere que el segmento tenga las dimensiones que permitan

garantizar su rentabilidad pro la cantidad de clientes reales o potenciales.
3.1.4. Capacidad Operativa.
Considerar las características demográficas que faciliten su ubicación y

selección de la estrategia comercial.
9
El mercado
3.2. Criterios de Segmentación
Luego de decidir cuál será el segmento al que se dirigirán todas las

estrategias de mercadeo, es necesario tener en cuenta los elementos
fundamentales en la consecución de los objetivos corporativos,
esencialmente los comerciales. Es fundamental realizar una elección
eficiente de la porción que se escogerá; para esto, es necesario tener en
cuenta las siguientes definiciones:

geográficos
Los elementos que miden los segmentos

geográficos son: países, provincias, municipios,
ciudades, etc.
Las variables que intervienen para el análisis

de aspectos en el orden geográfico son
cuantificables y de gran operatividad.

socioeconómico-demográficos
Dentro de este contexto de segmentación,

se encuentran aspectos tales como el
sexo, la edad, el estado civil, la familia,
y paralelamente encontramos variables
socioeconómicas como la ocupación, la
educación y los ingresos, entre otros.
El perfil que se encarga de analizar los comportamientos y preferencias de

los consumidores tiene relación con los aspectos socioeconómicos.
Con el fin de fraccionar el mercado, es común que se usen varios criterios

para maximizar la calidad de la segmentación.
3.2.3. Segmentación por criterios psicográficos
Al interior de este aspecto, se deben tener en cuenta la personalidad, el
10
El mercado
estilo de vida, las actividades, las actitudes,

las opiniones y los valores.
Este criterio de la segmentación alcanza

una explicación clara acerca de las personas
con un mismo perfil sociodemográfico que
posean una conducta de compra distinta;
para la validez de este criterio es necesario
analizar los siguientes parámetros:
• Se compone de una compleja cuantificación.
• Es complicado identificar las necesidades básicas de los consumidores.
• Las porciones de consumidores resultantes pueden ser de difícil acceso.

relacionados con el producto
Este tipo de fraccionamiento del mercado

permite observar aspectos tales como el
tipo de establecimiento, las horas en las que
el cliente compra, frecuencia de compra y
lealtad a la marca.
La segmentación que se encarga de

establecer aspectos claros frente al producto es la manera más directa
para el análisis del mercado. Los parámetros son fácilmente cuantificables
y las porciones de mercado suelen ser tácticos de alta accesibilidad.
Aun cuando existen diferentes factores a considerar para realizar la

segmentación, a continuación se presentan algunas de las variables
con las que Daniel Yankelovich2 propone la realización del método que
denomina Análisis de Segmentación, las cuales pueden ilustrar los criterios
a considerar.
2 Yankelovich Daniel, Nuevos criterios para segmentar los mercados. Biblioteca

Harvard de Administración de Empresas.
11
El mercado
Diagrama Criterios Modernos de segmentación (YANKELOVICH)
Criterios Modernos de segmentación (YANKELOVICH)
1. Productos de prestigio
2. Productos para adultos
3. Productos para un nivel
Factores relacionados
con el producto 4. Productos de ansiedad
5. Demanda hedonista
6. Demanda funcional
8. Edad
9. Sexo
10. Tamaño de la familia
11. Nivel de ingresos
12. Ocupación
13. Educación a nivel cultural
15. Política
16. Raza
17. Nacionalidad
18. Clase social
19. Clima
20. Ambiente y costumbres
21. Necesidades
22. Actitudes
23. Actividades
24. Intereses
25. Opiniones
26. Conveniencia
27. Funcionalidad
Factores relacionados caracteristicas

con la situación 29. Indice de consumo
30. Lealtad de la marca
31. Situación de compra
32. Segmentación por valores

33. Por conceptos estéticos
34. Susceptibilidad de cambio
Factores modernos
36. Por desarrollo tecnológico
37. Por conocimiento y
entendimiento del producto
12
El mercado
3.3. Proceso de segmentación.
Los pasos a considerar en el proceso de segmentación de un mercado

son:
a. Seleccionar un mercado o categoría de producto.

Se debe identificar el mercado global que existe para el producto o servicio
a ofrecer.
b. Seleccionar la base para segmentar el mercado.

Al seleccionar la o las bases para segmentar el mercado es importante
que se contemplen los criterios de rentabilidad, que sean fácilmente
identificables los segmentos y respondan a algún tipo de medición,
que puedan ser accedidos sin restricciones y por último que tengan un
comportamiento mercantil similar.
c. Seleccionar las variables de la segmentación.

Se deben seleccionar los factores de segmentación a utilizar, los cuales
determinarán las variables que se considerarán.
d. Perfilar y analizar los segmentos.

Preferiblemente deben incluirse el tamaño, crecimiento esperado, la
frecuencia de compra y el potencial a largo plazo.
Seleccionar Aplicar el
Mercado proceso para
Global obtener
segmentos
Seleccionar
base para
segmentar
Analizar los
segmentos
13
FICHAS TÉCNICAS
INTRODUCCIÓN
La elaboración de fichas técnicas, permite que se pueda tener a manera

de resumen una descripción detallada de los equipos o hardware que
se utilizara en el desarrollo del sistema de información y/o de las
necesidades informáticas de la organización para la implementación del
proyecto software.
El contenido de una ficha técnica cambia dependiendo del producto, servicio,

entidad o empresa para la cual se desarrollara el proyecto, pero en general
contiene datos tales como: nombre del producto, características físicas,
el modo de uso o elaboración, propiedades distintivas y especificaciones
técnicas.
Es importante que una ficha técnica tenga una buena redacción ya que
garantiza la satisfacción del cliente, proveedor o consumidor, especialmente
en los casos donde utilizar incorrectamente un producto trasciende a
daños personales, materiales o responsabilidades civiles o penales.
El desarrollo de una ficha técnica, casi siempre se guía por documentos,

plantillas o formatos estandarizados en las organizaciones o entidades
donde se va a desarrollar.
Es importante realizar las fichas técnicas de los equipos hardware que se

utilizarán en el desarrollo de un proyecto, ya que así se están definiendo
las características que deben poseer los equipos para el correcto
funcionamiento del software, adicionalmente a futuro es información
relevante sobre el estado actual, características, estado de conservación,
operatividad y las necesidades de mantenimiento y reposición de los
equipos.

Fichas Técnicas
1. FICHAS TÉCNICAS
En el desarrollo de un proyecto software es necesario contar con
computadores personales, impresoras, servidores, y de acuerdo a la
arquitectura tecnológica de hardware determinada, se necesita elaborar
una ficha técnica por cada equipo que se requiera, para determinar sus
características técnicas.
Aun cuando cada organización puede diseñar sus propias fichas técnicas,
de acuerdo con las diferentes áreas que las manipulen, existen algunos
componentes mínimos que deben poseer:
• Nombre del dispositivo

• Solicitante: puede ser un área o proyecto.
• Características físicas
• Especificaciones técnicas o propiedades distintivas: en caso de ser
software se debe proveer además del nombre, la versión y fabricante
• Garantía
A continuación se presentan algunos ejemplos, utilizando un formato
utilizado en algunos centros de formación, note que existen variaciones
dependiendo del tipo de producto a describir.
Por ejemplo para un computador de escritorio la ficha técnica podría ser

la siguiente:
Ejemplo: Ficha técnica computador escritorio
FICHA TÉCNICA COMPUTADOR ESCRITORIO
1. NOMBRE DEL DISPOSITIVO:
Computador de escritorio (Para aplicaciones de uso general)
2. SOLUCIÓN- PROYECTO:
Solución informática para proyecto de gestión de historias clínicas.
3. ESPECIFICACIONES MÍNIMAS REQUERIDAS
Las características mínimas obligatorias para cada uno de los dispositivos

son:
2
Fichas Técnicas
3.1 CARACTERISTICAS FÍSICAS
ÍTEM CANTIDAD COMPONENTE

1 1 Torre con fuente de poder
2 1 Monitor plano LCD de 15” con punto de conexión a guaya
3 1 Mouse USB óptico de dos botones y scroll
4 1 Teclado en español USB
5 1 Cámara web 2 Mpixeles con conexión al puerto USB
Candado externo mecánico para evitar el ingreso a la torre del compu-
6 1
tador de escritorio
7 1 Guaya para el monitor
8 --- Cables de poder
9 --- Cable de conexión para el monitor
10 --- Manuales del equipo
Medios físicos con drivers de los componentes del equipo para Win-
11 ---
dows 7
12 1 Pad Mouse ergonómico
3.2 ESPECIFICACIONES TÉCNICAS

1 1 Main board
Cualquiera de los siguientes procesadores:
2 1 - Procesador AMD Phenom
- Procesador Intel Core i3

3 1 Módulo de memoria RAM de 2 Gbytes
4 4 Slots de memoria RAM deben soportar 4 Gbytes de memoria RAM
5 1 Disco duro de 150 GBytes
6 1 Unidad óptica CD-ROM/DVD-ROM
7 4 Puertos USB 2.0
8 1 Puerto de video compatible con el monitor
Adaptador de red (Tarjeta de Red) 10/100/1000 Mbps, conector RJ-45
9 1
integrado, que soporte IEEE 802.1x
Adaptador inalámbrico (Tarjeta de red para conexiones inalámbricas)
con antena integrada, que soporte IEEE 802.11 b/g, WEP, WPA, IEEE
10 1 802.1x. Debe ir a un slot del computador. No se permiten que se
conecten de forma externa a puertos USB u otros puertos del com-
putador.
11 1 Sistema operativo Microsoft Windows 7 Home OEM
12 --- El computador debe estar certificado bajo la norma Energy Star
13 --- Alimentación 120 VAC
14 --- El monitor, torre, teclado y mouse deben ser de la misma marca
3
Fichas Técnicas

El fabricante de los equipos debe certificar que las partes que confor-
15 ---
man el equipo son interoperables y compatibles
3.3 GARANTÍA
ÍTEM CANTIDAD CARACTERÍSTICA

1 3 años garantía en sitio para el computador y todas sus partes
Ejemplo: Ficha Técnica Impresora:

FICHA TÉCNICA IMPRESORA
1. NOMBRE DEL DISPOSITIVO O SOLUCIÓN:
Impresora de gran formato

son:
2.1 CARATERISTICAS FÍSICAS

1 1 Impresora de gran formato
2 1 Alimentador hojas
3 1 Alimentador papel en rollo
4 1 Panel de control
5 2 Cartuchos tinta de color (instalado y repuesto)
6 2 Cartuchos tinta negra (instalado y repuesto)
CANTI-
ÍTEM COMPONENTE
DAD
1 --- Tecnología de impresión: Inyección térmica de tinta de color
2 --- Software y medios para la gestión de las impresoras de formato grande
3 --- Resolución de impresión 1200 dpi x 600 dpi
4 1 Memoria 30 GBytes
5 1 Disco duro 100 Gbytes
6 1 Cortador de papel automático
7 --- Tamaños soportados: A1, A2, A3, A4, pliego completo, medio pliego
8 1 Área de impresión 615 x 1608 mm
9 1 Puerto USB
10 1 Tarjeta de red 10/100 Mbps RJ-45
4
Fichas Técnicas
CANTI-
ÍTEM COMPONENTE
DAD
11 1 Software mantenimiento Impresora
12 1 Voltaje de alimentación 110 V
13 --- Cables de poder
14 --- Cables de conexión con el computador
15 --- Software y medios para la gestión de las impresoras de formato grande
16 --- Compatible con Windows XP, Windows Vista y Windows 7
17 --- Manual del equipo
2.3 GARANTÍA

1 3 años Garantía en sitio para la impresora y todas sus partes
Ejemplo: Ficha Técnica Servidor:
FICHA TÉCNICA SERVIDOR
1. NOMBRE DEL DISPOSITIVO O SOLUCIÓN:
Servidor
2. USO/FIN
VALOR
ÍTEM CARACTERÍSTICA
(DEBE SER DILIGENCIADO POR PARTE DEL CENTRO DE
FORMACIÓN)
1 Cantidad de usuarios estimados

2 Ubicación de los usuarios estimados
NOMBRE
VERSIÓN FABRICANTE
SOFTWARE
Software que va a ser instalado en el

3
servidor

son:
5
Fichas Técnicas
3.1 CARATERISTICAS FÍSICAS
ÍTEM CANTIDAD CARACTERISTICA

4 1 Servidor
ÍTEM CANTIDAD CARACTERISTICA

1 --- Tipo rack
2 X Unidades de rack
Cualquiera de los siguientes:
3 2 - Procesadores Quad-core Intel Xeon
- Procesadores Quad-core AMD Opteron

4 --- El computador debe estar certificado bajo la norma Energy Star
5 1 Memoria X GBytes expandible a X Gbytes
6 2 Disco duro X Gbytes extraíble en caliente
7 1 Unidad óptica lectura y escritura DVD/CD externa USB
8 2 Puertos USB 2.0
9 1 Controladora de arreglos de discos
10 2 Fuentes de poder
11 2 Tarjetas de red 100/1000 Mbps – RJ45
12 --- Manuales del equipo
Medios físicos con los controladores y drivers de los componentes del
13 ---
equipo para Windows server 2008
El fabricante debe certificar que las partes que conforman el equipo
14 ---
son interoperables y compatibles
3.3 GARANTÍA

1 3 años Garantía en sitio para el servidor y todas sus partes
6
CONSTRUIR EL PROTOTIPO DEL SISTEMA
MEDIANTE LAS INTERFACES DE CAPTURA,
PROCESO Y SALIDA DE DATOS.
Introducción 3
1. Principios de diseño de las Interfaces de usuario 4
2. Tipos de Interfaz de Usuario 4
2.1. Interfaces de Lenguaje natural 4
2.2. Interfaces de pregunta y respuesta 4
2.3. Interfaces con Menús 4
2.4. Interfaces con formularios 5
2.5. Interfaces de lenguaje de comandos 5
2.6. Interfaces graficas de usuarios (GUI) 5
3. El proceso de Diseño de la Interfaz de usuario 5
3.1. Análisis del usuario 6
3.2. Prototipo de la Interfaz de Usuario 6
3.3. Evaluación de la Interfaz de Usuario 6
4. Herramientas Software para Diseño de Interfaces 8
5. Ejemplos Diseño Interfaces Casos de Uso 10
RECURSOS BIBLIOGRÁFICOS 15
GLOSARIO 16

2
Mapa conceptual
Construir el prototipo del sistema mediante las interfaces
de captura, proceso y salida de datos.
FAVA - Formación en Ambientes Virtuales de Aprendizaje

SENA - Servicio Nacional de Aprendizaje
Diseño Interfaces
CONSTRUIR EL PROTOTIPO DEL SISTEMA MEDIANTE

LAS INTERFACES DE CAPTURA,
PROCESO Y SALIDA DE DATOS.
INTRODUCCIÓN
En el proceso general del diseño y desarrollo de software hay un elemento

muy importante que es el diseño de la interfaz de usuario. Las grandes
empresas contratan personas expertas para ello, pero en la mayoría a los
desarrolladores les toca asumir la responsabilidad de diseñar la interfaz de
usuario, así como del diseño del software que implementa la interfaz.
Un diseño cuidadoso de la interfaz de usuario es parte fundamental del

proceso de diseño general del software. Si un sistema software debe
alcanzar su potencial máximo, es fundamental que su interfaz de usuario
sea diseñada para ajustarse a las habilidades, experiencia y expectativas
de sus usuarios previstos.
Antes de iniciar el proceso de diseño de la interfaz de usuario, es bueno

hacernos las siguientes preguntas:
1 ¿Cómo debe interactuar el usuario con el sistema informático?

2 ¿Cómo se debe presentar la información del sistema informático al
usuario?
Una muy buena interfaz de usuario debe integra los dos elementos relacio-
nados en las preguntas, la interacción del usuario y la presentación de la
información.
3
Diseño Interfaces
1. Principios de diseño de las Interfaces de Usuario.
Principio Descripción
Familiaridad La interfaz debe utilizar términos y conceptos obtenidos de la

del usuario experiencia de las personas que más utilizan el sistema.
Siempre que sea posible, la interfaz debe ser uniforme en el
Uniformidad sentido de que las operaciones comparables se activen de la
misma forma.
Mínima El comportamiento del sistema no debe provocar sorpresa
Sorpresa a los usuarios
Recuperabilidad
La interfaz debe incluir mecanismos para permitir a los
usuarios recuperarse de los errores.
Guía de Cuando ocurran errores, la interfaz debe proporcionar

Usuario retroalimentación significativa y características de ayuda
sensible al contexto.
Diversidad de La interfaz debe proporcionar características de interacción
Usuarios apropiadas para los diferentes tipos de usuarios del sistema.
2. Tipos de Interfaz de usuario.
2.1. Interfaces de lenguaje natural.

Estas interfaces son las “ideales” y utópicas a la vez, ya que en teoría
debe permitir la interacción del usuario en su lenguaje natural, como
el español o inglés, sin requerir de ninguna otra habilidad especial. El
problema es que el lenguaje natural es ambiguo y las interfaces son
limitadas.
2.2. Interfaces de pregunta y respuesta.

En esta interfaz se le presenta una pregunta al usuario, da su
respuesta y puede continuar con la siguiente pregunta, normalmente
dependiendo de la respuesta anterior.
2.3 Interfaces con Menús.

En esta interfaz se le presentan una serie de opciones al usuario y
dependiendo de su elección se ejecuta una acción. Los menús pueden
estar anidados y llevar de una opción a un nuevo menú.
El usuario necesita saber qué tarea debe ser realizada. En este tipo de
interfaz es importante ser consistente, respecto al lugar en que se
colocan los menús, teclas de rápido acceso, nombres comunes para
ciertas tareas, etc.
4
Diseño Interfaces
2.4 Interfaces con formularios (entrada/salida).

Estas interfaces tratan de asimilar las formas impresas que normalmente
utiliza el usuario, ayudándole mostrando dónde colocar qué información.
Algunas formas facilitan el trabajo llenando valores por omisión.
En estas interfaces habrá que considerar si el usuario es
experimentado, en cuyo caso esperará que las interfaces sean más
eficientes que las formas impresas tradicionales.
2.5 Interfaces de lenguaje de comandos.

En esta interfaz se permite al usuario controlar la aplicación por
medio de comandos, conjuntos de teclas, frases, o combinación de las
anteriores. Por lo anterior, el usuario tiene mayor control y poder de
decisión sobre la aplicación, pero requieren capacitación para que el
usuario memorice los comandos y reglas de utilización.
2.6 Interfaces gráficas del usuario (GUI).

Estas son las interfaces más sofisticadas y complicadas, que ofrecen
mayor funcionalidad y flexibilidad al usuario.
3. El proceso de diseño de la Interfaz de usuario.
Analizar y
Realizar el diseño Evaluar el diseño
comprender
del prototipo en con los usuarios
las actividades
papel finales
del usuario
Realizar el diseño Evaluar el diseño

Diseño del
dinámico del de los usuarios
prototipo
prototipo prototipo
Implementar la
Prototipo ejecutable interfaz de usuario
definitiva
El diseño de interfaces es un proceso iterativo, que en general, se puede

resumir en las siguientes fases:
5
Diseño Interfaces
3.1 Análisis del Usuario

Se realiza un análisis cuidadoso para conocer y clasificar al usuario,
su tarea y el ambiente.
Sino se entiende lo que los usuarios quieren hacer con el sistema, no

se podrá llevar a cabo un diseño real y eficaz de la interfaz de usuario.
Para desarrollar esta comprensión, se pueden utilizar técnicas como el
análisis de tareas, estudios etnográficos, entrevistas de usuarios y
observaciones.
3.2 Diseño de la interfaz

En esta fase se elaboran formatos de pantalla donde se incluyan
menús, ubicación de iconos, texto descriptivo, nombres de ventanas,
etc. Pueden generarse prototipos de preferencia con herramientas
constructoras de GUIs (graphical user interfaces). También en esta
fase se realiza la implementación.
Para el diseño de la interfaz se recomienda realizar prototipos

evolutivos o exploratorios con la implicación de los usuarios finales.
Implicar al usuario en el proceso de diseño y desarrollo es un aspecto
fundamental del diseño centrado en el usuario (Nrmal y Draper ,
1986), un criterio de diseño para sistemas operativos.
El propósito de realizar prototipos es permitir a los usuarios adquirir

una experiencia directa con la interfaz.
Cuando se están construyendo los prototipos se debe realizar en dos

etapas así:
• Iniciar con prototipos en papel, maquetas de los diseños de las

pantallas y mostrarlos a los usuarios finales.
• Después se perfecciona el diseño y se desarrollan los prototipos
automatizados y se ponen a disposición de los usuarios para realizar
pruebas y simulación de actividades.
3.3 Evaluación de la Interfaz

Se realizan pruebas y validaciones de las interfaces previas a la liberación.
La evaluación de la interfaz es el proceso de evaluar la forma en que

se utiliza una interfaz y verificar que cumple los requerimientos del
usuario. La evaluación se debe llevar a cabo contra una especificación
de la usabilidad basada en atributos de la usabilidad.
6
Diseño Interfaces
Cabe resaltar que el usuario debe estar involucrado en el proceso de

diseño para facilitar que acepte el producto final.
Atributo Descripción
Facilidad de Rapidez con que un usuario aprende a utilizar un sistema

Aprendizaje con el que no ha tenido contacto anteriormente.
Eficiencia Que el usuario pueda alcanzar un alto nivel de productividad

al usar el sistema.
Retención en Que el usuario pueda recordar fácilmente como se utiliza un
el tiempo sistema cuando ha dejado de utilizarlo por un tiempo.
Se refiere a la cantidad y gravedad de errores que comete
Tasa de error el usuario. Al cometer un fallo el sistema debe informar
a los usuario y ayudar a solucionarlos.
Hace referencia, si los usuarios se sienten cómodos y
Satisfacción
satisfechos al utilizar el sistema.
Control Los usuarios deben tener el control sobre el sistema,

y no a la inversa.
El sistema debe respetar al usuario, es decir, el usuario debe
Habilidades sentir que su experiencia se ve potenciada y complementada
por el sistema.
El sistema debe ayudar a los usuarios a proteger su
Privacidad
información.
Posibilidades de intercambio de información entre los
Flexibilidad
usuarios y el sistema.
Robustez Nivel de apoyo del Sistema al Usuario.
Velocidad de Tiempo que tarda un usuario en realizar una actividad,

Utilización: una vez ya conoce el sistema.
Existen algunas técnicas sencillas para la evaluación de interfaces que

pueden identificar deficiencias específicas en el diseño tales como:
• Cuestionarios que recopilan información de lo que opinan los

usuarios de la interfaz.
• La observación de los usuarios cuando trabajan con el sistema y
piensan en voz alta, de como tratan de utilizar el sistema para llevar
a cabo alguna tarea.
• Instantáneas de vídeos del uso típico del sistema.
• La inclusión de código en el software que recopila información de los
recursos más utilizados y de los errores más comunes.
7
Diseño Interfaces
Cabe resaltar que el usuario debe estar involucrado en el proceso de

diseño para facilitar que acepte el producto final.
4. Herramientas Software para el Diseño de Interfaces
En la actualidad existen muchas herramientas software para el Diseño de

Interfaces. Dentro de ellas encontramos herramientas web y herramientas
de aplicaciones Windows.
Las herramientas de desarrollo de software como visual studio y netbeans,
incluyen elementos propios para el diseño de interfaces.
A continuación se relacionan tres (3) herramientas posibles a utilizar:
• Adobe Dreamweaver: Esta herramienta es licenciada y viene

incluida en la suite de adobe para el diseño de sitios web.
Interfaz de la Herramienta:
• Balsamiq Mockups: Es una herramienta web que se puede

descargar desde internet por un periodo de prueba.
Sitio de descarga: http://www.balsamiq.com

8
Diseño Interfaces
La herramienta permite descargar las interfaces a diferentes

formatos como PNG o PDF.
• Wirefreams on the fly mockingbird: Herramienta web para el

diseño de interfaces, se pueden crear las interfaces directamente
desde el navegador.
Se debe ingresar a la siguiente dirección:
https://gomockingbird.com/
9
Diseño Interfaces
5. Ejemplos Diseño Interfaces Casos de Uso
Se tiene como referencia un Sistema de un Centro Odontológico.
Para iniciar vamos a realizar la interfaz de usuario para el siguiente caso

de uso:
Caso de Uso: Autenticar Usuario.

Sistema: Gestión Odontológica.
Caso de Uso Autenticar usuario
Descripción El comportamiento del Sistema debe validar

el usuario que ingresa al sistema.
El personal debe estar registrado en el sistema
Precondición para que al ingresar sus datos de login y password
puedan ser validados.
Secuencia Paso Acción

Normal
1 El personal médico al ingresar al sistema
debe ingresar con un login y password
asignados por el administrador.
2 El sistema valida el login y password.
3 Si los datos son validos, el sistema

muestra las opciones correspondientes,
dependiendo del tipo de usuario.
Pos condición El empleado ingresa al sistema.
Excepciones Paso Acción
3 Si los datos de login y password no son
validos, el sistema informa al personal
médico para que se revise y actualice
la información.
3 Si el login y password no son validos

el sistema no permite ingresar.
10
Diseño Interfaces
Pasos para realizar la interfaz mediante prototipos:

1. Creamos un prototipo en una hoja de papel.
2. Ahora procedemos a realizarlo utilizando una herramienta

software. Para ello vamos a utilizar Balsamiq Mockups.
En el documento de apoyo llamado Crear Interfaces Balsamiq se
muestra el paso a paso de la creación de la siguiente Interfaz.
11
Diseño Interfaces
Caso de Uso: Registrar Paciente.

Sistema: Gestión Odontológica.
Caso de Uso Autenticar usuario
Descripción El comportamiento del sistema deberá describir

el paso a paso del caso de uso cuando el personal
encargado de gestionar datos del paciente inicie
el ingreso de estos.
Precondición El paciente no se encuentra registrado en el

sistema y tiene la documentación necesaria
para poder ser ingresado al sistema.
Secuencia Paso Acción
Normal El sistema muestra al personal medico una
1 interfaz para que se ingresen los datos del
nuevo paciente(identificación, nombres,
apellidos, dirección, teléfono, correo,
genero, tipo de sangre, nombre acudiente.
2 El personal médico ingresa los datos
del paciente.
3 El sistema valida inicialmente si el

documento de identidad del nuevo
paciente no existe en el sistema,
si no existe registra el nuevo paciente.
4 El sistema informa al personal médico que

el paciente ya ha sido ingresado al sistema.
Pos condición El paciente queda registrado en el sistema.
Excepciones Paso Acción
3 Si el sistema detecta que ya existe un

paciente registrado con ese documento de
identidad, procede a informar al personal
médico, estos deben modificar y/o
actualizar si es necesario.
3 Si ya existe la persona en el sistema se

procede a cancelar el registro del paciente
y se termina el caso de uso.
12
Diseño Interfaces
1. Creamos un prototipo en una hoja de papel.
13
Diseño Interfaces
2. Ahora vamos a crear la interfaz utilizando una herramienta

software desde gomockingbird.com. En el Documento de apoyo
llamado Crear Interfaces Gomockingbird se muestra el paso a paso
de la creación de la siguiente Interfaz.
14
Diseño Interfaces
GLOSARIO
Interfaz de usuario: La interfaz de usuario es el medio con que el

usuario puede comunicarse con una máquina, un equipo o una
computadora, y comprende todos los puntos de contacto entre el
usuario y el equipo. Normalmente suelen ser fáciles de entender y
fáciles de accionar.
GUI: La interfaz gráfica de usuario, conocida también como GUI (del

inglés graphical user interface) es un programa informático que actúa de
interfaz de usuario, utilizando un conjunto de imágenes y objetos
gráficos para representar la información y acciones disponibles en la
interfaz. Su principal uso, consiste en proporcionar un entorno visual
sencillo para permitir la comunicación con el sistema operativo de una
máquina o computador.
Prototipos: Un prototipo en software es un modelo del comportamiento

del sistema que puede ser usado para entenderlo completamente o
ciertos aspectos de él y así clarificar los requerimientos... Un prototipo
es una representación de un sistema, aunque no es un sistema
completo, posee las características del sistema final o parte de ellas.
Usabilidad: se refiere a la facilidad con que las personas pueden utilizar

una herramienta particular o cualquier otro objeto fabricado por
humanos con el fin de alcanzar un objetivo concreto. La usabilidad
también puede referirse al estudio de los principios que hay tras la
eficacia percibida de un objeto.
Menús: Es una serie de opciones que el usuario puede elegir para

realizar determinada tarea.
Formularios: Un formulario es un documento, diseñado con el

propósito de que el usuario introduzca datos estructurados en las zonas
del documento destinadas a ese propósito para ser almacenadas y
procesadas posteriormente.
16
PATRONES DE DISEÑO
1. Generalidades
2. Patrones Gof
2.1. Patrones Creacionales
2.1.1.Fábrica Abstracta
2.1.2.Constructor
2.1.3.Método de Factoría
2.1.4.Prototipo
2.1.5.Singleton
2.2. Patrones Estructurales
2.2.1.Adaptador
2.2.2.Puente
2.2.3.Compuesto
2.2.4.Decorador
2.2.5.Fachada
2.2.6.Peso Ligero
2.2.7.Proxy
2.3. Patrones de Comportamiento
2.3.1.Cadena de responsabilidades
2.3.2.Comando
2.3.3.Interprete
2.3.4.Iterador
2.3.5.Memento
2.3.6.Observador
2.3.7.Estado
2.3.8.Estrategia
2.3.9.Método plantilla
2.3.10.Visitante
3. Patrón Modelo Vista Controlador

Patrones de Diseño
MAPA CONCEPTUAL
Generar Reportes
2
Patrones de Diseño
INTRODUCCIÒN
Durante la etapa de diseño del sistema una de las principales tareas es la

construcción de diagramas de clases, sin embargo, pensar que el
problema que se desea solucionar es único, es un error. Existen
problemas comunes al desarrollo de software que han sido tipificados o
estandarizados y se presentan con sus respectivas soluciones generadas a
partir de diseños de interacción o interfaces. Las soluciones tipificadas, ya
probadas y documentadas, se denominan patrones de diseño.
Los patrones de diseño son una herramienta que soporta la actividad de

diseño de la arquitectura, proporcionando en algunas ocasiones el punto
de inicio en la determinación de aspectos relacionados con la
especificación de clases e interacción para el sistema de información.
La temática que se presenta en este objeto proporciona información sobre

algunos de los patrones de diseño más importantes, con el fin de que sean
considerados durante la fase de diseño de su proyecto formativo.
Patrones de Diseño
GENERALIDADES
Un Patrón de diseño es un modelo o plantilla de la solución a un problema

común en el desarrollo de software. La historia de estos patrones se
remonta a 1987 cuando Warde Cunningham y Kent Beck profesionales del
desarrollo de software se dieron a la tarea de retomar algunas de las que
consideraban “buenas ideas” en la solución de problemas orientados a
objetos y desarrollaron cinco patrones de interacción publicados en un
artículo. Sin embargo no fue hasta 1990 cuando el grupo denominado
“Gang of Four” que en adelante se identificarían como GoF retomaron un
conjunto de 23 patrones de diseño y se empezó con mayor fuerza a
difundir su uso.
Los patrones de diseño se enfocan en brindar una solución a problemas de

software que han sido probados y tienen la documentación que permite
analizar su posibilidad de uso. Esta documentación cuenta entre otros con:
Nombre: describe el problema, solución y consecuencias a través de un

nombre significativo.
Problema: describe cuando debe utilizarse el patrón así como las

condiciones para su aplicación.
Solución: describe los elementos de diseño a incorporar, con la

disposición general de las clases y objetos de forma abstracta.
Consecuencias: los costos/beneficios al aplicar el diseño.
El principal objetivo que se consigue al utilizar esta técnica es el de la

reutilización, lo que facilita conseguir apuntar a los principios de calidad en
el diseño de software que son: la eficiencia, la mantenibilidad del sistema,
que el sistema sea correcto y por ende la disminución en costos.
3
SENA FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
Patrones de Diseño
Una vez que se ha seleccionado el patrón de diseño a utilizar se

recomienda leer inicialmente las partes relacionadas con la aplicabilidad y
consecuencias para verificar que es el correcto, revisar concienzudamente
la estructura para entender las clases y relaciones, así como verificar el
código de ejemplo, que también puede ayudar a entender la
implementación del mismo, escoger nombres significativos para los
objetos y elementos, declarar las clases e identificar las clases que
afectará, definir nombres para los métodos de acuerdo con la guía y por
último redactar las operaciones.
2.0 Patrones Gof: Gang-of-Four.
Se pueden clasificar en 3 categorías:
• Patrones Creacionales (Creational patterns)

• Patrones Estructurales (Structural patterns)
• Patrones de Comportamiento (Bahavioral patterns).
2.1. Patrones Creacionales
Los patrones de creación muestran una guía de cómo crear objetos

cuando su creación requiere tomar decisiones como qué clases instanciar
o sobre que objetos se delegará responsabilidades.
Tienen relación con la instanciación de Clases. Pueden ser divididos en

class-creation patterns y object-creational patterns.
• Los primeros usan la herencia dentro del proceso de instanciación.

• Los otros usan la delegación para realizar la tarea.
4
Patrones de Diseño
2.1.1. Patrón Fabrica Abstracta (Abstract Factory)
Problema:
¿Cómo crear familias de clases relacionadas
que implementan una interfaz común?
¿Cómo hacer que el cambio de la familia de

clases a utilizar sea transparente para la aplicación?
Solución:
Definir una interfaz que contenga métodos para la creación de los objetos
de cada clase.
• Esta representa la Fábrica abstracta.

• Puede ser una interfaz o una clase abstracta.
• Definir las fábricas concretas para cada familia de clases.
MODELO GENERAL FABRICA ABSTRACTA
5
Patrones de Diseño
EJEMPLO FABRICA ABSTRACTA
2.1.2. Patrón Constructor (builder)
Problema:
¿Cómo construir objetos complejos manteniendo la alta cohesión?
¿Cómo construir objetos que requieren varios pasos en su construcción?
6
Patrones de Diseño
Solución:
• Definimos una interfaz que defina cada uno de los pasos de la
construcción.
• Definimos una clase que dirija la construcción de los objetos.
• Para cada forma distinta de crear el objeto, definimos una clase concreta
que la defina.
• Muy similar a Fábrica Abstracta.
o Fábrica Abstracta >> familia de objetos.
o Constructor >> objetos complejos.
MODELO GENERAL - PATRON CONSTRUCTOR ( BUILDER )
7
Patrones de Diseño
EJEMPLO - PATRON CONSTRUCTOR ( BUILDER )
8
Patrones de Diseño
2.1.3. Patrón Método Factoría (Factory Method)
Problema:
¿Cómo creo instancias de elementos sin
saber el tipo concreto del elemento?
¿Cómo creo instancias de una clase, donde la

creación es un proceso complejo?
Solución:
• Asignamos la responsabilidad de la creación a un método particular.
• En caso de que sean múltiples tipos, es el método el que se encarga de
la decisión de cual elemento crear.
• En caso de creación compleja, el método encierra y se encarga de esta
complejidad.
o Dado la responsabilidad de los constructores, estos no

debieran dedicarse a lidiar con operaciones complejas.
o Si existiesen operaciones muy complejas (lectura de archivos,

acceso a bases de datos), en ese caso es mejor que un método se
encargue de la responsabilidad de crear a los objetos de la clase.
o Es una simplificación de Fábrica Abstracta, donde solo se

construye instancias de una clase.
9
Patrones de Diseño
MODELO GENERAL - Patrón Método Factoría (Factory Method)
10
Patrones de Diseño
EJEMPLO - Patrón Método Factoría (Factory Method)
11
Patrones de Diseño
2.1.4. Patrón Prototipos (Prototype)
Problema:
¿Cómo aumentar el rendimiento en la construcción
de objetos que siempre son iguales?
Solución:
• Creamos una instancia del objeto y luego lo clonamos.
• Para ello, definimos una interfaz que deban implementar todos los
objetos que quieran ser clonados.
• En la mayoría de los lenguajes es posible hacer un Shadow copy de los
objetos.
o En C# existe el método MemberwiseClone().

o En Java existe clone().
• Este se puede combinar con Método Factoría para la construcción de

distintos objetos.
12
Patrones de Diseño
MODELO GENERAL - Patrón Prototipos (Prototype)
EJEMPLO - Patrón Prototipos (Prototype)
13
Patrones de Diseño
2.1.5. Patrón de Diseño de Instancia Única (Singleton)
Problema:
¿Qué puedo hacer para asegurar que de una clase determinada exista sólo
una instancia durante toda la ejecución de la aplicación?
Solución:
• Dentro de la clase eliminamos el acceso a los constructores, de modo
que no sea posible construir elementos de esta clase, sólo a través de la
misma clase.
o En la mayoría de los lenguajes esto se logra poniéndolos private o

protected.
• Creamos un método estático de acceso esta instancia.

SENA
o Solamente la primera vez que se llame a este método creamos la
instancia.
o Luego simplemente la retornamos.
MODELO GENERAL - Patrón de Diseño de Instancia Única

(Singleton)
14
Patrones de Diseño
EJEMPLO - Patrón de Diseño de Instancia Única (Singleton)
2.2. Patrones Estructurales
Estos patrones describen las formas en que diferentes tipos de objetos

pueden ser organizados para trabajar unos con otros, es decir la
composición entre clases y objetos, se utiliza la herencia para componer
interfaces y además definen formas de composición entre objetos para
obtener determinada funcionalidad.
15
Patrones de Diseño
2.2.1. Patrón de diseño Adaptador (Adapter)
Problema:
• ¿Cómo puedo hacer que una clase A utilice una clase B, si B no tiene la
interfaz necesitada por A?
• Interfaz en su sentido más amplio.
• Métodos públicos.
• ¿Cómo puedo hacer lo anterior sin cambiar B (porque no tengo acceso,
o porque está muy acoplada)?
Solución:
• Crear una clase que funcione de adaptador entre las dos clases que
quieren comunicarse.
• El adaptador provee la interfaz que necesita la clase A.
• El adaptador traduce las llamadas a su interfaz en llamadas a la interfaz
original (en este caso la clase B).
o En general se trata de transformaciones de parámetros.

o Pero puede llegar a cambiar las responsabilidades de la clase
adaptada.
• Este patrón está pensado para situaciones en las que no tenemos acceso
a la clase B, o dado que la usamos en otras partes de nuestro sistema,
no queremos modificarla.
o Solamente la primera vez que se llame a este método creamos la

instancia.
o Luego simplemente la retornamos.
16
Patrones de Diseño
MODELO GENERAL - Patrón de diseño Adaptador (Adapter)
17
Patrones de Diseño
EJEMPLO - Patrón de diseño Adaptador (Adapter)
18
Patrones de Diseño
2.2.2 Patrón Puente (Bridge)
Problema:
¿Qué debo hacer para desacoplar una abstracción de su implementación,
de modo que ambas puedan variar independientemente?
• Con abstracción nos referimos a la interfaz.
¿Cómo hago cuando una cierta implementación varía en tiempo de

ejecución, manteniendo la abstracción estable?
¿Cómo hago cuando una cierta abstracción varía en tiempo de ejecución,

manteniendo la implementación estable?
Solución
• Creamos una clase abstracta que represente la abstracción y otra clase
abstracta/interfaz que represente la implementación.
• La abstracción contiene un objeto de la implementación, el cual utiliza
para cumplir su propósito
19
Patrones de Diseño
MODELO GENERAL - Patrón Puente (Bridge)
EJEMPLO - Patrón de Diseño de Instancia Única (Singleton)
20
Patrones de Diseño
2.2.3 Patrón Compuesto (Composite)
Problema:
Cómo tratar a un grupo de ciertos elementos de la misma forma como se
trata uno de esos elementos?
• El grupo es una composición.

• El elemento único es un objeto atómico.
¿Cómo tratar a este mismo grupo si además permitimos que contenga

otros grupos de los mismos elementos?
Solución:
• Definir clases para composiciones y objetos atómicos que implementen

la misma interfaz.
• Los objetos se representan como una estructura de árbol.
o Los objetos compuestos son ramas.
o Los objetos atómicos son hojas.
• Permite la realización recursiva de las operaciones.
21
Patrones de Diseño
MODELO GENERAL - Patrón Compuesto (Composite)
EJEMPLO - Patrón Compuesto (Composite)
22
Patrones de Diseño
EJEMPLO - Patrón Compuesto (Composite)
23
Patrones de Diseño
2.2.4. Patrón Decorador (Decorator)
Problema:
¿Cómo podemos añadir nuevas funcionalidades a una clase de forma
dinámica?
¿Cómo podemos decidir en ejecución las funcionalidades que queremos

que realice una cierta clase?
• Herencia implica tener una subclase para cada combinación de

funcionalidades.
• Para 4 funcionalidades serían 16 subclases distintas.
Solución:
• Creamos una clase que decore la clase a la cual queremos agregar

funcionalidad.
• La clase decoradora envuelve a la otra clase, pero comparte con esta la
misma interfaz.
o La clase decoradora tiene como atributo a la otra clase.

o Como comparten la interfaz, podemos tener una clase decoradora
que envuelve a otra clase decoradora.
o De esta forma podemos elegir los adornos en tiempo de ejecución,
simplemente creando decoradores que envuelvan otros decoradores.
• Funcionamiento recursivo similar a Compuesto.
24
Patrones de Diseño
MODELO GENERAL - Patrón Decorador (Decorator)
25
Patrones de Diseño
EJEMPLO - Patrón Decorador (Decorator)
26
Patrones de Diseño
2.2.5 Patrón Fachada (Facade)
Problema:
¿Cómo reducir el acoplamiento con un subsistema de clases complejas,
que están sujetas a futuros cambios, pero manteniendo la funcionalidad
del subsistema?
¿Cómo simplificar la realización de tareas comunes con una serie de clases

de un subsistema?
Solución:
• Creamos una interfaz que exponga las funcionalidades del subsistema.
o Un punto de contacto único con el subsistema, disminuyendo el
posible acoplamiento con ´este.
• A esta interfaz se le llama la fachada del subsistema.

• La clase fachada se preocupa de trabajar con las clases del subsistema
para conseguir la funcionalidad solicitada.
• Una fachada debe simplificar el trabajo con el subsistema.

• Similar a Adaptador
o Adaptador se utiliza cuando es necesario respetar una cierta

interfaz preexistente.
o Fachada se utiliza para definir una interfaz simplificada de acceso

a un subsistema o conjunto de clases.
27
Patrones de Diseño
MODELO GENERAL - Patrón Fachada (Facade)
28
Patrones de Diseño
EJEMPLO -Patrón Fachada (Facade)
29
Patrones de Diseño
2.2.6. Patrón Peso Ligero (FlyWeight)
Problema:
¿Cómo podemos aumentar el rendimiento/uso de memoria de una
aplicación que posee elementos redundantes?
¿Cómo podemos agrupar ciertas características de algunos elementos, de

modo de asegurarnos que siempre sean iguales en todos los objetos?
Solución:
• Definimos una clase flyweight que contenga las características comunes.

• Luego todos los elementos redundantes hacen referencia a un mismo
objeto de la clase flyweight.
o Reducimos el uso de memoria, no hay redundancia de estas

características.
o Referencian al mismo objeto, por ende, cambiar una característica
implica cambiarla en un solo objeto.
30
Patrones de Diseño
MODELO GENERAL - Patrón Peso Ligero (FlyWeight)
EJEMPLO - Patrón Decorador (Decorator)
31
Patrones de Diseño
2.2.7. Patrón Apoderado (Proxy)
Problema:
¿Qué debemos hacer para controlar el uso de recursos de un objeto
determinado, dada su complejidad o uso de memoria?
¿Cómo podemos hacer para que los recursos se consuman solamente si es

necesario?
Solución:
• Creamos un intermediario con la misma interfaz que el objeto final.

o El intermediario contiene un objeto de la clase que queremos
utilizar.
o Puede crearlo solamente cuando sea necesario.
• Este intermediario es el llamado proxy.

o Al compartir la interfaz con la clase final, su uso es transparente
para la clase cliente.
• Muy utilizado para el acceso a redes.
o Por ejemplo en un servidor Web podemos utilizarlo para que cuando
nos pidan un sitio que ya fue solicitado antes, enviar la versión que
almacenamos en la cache.
32
Patrones de Diseño
MODELO GENERAL - Patrón Apoderado (Proxy)
EJEMPLO - Patrón Apoderado (Proxy)
33
Patrones de Diseño
2.3. Patrones de Comportamiento
Los patrones de este tipo son utilizados para organizar, manejar y

combinar comportamientos.
Relación de Patrones de Comportamiento
Cadena de Responsabilidades (Chain of Responsability): Permitir que ante

una petición se realicen acciones distintas dependiendo del estado del
sistema.
Comando (Command):
Manejar acciones de forma independiente y generalizable, de modo que

podemos hacer invocaciones con estas acciones sin necesidad de saber
quien la realiza realmente.
Intérprete (Interpreter):
Representar la gramática de un cierto lenguaje para poder interpretarlo.
Iterador (Iterator):
Recorrer objetos sin necesidad de conocer su estructura.
Mediador (Mediator):
Desacoplar la interacción entre distintos elementos, permitiendo que

todos se comuniquen a través de un objeto común, reduciendo la
complejidad de la interacción.
Recuerdo (Memento):
Manejar estados de la aplicación, pudiendo volver a estados anteriores.
Observador (Observer):
Definir una dependencia de uno a muchos entre objetos, de forma que

muchos objetos puedan enterarse de los cambios en uno de ellos.
34
Patrones de Diseño
Estado (Server):
Permitir que la ejecución de las acciones de una clase sea dependiente del
estado en que se encuentra, pudiendo variar el estado en tiempo de
ejecución.
Estrategia (Strategy):
Tener diversos algoritmos para realizar una tarea y poder cambiarlos en

ejecución.
Método Plantilla (Template Method):
Reutilizar el esqueleto de un algoritmo, cambiando sólo el contenido de

cada uno de los pasos de este.
Visitante (Visitor):
Definir nuevas operaciones sobre una jerarquía de clases sin modificar las
clases sobre las cuales opera.
35
Patrones de Diseño
3. Patrón Modelo Vista Controlador (MVC)
MVC son las siglas de Modelo Vista Controlador, que es un patrón de

arquitectura de software cuya función es subdividir una aplicación en tres
módulos que corresponden a la vista del usuario (la interfaz a la que
accede el usuario), una lógica de control para captar los eventos que el
usuario ha generado a través de la interfaz, y un modelo que gestiona los
datos según le indique la lógica de control.
El objetivo del patrón MVC es desacoplar la presentación de la información

(vista) de su representación (modelo), para así reducir la complejidad en
el diseño arquitectónico (de IU) e incrementar la flexibilidad y
mantenibilidad del código.
Sin MODELO VISTA CONTROLADOR - MVC
Responsabilidades difusas
36
Patrones de Diseño
Modelo:
Esta es la representación específica de la información con la cual el

sistema opera y se compone por el Sistema de Gestión de Base de Datos
y la lógica de negocio. La lógica de negocio asegura la integridad de estos
y permite derivar nuevos datos. El Sistema de Gestión de Base de Datos
(SGBD) será el encargado de almacenar los cambios en los datos (agregar
datos, editarlos o borrarlos) producidos por la lógica de negocio; ejemplos
de SGBD son MySQL, Oracle... Es recomendable una capa de abstracción
extra denominada Data Access Object (DAO), que es un componente de
software que suministra una interfaz común entre la lógica de negocio y el
SGBD.
Vista:
Este presenta el modelo en un formato adecuado para interactuar,

usualmente la interfaz de usuario. Por lo tanto, la vista es la encargada de
presentar los datos al usuario y la interfaz necesaria para modificarlos.
Controlador:
Este responde a eventos, usualmente acciones del usuario e invoca

cambios en el modelo y probablemente en la vista. Por lo general, el
controlador sería la unidad central que comunica la vista con el modelo y
viceversa, asociando los eventos del usuario con los cambios que se
producirán en el modelo y devolviendo los datos resultantes que genere el
modelo a la vista que corresponda.
37
Patrones de Diseño
CON MODELO VISTA CONTROLADOR - MVC
38
Patrones de Diseño
Aunque se pueden encontrar diferentes implementaciones de

MVC, el flujo de control generalmente es el siguiente:
• El usuario interactúa con la interfaz de alguna manera (ej. presionando

un botón, un enlace).
• El controlador recibe (por parte de los objetos de la interfaz vista) la

notificación de la acción solicitada por el usuario.
• El controlador accede al modelo o, posiblemente actualizando los datos

enviados por el usuario.
• El controlador delega a los objetos de la vista la tarea de desplegar la

interfaz de usuario.
• La vista usa el modelo para generar la interfaz apropiada para el usuario

donde se refleja los cambios en el modelo.
• En algunas implementaciones la vista no tiene acceso directo al modelo,

dejando que el controlador envíe los da tos del modelo a la vista.
• La interfaz espera por nuevas interacciones de usuario para iniciar

nuevamente el ciclo.
39
Diseño de interfaces utilizando
herramienta web balsamiq mockups
Primero ingresar al siguiente sitio de internet: http://www.balsamiq.com,

para que descargue e instale la herramienta Desktop Mockups.
Cuando se instala se crea un icono en el escritorio con el nombre de

Balsamiq Moczkups. Dar clic en este icono para iniciar. Debe aparecer la
siguiente ventana:
Como ejercicio vamos a crear la siguiente interfaz:
2
Damos clic en la pestaña llamada forms como lo indica la siguiente imagen:
Al dar clic en forms en la parte inferior aparecen muchos elementos que

podemos utilizar para crear nuestra interfaz. Debajo de esos botones hay
una barra de desplazamiento para mirar todos los elementos de la pestaña
forms.
Ahora damos clic en la Pestaña All y aparecen todos los elementos posibles
a utilizar para el diseño de la Interfaz:
Para iniciar vamos a buscar el elemento llamado Window / Dialog, para

ello utilicemos la barra de desplazamiento. Este elemento es el último.
3
Damos clic sostenido y lo soltamos en el área de trabajo.
Al agregarse el elemento, nos aparece la opción habilitada para cambiar

el texto, como ejercicio vamos a colocar Sistema Centro Odontológico
como se encuentra en la interfaz a realizar. Al hacer los cambios ya la
interfaz se encuentra así:
4
Ahora vamos agregar un texto para agregar el Titulo CENTRO

ODONTOLOGICO ADSI. Para ello buscamos el elemento llamado A Subtitle
así:
Damos clic sostenido y lo agregamos dentro del objeto anterior.
5
Al agregar el elemento A subtitle modificamos el texto y colocamos

CENTRO ODONTOLOGICO ADSI.
Al cambiar y aceptar el texto nos muestra otras opciones de configuración

del subtitulo así:
Por ahora no vamos a modificar nada.
Al agregar el texto la interfaz va quedando así:
6
Ahora vamos agregar el elemento llamado Rectangle / Canvas dentro del

elemento ventana de la interfaz, debajo del título Centro Odontológico
ADSI.
Al agregar le modificamos el tamaño, dando clic sostenido en las esquinas,

para que la interfaz quede así:
7
Ahora vamos agregar el texto INGRESO AL SISTEMA, para ello agregamos

el elemento llamado some text dentro del rectángulo agregado
anteriormente.
Al agregar el elemento y actualizar el texto, nos salen las propiedades,

cambiemos el tamaño del texto a 20.
Después de los cambios la interfaz va quedando así:
8
Ahora vamos agregar los textos login y password utilizando el emento

some text, cambiando el tamaño a 16 y la interfaz debe quedar así:
Para continuar con el diseño vamos agregar un elemento llamado Text/

Input al frente de login y password.
9
Al agregar los text-input podemos ajustarles el tamaño al deseado.
Después de agregar estos elementos la interfaz va quedando así:
Para continuar ahora vamos agregar un botón y le colocamos el texto

INGRESAR. Para ello busque el elemento llamado button y agréguelo al
área de trabajo y cambie el texto.
Al agregar el botón la interfaz ha quedado así:
10
Si deseamos cambiar las propiedades de la ventana completa de la interfaz,

damos clic en el objeto y aparecen las opciones de propiedades así:
Como ejercicio vamos a dar clic en los 3 elementos que me señala la

flecha roja para que mi interfaz también quede con esos elementos de la
ventana window de la interfaz que estamos creando.
11
Después la interfaz queda así:
Para terminar puede guardarlo en el formato propio de la herramienta y

exportarlo a diferentes formatos como lo muestra las opciones del menú
file de la herramienta.
12
herramienta gomockingbird
Ingresar al siguiente sitio de internet: https://gomockingbird.com/
Al iniciar aparece la siguiente información:
Damos clic en el botón:
2
Interfaz de gomockingbird.
3
Vamos a conocer la interfaz que vamos a crear con la presente herramienta:
4
Pasos para crear la interfaz
1. Ubicarnos en el menú file y dar clic en la opción new para crear nuestra
nueva interfaz.
2. Al dar clic en esa opción nuestra área de trabajo ya esta vacía y lista
para iniciar.
3. Agregamos un rectángulo grande donde se van agregar todos los demás

controles de la interfaz. Buscamos el objeto Rectangle al lado izquierdo
en el bloque widgets, damos un clic sostenido en el objeto, lo llevamos al
área de trabajo y lo soltamos.
5
Al agregarlo lo ampliamos al tamaño deseado, de acuerdo a las necesidades.
4. Vamos agregar a la interfaz el titulo REGISTRAR PACIENTE. Para ello

buscamos el objeto llamado text, clic sostenido y lo soltamos en la parte
superior interna del Rectángulo.
Al agregar el objeto text, podemos cambiar directamente el texto deseado

por el texto inicial Some Text.
Al cambiar el texto la interfaz va quedando así:
6
Podemos cambiar el tamaño y color del texto como lo indica la siguiente

gráfica. Las opciones las tenemos en la barra de herramientas.
Vamos a cambiar el tamaño a 22 en Font size y cambiar el color de texto

como lo muestra la siguiente imagen:
7
5. Ahora vamos agregar el texto Identificación y su caja de texto respectiva.

Agregamos el objeto texto y lo cambiamos por Identificación.
6. Después agregamos el objeto Text Input Box con clic sostenido y lo

soltamos en el área de trabajo al frente del objeto de texto identificación.
Eliminamos la palabra Some text. Al agregar la interfaz debe quedar así:
Podemos modificar el tamaño del Text Input Box, de acuerdo las

necesidades.
8
7. De la misma forma lo hacemos para los elementos nombres, apellidos,

dirección, teléfono y correo. Al realizar la interfaz debe ir quedando así:
8. Vamos agregar ahora el objeto Text y cambiamos el texto por estrato.
9. Después agregamos el objeto DropDown al frente el objeto de texto

llamado estrato.
Al agregar el elemento aparece así:
9
La interfaz va quedando así:
10. De la misma forma hacemos para los elementos tipo de sangre y

genero. Al finalizar la interfaz debe quedar así:
10
11. Para continuar agregamos un objeto Text y colocamos el texto Nombre

Acudiente. Agregamos su respectiva caja de texto.
Al agregar los anteriores elementos la interfaz va quedando así:
12. Ahora agregamos a la interfaz dos Botones y a uno de ellos le colocamos

la palabra REGISTRAR y al otro CANCELAR. Para ello buscamos el objeto
llamado Button.
11
Al agregarlos la interfaz queda así:
13. Vamos agregar una línea horizontal debajo de la línea superior del
rectángulo. Para ello utilizamos el objeto llamado Horizontal Line.
Ahora seleccionamos y la línea y todo el rectángulo lo agrupamos dando

clic en el botón de la barra de herramientas que se llama Group.
12
Ahora agregamos un texto en la parte superior en medio del borde externo

del rectángulo y la línea que acabamos de agregar. Cambiamos el texto
por: Centro odontológico: Registrar Paciente. Al finalizar la interfaz debe
quedar así:
14. Para terminar procedemos a guardarlo. Dar clic en menú File y después
en Save as. Aparece la siguiente ventana:
Ingresamos un nombre a nuestra interfaz. Como ejemplo vamos a colocar

registrarPaciente.
También puede exportarlo a formato PDF o PNG. Para ello dar clic en
menú File y después por Export seleccionar PDF o PNG.
13
ARQUITECTURA LÓGICA DEL SISTEMA ARQUITECTURA LÓGICA DEL SISTEMA
INTRODUCCIÓN ESTRUCTURA DE CONTENIDOS
La arquitectura se refiere a un arte y a un estilo de construir caracterizados Introducción ............................................................................... 2

por ciertas particularidades. La arquitectura tradicionalmente se aplica
a la construcción de edificios. En toda la historia de la humanidad las Mapa Conceptual ......................................................................... 4
diferentes culturas han usado diferentes técnicas, materiales y estilos
en la construcción de su casa, edificios religiosos, edificios militares y 1. Arquitectura de Software ................................................... 5
edificios civiles.
1.1. Arquitectura en capas ........................................................... 6
En la industria del software, el término arquitectura se usa para describir
las diferentes estructuras que forman un sistema y las relaciones entre
1.1.1. Modelo en dos capas ........................................................ 6
ellas .
1.1.2. Modelo en tres capas ....................................................... 7

Como refiere Pressman (2005), “En su forma más simple, la arquitectura es
la estructura u organización de los componentes del programa (módulos),
la manera en que éstos componentes interactúan y la estructura de datos 1.1.3. Modelo Multicapas ........................................................... 8
que utilizan los componentes”
2. Diseño de la Arquitectura .................................................. 9
A partir de la utilización del Lenguaje Unificado de Modelamiento (UML por
sus siglas en Inglés) se proveerán los elementos a considerar y diagramas 2.1. Diagrama de componentes .................................................... 10
que permitirán definir la arquitectura lógica del sistema de información.
2.1.1. Componentes ................................................................. 10
2.1.2. Interfaces ...................................................................... 12
2.1.3. Como se realiza un diagrama de componentes .................... 13
2.1.4. Subsistemas .................................................................. 16
2.2. Diagrama de paquetes ......................................................... 16
2.2.1. Elementos de un diagrama de paquetes ............................. 16
Bibliografía ................................................................................ 19
Glosario..................................................................................... 20
Control de Documentos Creative Commons y Marca Registrada ........ 21
2 3
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
MAPA CONCEPTUAL 1. ARQUITECTURA DE SOFTWARE
La arquitectura de software de un programa o de un sistema computacional,

es la estructura o estructuras del sistema. Dicha estructura comprende
sistemas, subsistemas, componentes e interfaces, así como las relaciones
entre ellos. Debido a que la definición de la arquitectura de un sistema
se basa en modelos o abstracciones de la realidad, la arquitectura debe
suprimir el detalle que no influye en la descripción de cómo las partes
usan, son usadas o se relacionan con las otras partes del sistema.
La arquitectura debe considerar tanto los requerimientos funcionales

como los no funcionales: restricciones de diseño, tiempos de respuesta y
disponibilidad del servicio, entre otros y debe estar preparada para recibir
fácilmente requerimientos nuevos.
Dada la creciente demanda de software en todo el mundo y la dificultad

para cubrir la necesidad de ingenieros preparados, la reutilización se ha
vuelto una necesidad mayor. La arquitectura debe facilitar la identificación
temprana de oportunidades de reutilización y facilitar la incorporación de
partes desarrolladas y probadas con anterioridad.
La arquitectura debe considerarse la base para el mantenimiento del

sistema, así mismo debe favorecer la evolución del sistema previniendo
la erosión o la descomposición de la arquitectura debido a violación de los
principios originales y evitando caer en un caos de la arquitectura por no
respetar las tendencias o rumbo establecidos para un proyecto.
En general, la arquitectura de software proporciona un marco de

referencia para todo el proyecto e incorpora muchas de las decisiones más
importantes que se hacen durante el proceso de desarrollo del sistema.
Podemos concluir que la arquitectura tiene cuatro funciones principales:
Constituye una base para el diseño.
Constituye la infraestructura sobre la cual se acomodan los

requerimientos a través de todo el ciclo de vida del desarrollo.
Alienta la detección de oportunidades de reutilización.
Constituye la base para el mantenimiento del sistema.
4 5
1.1. ARQUITECTURA EN CAPAS Aquí se organizan las funcionalidades de presentación y procesos del
negocio en una capa y la base de datos se encuentra en otra capa.
Una metodología para particionar el sistema es usar una arquitectura de
capas, donde cada capa debe cumplir con una responsabilidad claramente Esta estructura no facilita el mantenimiento ni la reutilización de
definida. A través del proceso de estructuración de metodologías de componentes por lo cual no se recomienda y actualmente está en desuso.
desarrollo, se han definido unas clasificaciones de acuerdo con la cantidad
de capas, sin embargo es importante clarificar que todas ellas tienen tres 1.1.2. Modelo en tres capas
componentes básicos:
En este modelo las tres capas se encuentran perfectamente diferenciadas,
lo cual facilita su mantenimiento y reutilización de componentes, algunas
Presentación: donde se genera los procesos de entradas y salidas de
de las características que presentan son:
datos, abarca todas las funcionalidades relacionadas con la interfaz
gráfica de usuario.
Lógica o procesos: provee las funcionalidades que dan respuesta a BBD

los requisitos del sistema. Presentación Negocio Acceso a datos
Datos: funcionalidades relacionadas con el almacenamiento y Interfaz de

Usuario
Lógica de
Procesos
manipulación de los datos.
WWW
Utilidad de
Usuario
1.1.1. MODELO EN DOS CAPAS Web Funciones

Services de Acceso a
Datos
También se le denomina, cliente servidor, en este caso permite que usuarios

finales obtengan acceso a los datos que generalmente se encuentran en
otra capa. Es importante aclarar que esta separación puede ser lógica o Utilidades del Lenguaje Seguridad
física.
Manejador de base Capa Presentación:

de datos DBMS
Allí se encuentran la interfaz de usuario y todas aquellas utilidades
relacionadas con la recepción y presentación de datos, también es la
que proporciona la interfaz con la capa lógica o de negocios y por tanto
envía los datos para ser procesados y posteriormente los recibe para
su presentación al usuario.
Cliente Servidor
6 7
Capa Lógica o de Negocios: 2. DISEÑO DE LA ARQUITECTURA
En ésta se encuentran las funcionalidades que dan respuesta a los Una de las principales actividades del diseño es la partición de funcionalidad,
requerimientos de la aplicación, regidas por las póliticas del negocio, identificada en la fase de análisis y especificación de requerimientos, en
entonces son todas aquellas utilidades propias o externas que módulos de software específicos. Un módulo puede corresponder a un
procesan los datos. Tiene interfaz con las otras capas, ya que por objeto, o un método.
un lado interactúa con los servicios de datos y por otro lado envía la
información procesada para ser presentada al cliente. Específicamente, el diseño del sistema está orientado alrededor de la
definición de objetos que representan las clases que fueron identificadas
Capa de Datos: durante el análisis, dándose el mismo énfasis al diseño de los datos que a
las acciones del sistema.
Contiene todas las funcionalidades para el acceso y manipulación
de los datos. Puede estar compuesto por el Sistema Manejador de Los componentes de software pueden describirse en términos de clases,
Base de Datos o Archivos planos y las utilidades construidas para el paquetes, subsistemas y sus dependencias, o físicamente en términos de
manejo de los datos. archivos ejecutables, librerías de clases y bases de datos.
1.1.3. Modelo multicapas En sistemas orientados a objetos la arquitectura lógica del software
se modela usando diagramas de clases y diagramas de paquetes.
Conservando la estructura de tres componentes principales, en este La arquitectura física del software es descrita usando diagramas de
modelo se “subdivide” cada una de las capas, especializando los servicios componentes
que se proveen en cada una de ellas.
Servicios de Traduccion de Datos
Servicios de Reglas de Negocio
Programación de Objetos en
Servicios de Acceso a Datos
Servicios de Base de Datos

Servicios de Presentación
Servicios de Contexto de
Diagrama de Diagrama de
Paquetes Paquetes
Acceso a datos
Bases de Datos
Negocio
Presentación Modulo de Modulo de
Modulo de Referencia Modulo de Referencia Contrareferencia
Contrareferencia
por Emergencia por Emergencia
Negocio
Lógica de
Interfaz de Procesos
Usuario
Modulo de Cambio de Modulo de Cambio de Modulo de

Modulo de
descripción descripción Administración
Administración
Utilidad de
Usuario WWW Funciones
Web de Acceso a
Services Datos
Modulo de Modulo de
Reportes Reportes
La cantidad de subniveles depende de la definición de funcionalidades, pero

facilita la actualización de las reglas de negocio, el manejo de recursos y
la escalabilidad del sistema, la definición de estas subcapas depende de
las metodologías de desarrollo que se apliquen.
8 9
2.1. DIAGRAMA DE COMPONENTES Relación entre clase y componentes

Clases Componentes
Los diagramas de componentes se utilizan para describir los elementos
físicos, códigos fuentes, las librerías, tablas, archivos y ejecutables que Abstracciones LógicasT iene fragmentos físicos
se van a utilizar o serán utilizados en el sistema o proyecto que se va a
desarrollar junto con sus relaciones.
Tiene operaciones y atributos Tiene interfaces
Los diagramas de Componentes incluyen los siguientes elementos:
Componentes.
Interfaces. <<Library>>
LogicaUsuarios.dll
Relaciones de dependencia, generalización, asociación y
realización. Componente
Implementa la clase
Paquetes o subsistemas.
Usuarios
2.1.1. COMPONENTES
Un componente es una parte física de un sistema de información (modulo,

Notación
base de datos, programa ejecutable, etc.).
Un componente se representa con un rectángulo en el que se escribe su

Un componente puede relacionarse, con las clases que se identificaron
nombre y en él se muestran dos pequeños rectángulos al lado izquierdo.
en la fase de análisis (específicamente en el diagrama de clases); los
componentes se pueden expresar como la materialización de una o más
clases. Recordemos que una clase consta de atributos y métodos, estos La representación grafica de un componente en StartUML es la siguiente.
pueden ser implementados en los componentes.
<<Library>>
Un componente tiene cinco estereotipos Standard: Logica.dll
<<Ejecutable>>: Componente que se puede ejecutar en un nodo.
<<Library>>: Representa una biblioteca de objetos estática o dinámica. Relación entre los componentes:
<<Table>>: Representa una tabla de la base de datos. Los componentes pueden tener relaciones de dependencia, generalización,
asociación (incluida agregación) y realización.
<<File>>: Representa un documento que contiene código fuente o datos.
Recuerde Agregación: Un componente puede construirse a partir de
<<Document>>: Representa un documento. otros componentes.
10 11
2.1.2. Interfaces 2.1.3. Cómo se realiza un diagrama de componentes.
Los componentes implementan interfaces o acceden a los servicios Para editar o graficar un componente y/o diagrama de componentes
proporcionados por las interfaces. se utilizan herramientas CASE que soporten el modelado UML. En este
material se utilizara la herramienta StarUML, una herramienta libre,
sencilla de manejar y fácil de instalar, en el laboratorio correspondiente
Notación encontrará el tutorial con la información correspondiente a su instalación
y utilización.
La representación grafica de una interfaz en StartUML es la siguiente:
Para construir un diagrama de componentes tenga en cuenta:
Previamente debe tener realizado el diagrama de clases (estudiado

en la fase de Análisis); e identifique claramente: las clases que
participaran en el sistema o subsistema a desarrollar y los métodos
Nombre Interfaz de cada clase.
Utilidad de las interfaces
Recuerde que los métodos en las fases de código luego se convierten
en módulos con líneas de código independientes.
Una interfaz es utilizada por un componente para indicar:
Un componente provee una interfaz. Por ultimo los módulos son los componentes identificados en un
diagrama de componentes.
Un componente utiliza una interfaz.
Por ejemplo: Se tiene un sistema que permite el registro de los datos Los componentes se relacionan entre ellos por medio de las interfaces.
personales de un usuario tales como (nombre, dirección, cedula, teléfono),
previamente se ha definido una tabla Usuarios (almacena los usuarios del
sistema, en este caso el componente identificado es de tipo <<Table>> Ejemplo 1:
y es llamado Usuarios), se definió una clase llamada RegistroDatos (en
este caso el componente es de tipo <<Ejecutable>>, llamado Registro). Descripción del Problema:
Con las interfaces podemos representar lo siguiente: El componente Un sistema de facturación para la compra y ventas de productos deportivos
ejecutable genera una interfaz llamada GestióndeUsuarios; el componente registra información referente al pedido que realiza un cliente, el contrato
BuscarUsuarios utiliza la interfaz GestiondeUsuarios. de venta, los datos personales de un cliente, los datos personales del
distribuidor, proveedor, datos de las cuentas por cobrar. Tiene asociado el
<<File>>
siguiente diagrama de clases.
BuscarUsuario
<<Ejecutable>>
Registro.exe
12 13
Pedido
Ejemplo 2:
ContratoVenta Cliente
- PedNum Proveedor
- ContVNumContrato - PedFecha - CliCodigo
1 1 * 1 - ProReferencia
Para las pruebas de estado ICFES que exige el Gobierno Nacional de
- ContVDetalle - PedDetalle - CliNombre
- ContVFecha - CliDireccion - ProNombre
- PedDescripcion Realiza
- ContVMonto Realiza - PedCantidad - CliTelefono - ProDireccion
+ ImprimirContrato()
+FirmaContrato()
+ RegistrarPedido()
- CliCedula
+ Pedido()
+ EntregarProducto() Colombia cuenta con un sistema que permite realizar las operaciones para
* *
+ConsultasProducto()
+PagoProductos()
1
el ingreso de los Estudiantes a la educación Superior o Universitaria, tales
Entrega
como registro de datos para poder presentar dicha prueba, consultar de
Provee
1
1
la citación y del resultado de la misma, y otras operaciones relacionadas
Distribuidor Distribuidor RegistroStock
*
con la intencionalidad y las características propias del examen. Estas
- CuentPCDetalle
- CuentPCFecha
* 1 - DisCodigo
- DisNombre
- RegSFecha
- RegSDetalle 1 *
Producto operaciones se pueden realizar a nivel individual, como estudiante de una
Institución, o a nivel Institucional (Por Plantel), por lo cual cada uno de
- CuentPCMonto - DisDireccion - ProdNombre
Registra + Busqueda() - ProdDetalle
- DisTelefono
+ BuscarCuenta() +ActualizacionRegistro() Registra
+ Actualizar() + EntregaPedido()
+Cobro Factura() estos usuarios debe contar con un código o documento de identificación,
+CobroDeudaPendiente()
y una contraseña; los usuarios individuales o particulares, el sistema les
solicita un Nº de Documento y un PIN, a los usuarios estudiante les solicita
Teniendo el diagrama anterior, se inicia con la construcción del diagrama un Nº de Documento y una Contraseña, y a los usuarios por institución
de componentes: les solicita el código del plantel y una Contraseña. Dichos datos son
necesarios en todas las operaciones que se realizan en dicho sistema.
Identifique los procedimientos y/o funciones para cada clase, en el
diagrama de clases de la imagen anterior las funciones se distinguen por
Diagrama de Clases:
que se encuentran ubicadas en el segundo fragmento de la clase y reciben
argumentos o parámetros, por lo tanto finalizan con paréntesis (). Prueba Resultado
-Codigo -Codigo
-Fecha -Fecha
Para la clase Cliente serian: Pedido(), ConsultaProductos(), PagoProductos(). -Lugar -Puntaje

Estudiante
+AdicionarPrueba() +GestionarResultado()
Citacion -Codigo
-Nombre
-Cedula
Una vez se tienen identificados todos los métodos de las clases se procede -Fecha
-Lugar Registro
-Contraseña
-Login
-Hora
a realizar el diagrama de componentes: Cuestionario
+GenerarCitacion()
-PIN
-TipoEs
-Codigo
-LasPreguntas -FechaReg +ObtNombre()
Diagrama de componentes.
+ObtCedula()
+ConformarPreguntas() +GenerarRegistro() t
+ObtNombre()
+GestionarCuestionario() -CodigoReg
Preguntas
-DescripcionPreg
+GenerarPreguntas()
<<File>>
<<Ejecutable>> ImprimirContrato
ElaborarContrato
<<File>> Diagrama de Componentes:

BuscarUsuario
<<Ejecutable>>
<<Ejecutable>> <<Ejecutable>>
RejistrarPedido
GestionarResultado
PagarProductos
<<Ejecutable>>
GestionPedido GestionResultado
Registro.exe
GestionUsuarios
<<Ejecutable>>
BuscarCuenta <<Ejecutable>> <<Ejecutable>>
<<Ejecutable>>
AdicionarPrueba ConformarPreguntas
BuscarUnidadesStock <<Ejecutable>>
ColorDeudaPendiente GestionPrueba
<<Ejecutable>> <<Ejecutable>>
GenerarRegistro.exe GenerarCitacion
GestionCuestionario
14 15
2.1.4. Subsistemas Notación
Permiten dividir en sistemas más pequeños el sistema actual, un subsistema Un paquete se representa con un icono con forma de carpeta y con el
puede contener componentes y a la vez subsistemas. nombre colocado dentro del icono.
Se debe tener en cuenta que la relación entre paquetes y clases en el

nivel lógico es el que existe entre subsistemas y componentes en el nivel
físico. Nombre
2.2. Diagramas de paquetes
Los diagramas de paquetes se utilizan para organizar el sistema en

subsistemas, agrupando elementos del análisis, diseño o construcción y
detallando las relaciones de dependencia entre ellos. Dependencia
Es decir, se hace necesario organizar el sistema en bloques menores para

comprender fácilmente el sistema por completo. Aplicando la frase “divide
y vencerás”.
Ejemplo 1:
2.2.1. Elementos de un diagrama de paquetes

Paquete Negocio Paquete de BD
Paquetes
+ Ejemplar + Persistencia
+ Préstamo
Un paquete permite agrupar varios elementos, bien sea casos de uso, + Título
# Eliminación
+ Información del prestatario
clases o componentes. Los paquetes pueden contener otros paquetes + Título del libro
por dentro, lo que se llama paquetes anidados, donde el paquete “hijo” + Reserva
contendrá nuevos elementos tales como los nombrados anteriormente. + Titulo de la revista
Relaciones de dependencia:
<<Paquete Negocio>>
Paquete G UI Paquete de Utilidad
Los paquetes se relacionan entre ellos y pueden la relación se llama de
dependencia, la cual significa que un elemento de un paquete requiere de + Ventana de Préstamos + Objeto ID
otro que pertenece a un paquete distinto. Es importante resaltar que las + Ventana de Devoluciones
+ Ventana de Reservas
dependencias no son transitivas. + Ventana de Mantenimiento
Las dependencias se representan con una flecha discontinua con inicio en

el paquete que depende del otro.
16 17
Sugerencias y consejos BILBIOGRAFIA
Los paquetes sólo existen para ayudar a organizar los elementos del
modelo. Si se tienen abstracciones que se manifiestan como objetos no Pressman, Roger (2005). Ingeniería de Software –Un enfoque práctico.
se deben utilizar paquetes. McGraw Hill. 6ª edición.
Un paquete bien estructurado: Rodríguez Díez, Gustavo. Arquitectura de Capas. Material del Curso
Metodologías de Diseño de Sistemas 2. ITESM Campus Monterrey, 2006
Es cohesivo
Booch, Rumbaugh y Jacobson (2006): El Lenguaje Unificado de Modelado.
2ª edición.
Está poco acoplado: exporta sólo aquellos elementos que otros
paquetes necesitan ver realmente.
Rumbaugh, Jacobson y Booch (2007): El Lenguaje Unificado de Modelado.
Manual de Referencia. 2ª edición.
No está profundamente anidado
Posee un conjunto equilibrado de elementos; no deben ser demasiado

grandes en relación con otros
18 19
ARQUITECTURA LÓGICA DEL SISTEMA
GLOSARIO
Diagrama de componentes: Describen los elementos físicos, códigos

fuentes, las librerías, tablas, archivos y ejecutables que se van a utilizar
para modelar un sistema de información.
Componente: Parte física de un sistema de información (modulo, base

de datos, programa ejecutable).
Subsistemas: Dividir en sistemas más pequeños el sistema actual.
Paquetes: Permite agrupar varios elementos, bien sea casos de uso,

clases o componentes.
Diagrama de paquetes: Se utilizan para organizar el sistema en

subsistemas, agrupando elementos del análisis, diseño o construcción y
detallando las relaciones de dependencia entre ellos.
Diagrama de despliegue: Modelan el hardware y/o conexiones físicas

entre los componentes hardware y software que se utilizara en la
implementación final del sistema y la relación entre sus componentes,
describen la configuración del sistema para su ejecución en un ambiente
del mundo real.
Nodo: Objetos físicos que existen en tiempo de ejecución, y que

representan algún tipo de recurso computacional (capacidad de memoria
y procesamiento).
20
Arquitectura Tecnológica del Sistema
Información
Programa: ANÁLISIS Y DESARROLLO DE SISTEMAS DE

INFORMACIÓN
Duración estimada de estudio (horas): 3 horas
Introducción..................................................................................3
1. Arquitectura física del sistema......................................................3
1.1. Diagramas de despliegue y/o distribución....................................3
1.1.1. Elementos de un diagrama de despliegue................................4
1.1.1.1. Nodo...............................................................................4
1.1.1.2. Conexión..........................................................................6
1.1.2. Componentes......................................................................7
1.1.3. Utilidades............................................................................9
1.1.3.1. Sistemas empotrados.........................................................9
1.1.3.2. Sistemas cliente-servidor: ...............................................10
1.1.3.3. Sistemas completamente distribuidos................................. 10
Recursos bibliográficos..................................................................11
Glosario......................................................................................12

Arquitectura Tecnológica del Sistema Información
Mapa Conceptual
El mercado.
2
Introducción
Apreciado aprendiz, este documento muestra los diferentes diagramas

que se utilizan para definir la arquitectura tecnológica (hardware) de un
sistema de información a desarrollar, de acuerdo con las necesidades del
cliente.
Estos diagramas se realizan en la fase de Diseño, los más utilizados por el

lenguaje UML (lenguaje de modelado unificado) son: el diagrama de nodos
y diagramas de despliegue (antes distribución), los cuales se presentan
en este material.
1. Arquitectura física del sistema
La Arquitectura física del sistema hace referencia a 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) que se utilizan para implementar el sistema
de información. Para describir la asignación del software al hardware se
utilizan los diagramas de despliegue, donde se detallarán entre otras
las especificaciones de las máquinas, capacidad de red, y requisitos de
hardware entre otros.
1.1. Diagramas de despliegue y/o distribución
Modelar la vista de despliegue de una aplicación la mayoría de veces

implica modelar la topología del hardware sobre el que se ejecuta el
sistema. Los diagramas de despliegue permiten modelar los nodos de un
sistema, ya que muestran la distribución física de los nodos que componen
en sistema. Aunque UML no es un lenguaje de especificación hardware de
propósito general, está diseñado para modelar muchos de los aspectos
hardware de un sistema a un nivel suficiente tales como la topología de
procesadores y dispositivos, para que el diseñador de la aplicación pueda
especificar la plataforma sobre la que se ejecuta el software del sistema y
que se pueda manejar la frontera entre el hardware y el software.
Esta vista cubre principalmente la distribución, entrega e instalación de

las partes que configuran un sistema físico.
3
Los diagramas de despliegue se utilizan para mostrar las relaciones físicas

entre los componentes hardware y software en el sistema final, también
se puede decir que muestran la disposición física de los distintos nodos
que componen un sistema y el reparto de los componentes sobre dichos
nodos.
Server
Corporate Phone Directory
Search Program Search Results
-Communication-
Client
Presentation Program
Los elementos utilizados para realizar un diagrama de despliegue son los

nodos (representados por un prisma), componentes y asociaciones.
1.1.1. Elementos de un diagrama de despliegue
1.1.1.1. Nodo
Un nodo es un objeto físico en tiempo de ejecución que representa un

recurso computacional, generalmente con memoria y capacidad de
procesamiento; debe tener un nombre representativo de la partición física
que simboliza, y lo distingue del resto de nodos.
Los nodos al representar objetos físicos que se utilizarán durante la

ejecución del sistema, pueden ser:
• Procesadores: Nodo con capacidad de procesamiento. Puede ejecutar

un componente.
4
• Dispositivos: Nodo sin capacidad de procesamiento. Representa

cualquier otro dispositivo hardware.
Un nodo se representa con la figura de un cubo, como puede verse a

continuación. Un nodo también puede ser una instancia, y se representa
por un nombre subrayado y lo preceden dos puntos (:) opcionalmente
Servidor:
Ventas copia
seguridad
antes de los dos puntos puede ir el tipo de nodo.
Los nodos también suelen llevar estereotipos que sirven para identificarlo,
como por ejemplo <<procesador>>, <<dispositivo>>, <<servidor>>,
<<pc>>, etc.
Estereotipo <<procesador>> Un Procesador es un

web Server hardware capaz de
ejecutar un programa
Nota
<<dispositivo>> Un dispositivo es un
Modem hardware sin poder
de cómputo
(modem, terminal, ect)
5
1.1.1.2. Conexión
Los nodos se conectan mediante asociaciones de comunicación las cuales

indican
algún tipo de ruta de comunicación entre los nodos. El tipo de comunicación

se identifica con un estereotipo que indica el protocolo de comunicación
o la red.
Los nodos intercambian objetos o envían mensajes a través de esta ruta.
Se representan con una línea continua que une ambos nodos y pueden
tener una etiqueta que indique el tipo de conexión. (Ejemplo: canal, red,
protocolo, etc.).
TCP/IP Servidor de Aplicaciones

Balanceador de
Carga
TCP/IP Servidor de Aplicaciones

Cliente
TCP/IP
6
1.1.2. Componentes
Para hacer más comprensible el diagrama de despliegue, dentro de

los nodos se debe incluir los componentes definidos para la aplicación,
que permitirán identificar en qué lugares particulares deben localizarse
los elementos de software que integran la aplicación. Los diagramas a
continuación presentan algunos ejemplos de representación.
• Componentes dentro del nodo:
Servidor de Aplicaciones
Comunicaciones
Acceso a Datos
• Componentes descritos externamente:
<<procesador>>
Servidor
<<App>> <<Libreria>> <<BD>>

AlqVideo.exe reportes.dll VideoClub
7
• Componentes a manera de artefactos dentro de los nodos:
Main Server
Business Logic
ActiveX Control
Java Bean
Web Server
top/ip
Work Station
Web Server
A continuación se presenta un ejemplo de diagrama de despliegue que

muestra el modelado de un sistema empresarial de compra y ventas
que utiliza servidores, y estaciones de trabajo que acceden a servidores
web para el registro de facturas de compras y ventas de productos.
Adicionalmente la capa de persistencia (datos) está ubicada en un servidor
para acceder a los datos.
Main Server
<<artifact>>
:Compra Productos
Servidor Empresarial
<<artifact>> <<artifact>>
:Proceso Pedido :Proceso Cliente
Servidor Datos
<<artifact>> <<artifact>> <<artifact>>
:Catalogo :Pedidos :Clientes
<<artifact>>
:Datos
8
1.1.3. Utilidades
Los diagramas de despliegue generalmente se utilizan para los siguientes

sistemas:
• Para modelar sistemas empotrados.
• Para modelar sistemas cliente/ servidor.
• Para modelar sistemas completamente distribuidos.
1.1.3.1. Sistemas empotrados.
Son sistemas que tienen software que controlan diferentes tipos de

dispositivos como motores, dispositivos sensoriales para entrada de
datos tales como sensores de movimiento, luminosidad y cambios de
temperatura, entre otros.
Son útiles para facilitar la comunicación entre los ingenieros de hardware

del proyecto y los desarrolladores de software y para razonar acerca de
los compromisos entre el hardware y el software.
Para modelar un sistema de este tipo hay que tener en cuenta que se
debe:
• Identificar los dispositivos y nodos propios del sistema.
• Integrar notas o iconos a los nodos que representan dispositivos poco

usuales.
PC Client CD-Rom Storage Unix Security

Device Server Device
9
1.1.3.2. Sistemas cliente-servidor:
En los diagramas de despliegue para sistemas cliente servidor se debe

especificar claramente la conectividad de la red y la ubicación de los
componentes dentro de los nodos. Una de las características de estos
sistemas es la separación de la interfaz gráfica de usuario que generalmente
es manejada por los clientes y la lógica de procesamiento y datos que
generalmente están ubicados en otros nodos.
<<PC>> <<Server>> <<Server>>
CLiente Servidor web Servidor de Datos
Browser IIS SMBD
HTTP TCP/IP
Lógica de presentación
Pagina HTML Base de Datos
Lógica de negocio Acceso a datos
Se recomienda construir un diagrama general y otros que detallen la

implementación de componentes en los nodos de manera detallada, pero
principalmente distinguir los nodos clientes y los nodos procesadores del
sistema.
1.1.3.3. Sistemas completamente distribuidos
Los diagramas de despliegue que se realizan para representar sistemas

distribuidos, normalmente incluyen varios niveles de servidores, en estos
casos el diseño del sistema requiere tener énfasis especial en el atributo
de mantenibilidad sobre el sistema, para permitir posteriores cambios en
la topología del sistema.
Como en estos sistemas los aspectos relacionados con la red son muy
importantes, se deben incluir dispositivos de comunicación y detalles
sobre su rendimiento. También en el diseño se incorporarán agrupaciones
lógicas de nodos que pueden presentarse a través de paquetes. Otro
aspecto importante son las bases de datos que estarán distribuidas por el
modelo y deben ser presentada esa organización adecuadamente.
Nota: a veces es frecuente representar la propia red como un nodo (por

ejemplo) Internet puede ser representada como un nodo). Se puede
representar una red de área local (LAN) o una red de área extendida WAN.
10
GLOSARIO
Artefacto: entidades físicas que se presentan en nodos, dispositivos y

ambientes de ejecución.
Dispositivo: componente que puede ser de acceso a datos, periférico de

entrada o salida de datos.
Nodo: objeto físico que existe en tiempo de ejecución, y que representan

algún tipo de recurso computacional (capacidad de memoria y
procesamiento).
Procesador: Circuito integrado que contiene los elementos de una Unidad

Central de Procesamiento.
Topología: Identifica la forma como se distribuyen y comunican los

diferentes elementos de un conjunto.
12
DISEÑAR LOS MECANISMOS DE
SEGURIDAD Y CONTROL
Introducción 3
1. FUNDAMENTOS DE SEGURIDAD 4
2. CONTROLES DE SEGURIDAD 9
3. SEGURIDAD EN PLATAFORMAS 11
3.1. Desde el punto del Control de Accesos 11
3.2. Desde el punto de Comunicaciones y Operaciones 13
4. SEGURIDAD DE SISTEMAS OPERATIVOS 14
BIBLIOGRAFÍA 16
GLOSARIO 17

DISEÑAR LOS MECANISMOS DE SEGURIDAD Y CONTROL
Mapa conceptual
2
Diseñar los Mecanismos de Seguridad y Control
DISEÑAR LOS MECANISMOS DE

SEGURIDAD Y CONTROL
INTRODUCCIÓN
Existen muchas definiciones del término seguridad. Simplificando, se

puede definir la seguridad como la "Característica que indica que un siste-
ma está libre de todo peligro, daño o riesgo." Villalón (2007).
En toda actividad se hace necesario, no solo planear y ejecutar las activi-

dades, sino efectuar procedimientos de control que vayan encaminados a
asegurar que dichas actividades han sido ejecutadas de acuerdo a los
parámetros que se habían establecido con anterioridad.
Es por ello, que para Evaluar la seguridad de los sistemas de información

se requiere que en las diferentes fases del ciclo de vida de los sistemas de
información, se planteen protocolos claros que permitan lograr un buen
nivel de calidad en el software.
Para el diseño de estos mecanismos de seguridad y control, se debe ir de

la mano de la seguridad informática, es por ello que en este tema tocare-
mos varios conceptos claves de este tema tan de moda actualmente, para
evitar caer en la “inseguridad informática”.
3
Algunos de ellos son:
Diseño de autorización: en este ítem se deben definir los roles, permi-

sos y privilegios de la aplicación.
Diseño de autenticación: Aquí se debe diseñar el modo en el que los

usuarios se van a autenticar, contemplando aspectos tales como los meca-
nismos o factores de autenticación con contraseñas, tokens, certificados,
etc. También, y dependiendo del tamaño de la organización, se puede
pensar en la posibilidad de integrar la autenticación con servicios externos
como LDAP, Radius o Active Directory y mecanismos que tendrá la aplica-
ción para evitar ataques de diccionario o de fuerza bruta.
Diseño de los mensajes de error y advertencia: Al diseñar estos men-

sajes se debe evitar que los mismos brinden demasiada información y que
ésta sea utilizada por atacantes.
Diseño de los mecanismos de protección de datos: Se debe contem-

plar el modo en el que se protegerá la información sensible en tránsito o
almacenada; según el caso, se puede definir la implementación de encrip-
ción, hashes o truncamiento de la información.
1. FUNDAMENTOS DE SEGURIDAD
Para definir estos dos términos se debe precisar que actualmente la per-
manencia y disponibilidad de los recursos en el planeta depende del apro-
vechamiento, manejo y conservación sostenible que se haga de ellos.
Para hablar de seguridad en las tecnologías de la información, se deben

tener en cuenta TRES PILARES fundamentales sobre el manejo de los
datos y la prestación de los servicios, los cuales se pueden relacionar con
la sigla C.I.A.
• Confidentiality (Confidencialidad): Indica que la información solo

es revelada a usuarios autorizados en tiempos precisos, es decir SOLO
en horarios asignados.
• Integrity (Integridad): Se refiere a la modificación de la información,

para ello se debe identificar muy bien los roles de los usuarios y así
definir los niveles de acceso para la manipulación de los datos.
4
• Availability (Disponibilidad): Se refiere a la disponibilidad de la

información. Para este proceso, desde el área técnica, se deben
establecer medidas de seguridad, cuyo objetivo fundamental es reducir
cualquier riesgo asociado, algunas de estas medidas de seguridad pueden ser:
• Identificación y autenticación de usuarios.

• Control de flujo de información.
• Confidencialidad.
• Integridad.
• No Autorización.
Estas medidas de seguridad se ponen en práctica mediante mecanismos de

protección como:
• Autenticación: Este término se refiere

a la verificación que se realiza a la Ingreso
identidad del usuario; este proceso Usuarios registrados
generalmente se lleva a cabo cuando se Tipo de documento de identidad:
ingresa al sistema, a la red o a cualquier
base de datos.
Número de documento:
Normalmente para ingresar a cualquier
sistema informático se utiliza un nombre
de usuario y una contraseña, aunque
actualmente se están utilizando técnicas Contraseña:
más seguras, como una tarjeta
magnética, o por huellas digitales, la
utilización de más de un método a la vez
disminuye el riesgo de ataques a la ¿Olvidé mi contraseña?
¿Mi usuario está
seguridad de la información. Bloqueado o Inactivo?
Al momento de construir la contraseña INGRESAR

de autenticación del sistema tenga en
cuenta las siguientes recomendaciones:
• Característica de la contraseña: Este aspecto se refiere al tamaño en

caracteres de la misma; en la medida que la contraseña contenga un
tamaño grande en caracteres y ésta sea compleja (conjunto de caracteres
variado, con minúsculas, mayúsculas y números) menor será la posibilidad
de ser adivinada y más difícil será burlar esta técnica.
5
• Confidencialidad: La contraseña solo la debe manejar el usuario,

no puede ser conocida por nadie más. Un error muy común, es que
los usuarios se prestan las contraseñas o que las escriben en un
papel y éste lo dejan pegado en el escritorio, lo que permite que
cualquier otro usuario conozca la contraseña, comprometiendo a la
empresa y al propio dueño.
Un problema muy común entre los usuarios, es que difícilmente

recuerdan contraseñas tan elaboradas. También es muy común que
se utilicen palabras muy obvias como el nombre, el apellido, el
nombre de usuario, el grupo musical preferido, la fecha de
nacimiento, etc., que facilitan la tarea a quién quiere ingresar al
sistema sin autorización.
En la actualidad existe una preocupación especial por las

conservación y el logro de un desarrollo sostenible pero aun se
requiere no solo de un nivel de conciencia e información, sino de
acciones puntuales y claras que apunten a resolver los problemas de
deterioro ambiental que cada ves son mas graves y ponen en riesgo
el equilibrio y la estabilidad de todos en el planeta.
•Control de Acceso: Todos los sistemas que no sean de libre acceso

deberán contar con control de acceso basado en roles. La autorización
deberá realizarse sobre el mismo sujeto que se autentica o también podrá
requerirse mayor información que permita obtener la autorización con
granularidad más fina, lo que implica que se adquieren muchos recursos
para administrar el bloqueo, pero se asegura la consistencia de los datos.
Tipos de Permisos
Registrar
Consultar
Modificar
Usuarios Rol
Procesar
6
• Cifrado de Datos: Mediante la evaluación de riesgos se identificará

el nivel requerido de protección, tomando en cuenta el tipo y la calidad
del algoritmo de cifrado utilizado y la longitud de las claves
criptográficas a utilizar.
101011
00
0101101
00
1011011
10
01
011010
• Firma Digital: Las firmas digitales proporcionan un medio de protección

de la autenticidad e integridad de los documentos electrónicos. Se
implementan mediante el uso de una técnica criptográfica sobre la base
de dos claves relacionadas de manera única, donde una clave,
denominada privada, se utiliza para crear una firma y la otra, denominada
pública, para verificarla.
JUAN
Hash resumen resumen

ENVIO
3
Mensaje 1 Cifrado del El resumen
Original. resumen con cifrado es la
clave privada. firma digital
del mensaje.
2
Mensaje
firmado.
resumen
6 5
Comparación Obtención del
de resultados. resumen de
RECEPCIÓN
mensaje.
MARIO resumen
Hash
resumen resumen
Descifrado del
4 resumen con
clave pública.
7
• Controles Criptográficos: Se utilizarán sistemas y técnicas

criptográficas para la protección de la información en base a un
análisis de riesgo efectuado, con el fin de asegurar una adecuada
protección de su confidencialidad e integridad.
Texto Claro Texto Claro
Texto
Encriptado
Algoritmo de Algoritmo de
Encriptación Desencriptación
• Servicios de No Repudio: Estos servicios se utilizarán cuando sea

necesario resolver disputas acerca de la ocurrencia de un evento o
acción. Su objetivo es proporcionar herramientas para evitar que
aquél que haya originado una transacción electrónica niegue haberla
efectuado.
Mensaje
Resumen del
mensaje Encriptación
resumen
Algoritmo de Comprobación
resumen de de firma
mensaje Clave privada (clave pública
del que envia del que envía)
8
2. CONTROLES DE SEGURIDAD
Para hablar de controles de seguridad es indispensable tomar como

referente la norma ISO27001- Sistema de Gestión de Seguridad de la
Información.
“La norma ISO 27001 define cómo organizar la seguridad de la

información en cualquier tipo de organización, con o sin fines de lucro,
privada o pública, pequeña o grande. Es posible afirmar que esta norma
constituye la base para la gestión de la seguridad de la información”
Esta norma se podría resumir mediante el siguiente grafico:
Políticas de
Seguridad
Organización de la
Desarrollo y Seguridad
Mantenimiento de
Sistemas
Gestión de Clasificación y
Comunicaciones y Control de Activos
Operaciones
Administración de Control de
la continuidad Accesos
del Negocio
Seguridad del
Personal
Cumplimiento
Gestión de Seguridad
Incidentes de Física
Seguridad
9
• Políticas de Seguridad: Busca proporcionar dirección y apoyo

gerencial para el proceso de seguridad de la información brindando los
lineamientos necesarios a cumplir para alcanzar los objetivos del
negocio.
• Organización de la Seguridad: Busca administrar la seguridad de la

información dentro de la organización mediante el establecimiento de un
marco gerencial para iniciar y controlar la implementación de la
seguridad de la información.
• Clasificación y Control de Activos: El objetivo es mantener una

adecuada protección de los activos de la organización.
• Control de Acceso: Se debe controlar el acceso a la información y los

procesos de negocio tomando como referencia los requerimientos de la
seguridad y los negocios. Actualmente se tienen disponibles recursos
como los firewalls, los VPN, las IPS y los dispositivos biométricos.
• Seguridad del Personal: Se centra en reducir los riesgos de error

humano, robo, fraude o uso inadecuado de instalaciones mediante la
definición de responsabilidades del personal con respecto a la seguridad
de la información y definición de criterios de selección del personal.
En este aspecto es importante incluir cláusulas de confidencialidad y

buen uso de la información en los contratos de trabajo.
• Seguridad Física y Ambiental: Se debe impedir accesos no

autorizados, daños e interferencia a las sedes y centros informáticos de
la empresa.
• Desarrollo y Mantenimiento de Sistemas: Se debe asegurar que la

aplicación pueda funcionar correctamente SIEMPRE y sin ataques de
intrusos, para ello se deben incorporar medidas de seguridad en la capa
de negocios.
• Gestión de Comunicaciones y Operaciones: Busca garantizar el

funcionamiento correcto y seguro de las instalaciones de procesamiento
de información, para ello se deben establecer responsabilidades para el
procedimiento y gestión de todas las instalaciones de procesamiento.
10
• Administración de la Continuidad de los Negocios: Se deben definir

estrategias para contrarrestar las interrupciones de las actividades
comerciales. Y proteger los procesos críticos de los negocios, de los
efectos de fallas significativas o desastres que puedan ocurrir.
• Cumplimiento: Se debe garantizar la compatibilidad del sistema de

gestión de seguridad de la información con las leyes del derecho civil y
penal.
• Gestión de Incidentes de Seguridad: Este tópico busca minimizar el

impacto causado por un riesgo de seguridad ya materializado, es decir
ocurrió una falla de seguridad. Para ello se deben definir procedimientos
muy claros que permitan realizar la investigación e identificar el origen
del riesgo.
Dependiendo del tamaño de la organización se habla de computación

forense y se manejan Equipos de respuesta a incidentes los cuales,
actualmente, toman como referente una serie de documentos de interés
general sobre seguridad de la información, conocidos como “serie 800
del NIST”, algunas de ellas son, NIST SP800-61 Y NIST SP800-94.
3. SEGURIDAD EN PLATAFORMAS
Los capítulos correspondientes al “control de Acceso” y “Gestión de

Comunicaciones y Operaciones” de la norma ISO 27001, son los
encargados de presentar algunos parámetros a tener en cuenta al
momento de definir protocolos para asegurar la seguridad de las
plataformas de la organización.
Es de vital importancia el análisis de riesgos a las plataformas para

minimizarlos adecuadamente con medidas de arquitectura de seguridad,
algunos de los aspectos a considerar son:
3.1. Desde el Punto del Control de Accesos, se deben definir

estrategias para:
• La administración de acceso a los usuarios.

• Control de acceso al Sistema Operativo.
• Control de acceso a las aplicaciones.
11
Recuerde que desde el momento que se inicia el proceso de definición de

requerimientos y el análisis de procesos y datos, se identifican diferentes
actores con sus respectivas responsabilidades, las cuales dependen del
cargo en la organización. Es de ese análisis de donde salen los perfiles y
permisos que van a configurarse en el sistema de información, los accesos
a los datos y los horarios en los cuales se van a utilizar las herramientas
informáticas.
Opc.1 Opc.1
ROL Opc.2 ROL Opc.2
‘XXXXX’ Opc.3 ‘YYYYY’ Opc.3
Opc.4 Opc.4
Opc.2 Opc.2 Opc.2 Opc.4 Opc.4 Opc.4

Opc.3 Opc.3 Opc.3
+
Opc.4
Se redactarán procedimientos necesarios para:
• Las claves deben tener fechas de inicio y caducidad de vigencia

definidas, de tal manera que sólo puedan ser utilizadas por el lapso
definido (se recomienda que no sea mayor a 12 meses).
• Almacenar claves, incluyendo la forma de acceso a las mismas por parte

de los usuarios autorizados.
• Cambiar o actualizar claves, incluyendo reglas sobre cuándo y cómo

deben cambiarse las claves.
• Distribuir claves de forma segura a los usuarios que corresponda,

incluyendo información sobre cómo deben activarse cuando se reciban.
12
• Generar claves para diferentes sistemas criptográficos y diferentes

aplicaciones.
• Recuperar claves pérdidas o alteradas como parte de la administración

de la continuidad de las actividades del Organismo, por ejemplo para la
recuperación de la información cifrada.
• Registrar y auditar las actividades relativas a la administración de claves.
• Revocar claves, incluyendo cómo deben retirarse o desactivarse las

mismas, por ejemplo cuando las claves están comprometidas o cuando
un usuario se desvincula del Organismo (en cuyo caso las claves
también deben archivarse).
3.2. Desde el Punto de Comunicaciones y Operaciones, se deben

tener en cuenta los siguientes parámetros:
• Control de cambio de las operaciones

• Procedimiento de manejo de incidentes
• Separación de funciones
• Separación de ambientes de desarrollo, pruebas y producción.
• Instalación de nuevos servidores
• Controles contra software malicioso
• Registro de actividades de los usuarios administradores
• Registro de fallas
• Eliminación de medios de almacenamiento
• Seguridad del comercio electrónico
• Seguridad del correo electrónico
• Seguridad en los equipos de oficina
En este aspecto es clave tener presente que al usuario (actor) del sistema
se le asignaran permisos dependiendo de los procesos que maneje.
13
Un ejemplo muy puntual es el aplicativo SOFIA PLUS, al actor aprendiz se

le permite Consultar constancias y horarios, Registrar (GUARDAR)
evidencias en las fechas estipuladas, Actualizar evidencias una vez el
instructor le ha configurado una nueva disponibilidad para la evidencia, y
no está permitido Eliminar nada.
El actor instructor puede Consultar las evidencias enviadas por el

aprendiz, Guardar y Actualizar el centro de calificaciones y tampoco
tiene permitido realizar Borrado de datos en el sistema.
Estos permisos se deben definir muy bien para asegurar los datos.
4. SEGURIDAD DE SISTEMAS OPERATIVOS
Los sistemas operativos (S.O) son el nivel base de seguridad para el

acceso de servicios informáticos en una empresa, ellos manejan un
modelo de autenticación, cuyo fin es el controlar el acceso principal a las
máquinas y permitir el uso de información de las mismas.
Los S.O tienen una serie de servicios que abren vulnerabilidades de

seguridad en las plataformas; estas vulnerabilidades pueden ser
controladas mediante configuraciones especiales en el Sistema Operativo.
Antes de realizar estas configuraciones, pensemos ¿Cómo combinar el

modelo de autenticación, servicios inseguros y controles de acceso de tal
manera que los riesgos resultantes sean mínimos y minimizados?
14
La respuesta se encuentra en la LINEA BASE DE SEGURIDAD (LBS),

donde se define la configuración de seguridad necesaria para que, sin el
uso de medidas adicionales de arquitectura de seguridad como firewalls e
IPS, los riesgos de seguridad de la plataforma sean minimizados.
La LBS incluye la revisión del modelo de autenticación, los servicios de

sistema operativo necesarios para la máquina y el esquema de permisos
para los recursos del sistema operativo. Existen herramientas que brindan
plantillas con algunas medidas para implantar en cada ambiente o sistema
operativo, algunas son:
NIST 800-68: Establece la línea base de seguridad para Windows XP

Bastille Linux: Establece la línea base de seguridad para Linux
Solaris Security toolkit: Establece la línea base de seguridad para Solaris.
Es importante aclarar que las plantillas se aplican de acuerdo con la

infraestructura de la empresa, y que las medidas de seguridad dependen
de la empresa.
Adicional a las medidas a implantar, en cada ambiente se deberán realizar

los controles necesarios para garantizar el control de acceso a los recursos
del sistema. Los sistemas deberán acceder únicamente a los archivos que
les pertenecen para garantizar la protección de los archivos en el disco
duro, ningún programa podrá acceder a archivos y/o carpetas en los
sistemas que no sean de su propiedad.
Esto deberá cumplirse independientemente del lugar donde se encuentren

alojadas las aplicaciones; que pueden ser, en Servidores de Aplicaciones o
en Computadoras de Escritorio. Los archivos propios de cada aplicación
deberán guardarse en lugares predefinidos.
Para el caso de las aplicaciones de escritorio, deberá definirse desde el

sistema operativo, un lugar con capacidad de guardar los archivos de las
aplicaciones (carpeta dedicada para la aplicación) con el fin de evitar que
se le deban dar derechos especiales para la ejecución de estos programas.
Se debe evitar la escritura de archivos en el disco duro en la ruta raíz.
En el caso de las aplicaciones alojadas en servidores deberá acordarse un

lugar donde la aplicación deberá acceder, Los servidores de aplicaciones
solo deberán acceder a los archivos que le pertenecen, y deberá
mantenerse el debido aislamiento entre las aplicaciones de un mismo
servidor de aplicaciones y entre los recursos que utilizan.
15
GLOSARIO
Autenticación: verificación que se realiza a la identidad del usuario.
Availability: Disponibilidad.
Confidentiality: Confidencialidad.
Directorio activo: Active Directory (AD) es el término que usa

Microsoft para referirse a su implementación de servicio de directorio en
una red distribuida de computadores. Su estructura jerárquica permite
mantener una serie de objetos relacionados con componentes de una
red, como usuarios, grupos de usuarios, permisos y asignación de
recursos y políticas de acceso.
Encripción: Es un proceso para convertir la información a un formato

más seguro. En otras palabras, los datos que están en un formato claro,
o sea entendible, se convierten mediante un proceso matemático a un
formato encriptado o codificado, o sea ininteligible. Una vez que llegan a
su destino, se decodifican para poder ser legibles de nuevo, se
desencriptan.
Firma digital: Proporcionan un medio de protección de la autenticidad

e integridad de los documentos electrónicos.
Granularidad fina: Implica que se adquieren muchos recursos para

administrar el bloqueo, pero se asegura la consistencia de los datos.
Hashes: Los hash o funciones de resumen son algoritmos que

consiguen crear a partir de una entrada (ya sea un texto, una
contraseña o un archivo, por ejemplo) una salida alfanumérica de
longitud normalmente fija que representa un resumen de toda la
información que se le ha dado (es decir, a partir de los datos de la
entrada crea una cadena que sólo puede volverse a crear con esos
mismos datos).
Integrity: Integridad.
17
ISO27001: Sistema de Gestión de Seguridad de la Información.
Ladp: Son las siglas de Lightweight Directory Access Protocol (en

español Protocolo Ligero de Acceso a Directorios) que hacen referencia a
un protocolo a nivel de aplicación que permite el acceso a un servicio de
directorio ordenado y distribuido para buscar diversa información en un
entorno de red.
L.B.S: Línea Base de Seguridad.
NIST: National Institute of Standards and Technology.
Radius: Acrónimo en inglés de Remote Authentication Dial-In User

Server, es un protocolo de autenticación y autorización para aplicaciones
de acceso a la red o movilidad IP. Utiliza el puerto 1812 UDP para
establecer sus conexiones.
Serie 800 del NIST: Serie de documentos de interés general sobre

seguridad de la información.
Sistemas Operativos: Son el nivel base de seguridad para el acceso de

servicios informáticos en una empresa.
Token: También llamado componente léxico, es una cadena de

caracteres que tiene un significado coherente en cierto lenguaje de
programación. Ejemplos de tokens podrían ser palabras clave (if, else,
while, int, ...), identificadores, números, signos, o un operador de varios
caracteres, (por ejemplo, :=).
18
CONVERSIÓN MER A MODELO RELACIONAL
1. INTRODUCCIÓN................................................................ 3
2. TRANSFORMACIÓN MER A MODELO RELACIONAL................... 3
3. REGLAS GENERALES DE TRANSFORMACIÓN.......................... 5
3.1 Transformación para las entidades y atributos...................... 5
3.2 Transformación para las Relaciones..................................... 7
4. TRANSFORMACIÓN MER- EXTENDIDO A RELACIONAL............. 11
5. CONSTRUCCIÓN TRANSFORMACIÓN MER- EXTENDIDO A

RELACIONAL......................................................................... 14
5.1 Relación especialización y generalización............................. 15
5.2 Relación Recursiva........................................................... 20
6. NORMALIZACIÓN............................................................... 23
6.1 Grados de Normalizacion................................................... 24

CONVERSIÓN MER A MODELO RELACIONAL
Mapa conceptual
2
Conversión Mer a Modelo Relacional
1. INTRODUCCIÓN
Almacenar información es uno de los usos más frecuentes que una

organización o empresa realiza día a día en un computador. La construcción
e implementación de bases de datos permite que la organización pueda
almacenar la información relevante del negocio a través de la construcción
de una base de datos que se realiza por medio del modelado de datos. En
este proceso están identificados tres modelos:
1. Modelo Entidad Relación (MER)
2. Modelo Relacional
3. Modelo Físico
En este material de consulta se presentará el proceso de construcción

de un modelo relacional a partir de un MER, lo cual se denomina:
“Transformación del MER a Modelo Relacional”.
La intención es que el aprendiz logre desarrollar y despertar su interés

en el modelado de datos, utilizando dicho modelo para la creación e
implementación de una base de datos relacional.
2. TRANSFORMACIÓN MER A MODELO RELACIONAL
Uno de los pasos iniciales para la construcción de una base de datos es el

modelado de ellos por medio de un Modelo Entidad Relación (MER), modelo
que permite por medio de entidades, atributos y relaciones acercarse a
una representación preliminar del diseño de una base de datos.
Luego de terminar un MER debe entrarse en el diseño de un modelo lógico,

el cual es llamado modelo relacional. La forma como se logra desarrollar
una base de datos relacional es a través del modelado y la metodología
de diseño de una base de datos puede estar enfocada en los siguientes 3
pasos:
3
Modelo Lógico
(Modelo relacional)
Permite identificar las
Permite llevar la
entidades, relaciones y
Permite llevar el MER a implementación de la
atributos que permiten
la expresión lógica que base de datos a un
dar solución al
incluye relaciones Gestor de base de
problema planteado.
lógicas entre los datos. datos.
Modelo conceptual
Modelo Físico
(MER)
En estos momentos se abordará el proceso de la construcción de un

modelo relacional a partir de un MER.
4
3. REGLAS GENERALES DE TRANSFORMACIÓN
La transformación de un Modelo Entidad Relación a Relacional, se puede

expresar mediante un esquema relacional o un modelo relacional.
Atributo 1 Atributo 2
Nombre
Identificador Candidata
El esquema relacional consta de palabras y relaciones mediante flechas

que indican la asociación de las entidades; el modelo relacional es un
dibujo que representa las tablas, atributos, llaves primarias y llaves
foráneas según la transformación realizada.
A continuación se explica detalladamente la transformación de un MER

según las reglas para las entidades y se expresa en esquema relacional y
modelo relacional.
NombreTabla(Identificador, Atributo1, Atributo2, Candidata)
3.1 Transformación para las entidades y atributos
• Entidades. Las entidades pasan a ser tablas

• Atributos. Los atributos pasan a ser columnas o atributos de la tabla.
• Identificadores principales. Pasan a ser claves primarias
• Identificadores candidatos. Pasan a ser claves candidatas.
La siguiente imagen ilustra los anteriores elementos:
5
Campo Nulo
Filo / Tupla
Celda / Campo
Llave Columna Llave

Primaria Atributo Foranea
PK FK
Por ejemplo:
Si se tiene la siguiente entidad Aprendiz se convierte entonces:
Apellido
Email
MER Nombre Aprendiz
Teléfono
TblAprendiz(AprCedula,AprNombre,AprApellido,
,AprTelefono,AprEmail)
Esquema
Relacional En este esquema la llave primaria se identifica
porque se encuentra subrayado el atributo que será
llave primaria
Modelo
Relacional
La tabla se llama TblAprendiz y la llave primaria se identifica
porque el nombre puede estar: subrayado, tener al frente el
estereotipo <<pk>> o una llave en color amarillo.
6
Nota: para garantizar unicidad de estilos recuerde que debe tener una
estandarización para nombrar las tablas y los atributos. Por ejemplo para
este caso la entidad aprendiz se convierte en la tabla aprendiz y es llamada
como TblAprendiz, el estilo de nombrado es iniciar con las tres primeras
letras Tbl para indicar que es tabla, seguido del nombre de la entidad e
iniciando con la primera letra en mayúscula.
Para el atributo Apellido, en el modelo relacional se convierte en AprApellido

indicando Apr que viene de la tabla Aprendiz y seguido del nombre del
atributo cada uno iniciando con Mayuscula la primera letra.
3.2 Transformación para las Relaciones
3.2.1 Relación Muchos a Muchos (M..M):
Esta relación se distingue en un MER porque su cardinalidad entre las dos

entidades esta designada por (M..M) o (N..M).
Ejemplo:
Nombre
Apellido
Email
Aprendiz M M
Nombre Curso
Matrícula
Complementario
Teléfono
Transformación Relación Muchos a Muchos (M..M):
Cuando se tiene una relación de este tipo se debe crear una nueva relación
(tabla) la relación se transforma en una tabla cuyos atributos son: los
atributos de la relación y las claves de las entidades relacionadas (que
pasarán a ser claves externas). La clave de la tabla la forman todas las
claves externas.
7
Transformación a Esquema Relacional
Cuando se hace la transformación a esquema relacional se debe tener un

esquema de nombrado para las tablas que se generaran, por ejemplo para
este caso la entidad aprendiz la tabla generada se denomina TblAprendiz,
anteponiéndole tres letras Tbl que indican que es una tabla; de la misma
manera para los atributos de esta entidad se le antepone las tres letras
Apr para indicar que son atributos de la tabla Aprendiz. Así se continuara
el estilo de nombrado para todos los casos de estudio y ejemplos de este
material.
TblAprendiz(AprCedula,AprNombre, AprApellido , ,AprTelefono,AprEmail)
TblCursoComp(CurCompCodigo,CurcompNombre)
TblRelAprCurso(AprCedula, CurCompCodigo)
Transformación a Modelo Relacional
Para realizar las transformaciones a modelo relacional puede utilizar

herramientas case, para estos ejemplos se ha utilizado DbDesigner, el
uso de ésta última se detallará en los videotutoriales que acompañan el
laboratorio correspondiente.
Se visualiza la nueva tabla donde las llaves primarias son a la vez llaves
foráneas, nótese que la cardinalidad de la relación está representada por
los rombos en blanco (1) o sombreados (M)
La nueva tabla creada es llamada TblRelAprendizCurComp, que tiene

incluida las dos llaves primarias de la tabla TblAprendiz y TblCurComp. Estas
llaves en la nueva tabla son llamadas llaves foráneas y son representadas
por un <fk> en el modelo.
8
Nota: las llaves primarias pasada a la nueva tabla se llaman llaves

foráneas.
3.2.2 Relación 1 a 1 (1..1):

entidades esta designada por (1..1).
Ejemplo:
Valor Fecha
Fecha Codigo
Tipo
1 1
Acta Inicio Genera Contrato
Descripcion
Transformación Relación 1 a 1 (1..1):
Cuando se tiene una relación de este tipo se envía la llave primaria de una
tabla a la otra tabla que participa de la relación, se envía la llave primaria
que se considere sea más relevante para enviar a la otra tabla.
Esquema Relacional
TblContrato(ConCodigo,ConValor,ConFecha,ConTipo).
TblActaInicio(ActCodigo,ActFecha,ActDescricpción,TblContratoConCodigo)
Para este ejemplo específico se ha pasado la llave primaria del contrato

(ConCodigo) a la tabla ActaInicio.
9
En la tabla TblActaInicio se incluye la clave primaria de la tabla TblContrato

(ConCodigo) quedando como llave foránea.
3.2.3 Relación 1 a Muchos (1..M):

entidades esta designada por (1..M).
Nombre
1 M
Programa
Ambiente Orientado
Formacion
Nombre
Transformación Relación 1 a Muchos (1..M):
Cuando se tiene una relación de este tipo se debe colocar o enviar la

llave primaria de la tabla que tiene en cardinalidad 1 a la tabla que tiene
cardinalidad M
Esquema relacional
TblAmbiente(AmbCodigo, AmbNombre)
TblProgramaFormacion(PrgForCodigo,PrgForNombre,AmbCodigo)
10
Visualice que La tabla TblAmbiente tiene como cardinalidad 1, por la tanto

la clave primaria de esta tabla es pasada a la tabla TblProgramaFormacion.
Rel_05
Note que la clave de la tabla TblAmbiente es pasada a la Tabla

TblProgramaFormacion la cual tiene su estereotipo <fk>.
4. TRANSFORMACIÓN MER- EXTENDIDO A RELACIONAL
A continuación se presenta un ejemplo de transformación de modelo

entidad relación a Relacional, que aplica las reglas descritas. Para este
ejemplo se toma una situación problémica y su modelo conceptual,
para lo cual se presenta la descripción del problema, el MER y el modelo
relacional resultante.
Descripción del Problema
En el SENA Regional Cauca del Centro de Teleinformática y Producción

industrial el coordinador requiere un sistema de información que permita
gestionar los horarios de los instructores pertenecientes a un centro de
formación que orientan formación profesional integral, tanto de planta
como de contrato, tenga en cuenta que un instructor de contrato puede
tener su relación de contrato por horas o asignación mensual.
Para lo cual es necesario conocer: Un instructor orienta formación

profesional (clase) en un programa de formación (el programa de formación
se refiere a las tecnologías o tecnólogos que ofrece el SENA), o en un
curso complementario (los cuales son cursos de duración de 2 a 3 meses
y solicitados por empresas del sector para capacitar a sus empleados).
Ambos: Programa de formación y complementarios son identificados por

un código.
11
Cuando un aprendiz se matricula a un programa de formación o curso

complementario tiene que durante toda su etapa lectiva (clase), cursar
competencias laborales.
Una competencia podría asemejarse como una asignatura que un aprendiz

debe cursar, pero para este caso siempre manejaremos el término
competencia.
Asignación de Competencias: Para asignar una competencia a un

instructor es necesario que esté legalmente contratado por el centro o que
tenga resolución de nombramiento y según su especialidad se le asignan
las competencias que va a orientar.
Ambientes de formación: Es el sitio específico (salón) donde se orientaran

las competencias asignadas. Cada ambiente tiene una codificación
asignada.
Reglas del negocio: Un instructor de contrato puede iniciar labores una

vez tenga el acta de inicio.
Tenga en cuenta que un instructor puede laborar de lunes a viernes de

7:00 a 10:00 p.m. de la noche, sábados y domingos de 8:00 a 6:00 p.m.
Un instructor puede orientar diferentes competencias en diferentes

programas de formación y cursos complementarios.
Un instructor no puede orientar una competencia en diferentes ambientes.
Dos o más instructores pueden orientar una o más competencias en un

mismo ambiente.
Usuarios: Los usuarios que interactúan con la base de datos
Coordinador académico
Instructores del SENA centro de Teleinformática y PI Regional Cauca
Informes por Usuario: Los informes necesarios para mostrar a los usuarios
identificados son:
12
• Visualizar el horario de todos los instructores de planta.

• Visualizar el horario de todos los instructores de contrato
• Visualizar el horario de un solo instructor.
• Visualizar el horario de todos los ambientes
• Visualizar el horario de un solo ambiente.
• Visualizar el horario de todos los programas de formación.
Modelo Entidad Relación
Codigo Valor Fecha

Codigo Fecha Descripcion
1 1
Tipo Contrato Genera Acta Inicio
1 Realiza M
Apellido
Nombre Apellido Email
Fecha
Codigo Fecha Fin Nombre Email Codigo
Inicio
1 M 1 1 M 1
Coordinador Gestiona Horario Asigna Instructor Pertenece Centro Nombre
Hora Cedula Direccion Direccion

Cedula Telefono Hora Fin
Inicio
Telefono
Nombre M Imparte M
TipoContrato 1 Tiene M
Codigo Codigo Nombre

Codigo Nombre
Nombre
1 M Programa M M
Ambiente Orientado Conforman Competencias
Formacion
Codigo
1 M
Matricula
Apellido
1 1
Asigna Email
Codigo Nombre
Nombre Aprendiz
Fecha
Hora_inicio HorarioAmbiente
M M Curso
Cedula Telefono Matricula
Complementario
Codigo Hora Fin
13
Modelo Relacional
TblContrato
TblActaInicio
ConCodigo: INTEGER
TblInstructor_InstCedula: INTEGER (FK) ActCodigo: INTEGER
TblCoordinador ConFecha: DATE TblIContato_ConCodigo: INTEGER (FK)
ConValor: DOUBLE ActFecha: DATE
CoorCedula: INTEGER
ConTipo: VARCHAR ActDescripción: VARCHAR
CoorNombre: VARCHAR
TblContrato_FKIndex1 TblActaInicio_FKIndex1
CoorApellido: VARCHAR
TblInstructor_InstCedula TblContrato_ConCodigo
CoorEmail: VARCHAR
CoorTelefono: INTEGER
TblTipoContrato
TipoCont: INTEGER
TipoNombre: VARCHAR
TblHorario
HorCodigo: INTEGER
TblInstructor_InstCedula: INTEGER (FK) TblProgramaFormacion
TblCoordinador_CoorCedula: INTEGER (FK)
InsDedula: INTEGER
HorfechaInicio: DATE
TblCentroFormacion_CentroCodigo: INTEGER (FK)
HorfechaFin: DATE
TblTipoContrato_TipoCodigo: INTEGER (FK)
HorHoraInicio: TIME
InsNombre: VARCHAR
HorHoraFin: TIME
InsApellido: VARCHAR
TblHorario_FKIndex1
InsEmail: VARCHAR TblIntructor_has_TblProgramaFormacion
TblCoordinador_CoorCedula
InsTelefono: INTEGER
TblHorario_FKIndex2 TblInstructor_InstCedula: INTEGER (FK)
TblInstructor_FKIndex1
TblInstructor_InstCedula TblAmbiente_AmbCodigo: INTEGER (FK)
TblTipoContrato_TipoCodigo
TblInstructor_has_TblProgramaFormación_FKIndex1
TblInstructor_FKIndex2
TblInstructor_InstCedula
TbllCentroFormacion_CentroCodigo
TblInstructor_has_TblProgramaFormación_FKIndex2
TblCentroFormación TblProgramaFormacion_ProgForCodigo
CentroCodigo: INTEGER
CentroNombre: VARCHAR
TblProgramaFormación
TblAmbiente ProgForCodigo: INTEGER

TblAmbiente_AmbCodigo: INTERGER (FK) TblProgramaFormación_has_TblCompetencias
AmbCodigo: INTEGER
ProgForNombre: INTEGER
AmbNombre: VARCHAR TblProgramaFormacion_ProgForCodigo: INTEGER (FK)
TblProgramaFormación_FKIndex1
TblAmbiente_AmbCodigo TblCompetencias_CompCodigo: INTEGER (FK)
TblCompetencias
TblHorarioAmbiente
TblMatriculaProgramaFormacion_Aprendiz
CompCodigo: INTEGER
HorAmbienteCodigo: INTEGER
TblProgramaFormacion_ProgForCodigo: INTEGER (FK) CompNombre: VARCHAR
TblAmbiente_AmbCodigo: INTEGER (FK)
HorAmbHoraInicio: TIME TblAprendiz_AprCedula: INTEGER (FK)
HorAmbHoraFin: TIME
HorAmbFecha: DATE
TblHorarioAmbiente_FKIndex1 TblMatriculaAprendizCurComp
TblAmbiente_AmbCodigo
TblCurComp_CurCompCodigo: INTEGER (FK)
TblAprendiz_AprCedula: INTEGER (FK)
TblCurComp
CurCompCodigo: INTEGER
CurCompNombre: VARCHAR
5. CONSTRUCCIÓN TRANSFORMACIÓN MER-

EXTENDIDO A RELACIONAL
El MER-Extendido ha sido creado para modelar otros tipos de relaciones

que no contempla el MER tradicional, los cuales son la generalización y
especialización, recursivas, inclusividad y exculsividad. A continuación se
muestra como se transforma cada una de estas relaciones a un modelo
relacional.
14
5.1 Relación especialización y generalización
Recordemos que en un MER-Extendido la generalización puede identificarse

como solapamiento, exclusividad, parcialidad o totalidad Figura 2,en estas
relaciones se encuentran entidad superclase o supertipos y entidades
subclase o subtipos,
SOLAPAMIENTO EXCLUSIVIDAD
Es_Un Es_Un
PARCIALIDAD TOTALIDAD
Es_Un Es_Un
Tipos de relación Generalización en un Mer Extendido
Existen cuatro opciones para la transformación de estos tipos de relaciones
1. Si es solapada y parcial: Crear una relación (tabla) para la

superclase, con sus atributoscorrespondientes y una relación (tabla)
para cada subclase con sus atributos incluyendo la clave primaria de la
superclase.
Generalización: esta representación es solapada y parcial, es decir una

persona puede ser profesor y estudiante a la vez y no es obligatorio que
asuma un subtipo.
15
Nombre
Persona
Puede
Ser
Salario PROFESOR ESTUDIANTE
Transformación Esquema Relacional
TblPersona(PerCedula,PerNombre)
TblPersona(PerCedula,PerNombre)
TblEstudiante(PerCedula)
Transformación Modelo Relacional
16
Observe que se creó la tabla persona con sus campos y se crearon las
tablas profesor y estudiante que heredan la llave primaria de la tabla
persona (PerCedula) y se convierte en una llave foránea.
2. Si es total: Se crea una relación (tabla) para las entidades subtipo,

donde cada una tiene los atributos del supertipo. No se crea una relación
para el supertipo.
Relación de totalidad: Obligatoriamente el empleado tiene que tomar

algún subtipo o administrador y/o docente.
Nombre
Empleado
Es_Un
ADMIN DOCENTE Escalafon
TblAdmin(AdminCedula,AdminNombre)
TblDocente(DocCedula,DocNombre)
Transformación Modelo Relacional
17
Observe que quedan dos tablas y se suprime la superclase (empleado),

cada una de las tablas hereda los atributos de la superclase y continúan
con los atributos propios.
3. Crear una relación (tabla) para almacenar los subtipos y la relación

(tabla) superclase. Teniendo en cuenta si es parcial, total, solapado o de
exclusividad; Miremos los dos casos que pueden darse en este sentido:
Caso 1: Si la descripción del problema indica que obligatoriamente

pertenece a un solo tipo es decir la relación es (total y exclusiva),
entonces se crea una relación para la SuperClase y otra para el tipo y se
le pasa la llave primaria de la tabla tipo a la tabla superclase.
DOCENTE
Tiene
Tipo
CATEDRATICO OCASIONAL PLANTA
En esta representación el docente puede tener un solo contrato (ocacional,

catedrático y planta) y obligatoriamente tiene que tener asociado un
contrato.
Transformación esquema relacional
TblTipocontrato(TipoCont,PerNombre)
TblDocente(DocCedula,TipoCont)
Observe que se crea una relación (tabla) que almacena los diferentes
tipos de contrato que un docente puede tener y adicionalmente a la tabla
TblDocente se la pasa la llave primaria de la tabla TipoContrato.
18
De esta manera se garantiza que cada docente obligatoriamente tenga un

solo tipo de contrato.
Transformación modelo relacional
Observe que se genera una nueva tabla llamada TblTipCont que almacenara
los diferentes tipos de contrato que puede tener un docente, para mayor
explicación esta tabla se almacenara con los siguientes datos.
TblTipCont
TipoContlD Tipo
1 Catedratico
2 Ocasional
3 Planta
Caso 2: Si la descripción del problema indica que puede pertenecer a

varios tipos es decir la relación es (parcial y solapada), entonces se crea
una relación para la SuperClase, otra para el tipo y se trata la relación
superclase y Tipo como una relación de muchos a muchos.
DOCENTE
Estudio
Es_Un
ESPECIALISTA MAGISTER DOCTOR
19
En esta representación un docente puede tener o no un tipo de estudio y

puede tenerlos todos a la vez.
TblDocente(DocCedula)
TblTipoEstudio(TipoEstlD,Tipo)
TblRelDocTipoEst(DocCedula,TipoEstld)
Observe que se crea una relacion (tabla) para la superclase y otra para
el tipo y se tratan estas dos relaciones como muchos a muchos, por lo
tanto se crea una tabla intermedia que contenga las llaves primarias de
las 2 tablas creadas.
5.2 Relación Recursiva
Las relaciones recursivas se tratan de la misma forma que las otras, sólo
que hay que imaginar que la tabla se divide en dos, una por cada rol.
Teniendo en cuenta eso, la solución es idéntica a lo ya resuelto en los
casos anteriores.
20
Atributo 1
Entidad
Relacion
Cardinalidad del rol 1
Cardinalidad del rol 2
La forma de imaginarse las relaciones recursivas para resolverlas

es:
Atributo
Atributo
Entidad Rol1 Relacion Entidad Rol2
Donde se “duplica la entidad” y se conservan las cardinalidades, luego

dependiendo de ésta, se aplica la regla de transformación correspondiente
teniendo las siguientes posibilidades:
1 caso: si la cardinalidad de la relación es de 1 a 1:
21
La entidad con Rol débil hereda el atributo de identificación de la otra

entidad y pasa a ser su llave foránea
2 caso: si la cardinalidad de la relación es de 1 a M :
O de M a 1:
En cualquiera de los casos, la entidad con relación muchos hereda el

atributo de identificación de la otra y esta se convierte en la llave foránea
3 caso: si la cardinalidad de la relación es de M a M:
Se genera en este caso una tercera tabla que relaciona las dos entidades,
está compuesta por los atributos de identificación que hereda de cada
entidad, más los atributos propios de la relación (si existieran).
22
6. Normalización
Una vez finalizado el proceso de conversión, se pueden presentar ciertos

inconvenientes tales como:
• Incapacidad de almacenar ciertos hechos.

• Redundancias y por tanto posibilidad de inconsistencias.
• Ambigüedades
• Perdida de información
• Perdida de ciertas restricciones de integridad que dan lugar a
interdependencia de los datos.
• Existencia de valores nulos.
• Aparición de estados inválidos en los proceso de manipulación.
La normalización es el proceso mediante el cual se transforman datos

complejos a un conjunto de estructuras de datos más pequeñas, que
además de ser más simples y más estables, son más fáciles de mantener.
También se puede entender la normalización como una serie de reglas que
sirven para ayudar a los diseñadores de bases de datos a desarrollar un
esquema que minimice los problemas de lógica. Cada regla está basada
en la que le antecede.
La normalización también hace las cosas fáciles de entender. Los seres

humanos tenemos la tendencia de simplificar las cosas al máximo. Lo
hacemos con casi todo, desde los animales hasta con los automóviles.
Vemos una imagen de gran tamaño y la hacemos más simple agrupando
cosas similares juntas. Las guías que la normalización provee crean el
marco de referencia para simplificar una estructura de datos compleja.
Otra ventaja de la normalización de base de datos es el consumo de

espacio. Una base de datos normalizada ocupa menos espacio en disco
que una no normalizada. Hay menos repetición de datos, lo que tiene
como consecuencia un mucho menor uso de espacio en disco.
Una vez obtenido el esquema relacional resultante del esquema entidad/

relación que representa la base de datos, normalmente tendremos una
buena base de datos. Pero otras veces, debido a fallos en el diseño o a
problemas indetectables, tendremos un esquema que puede producir una
base de datos que incorpore estos problemas:
23
Redundancia: Se llama así a los datos que se repiten continua e

innecesariamente por las tablas de las bases de datos. Cuando es excesiva
es evidente que el diseño hay que revisarlo, es el primer síntoma de
problemas y se detecta fácilmente.
Ambiguedades: Datos que no clarifican suficientemente el registro al

que representan. Los datos de cada registro podrían referirse a más de un
registro o incluso puede ser imposible saber a qué ejemplar exactamente
se están refiriendo. Es un problema muy grave y difícil de detectar.
Perdida Restricciones de Integridad: Normalmente debido a

dependencias funcionales. Más adelante se explica este problema. Se
arreglan fácilmente siguiendo una serie de pasos concretos.
Anomalías en operaciones de modificación de datos: El hecho de

que al insertar un solo elemento haya que repetir tuplas en una tabla para
variar unos pocos datos. O que eliminar un elemento suponga eliminar
varias tuplas necesariamente (por ejemplo que eliminar un cliente suponga
borrar seis o siete filas de la tabla de clientes, sería un error muy grave y
por lo tanto un diseño terrible).
El principio fundamental reside en que las tablas deben referirse a objetos

o situaciones muy concretas, relacionados exactamente con elementos
reconocibles por el sistema de información de forma inequívoca. Cada fila
de una tabla representa inequívocamente un elemento reconocible en el
sistema. Lo que ocurre es que conceptualmente es difícil agrupar esos
elementos correctamente.
En cualquier caso la mayor parte de problemas se agravan si no se sigue un

modelo conceptual y se decide crear directamente el esquema relacional.
En ese caso, el diseño tiene una garantía casi asegurada de funcionar mal.
Cuando aparecen los problemas enumerados, entonces se les puede

resolver usando reglas de normalización. Estas reglas suelen forzar la
división de una tabla en dos o más tablas para arreglar ese problema.
6.1 Grados de Normalizacion
Las formas normales corresponden a una teoría de normalización iniciada

por el propio Coddy continuada por otros autores (entre los que destacan
24
Boycey Fagin). Codd definió en 1970 la primera forma normal, desde ese
momento aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la
quinta forma normal.
Una tabla puede encontrarse en primera forma normal y no en segunda

forma normal, pero no al contrario. Es decir los números altos de formas
normales son más restrictivos (la quinta forma normal cumple todas las
anteriores).
6.1.1 Primera forma Normal (1FN)
Es una forma normal inherente al esquema relacional. Es decir toda tabla

realmente relacional la cumple.
Se dice que una tabla se encuentra en primera forma normal si impide

que un atributo de una tupla pueda tomar más de un valor. La tabla:
EMPLEADO
Identificación nombre departamento
12345 Pedro Murcia Sistemas
24680 Maria Dolores Rosas Contabilidad
12232 Juan José Muñoz Gerencia
Recursos Humanos
Lo que vemos es una tabla, pero no una tabla relacional (lo que en
terminología de bases de datos relacionales se llama relación). No cumple
la primera forma normal.
Podríamos mejorar para que cumpla la primera forma normal así:
Asignación de Competencias:
EMPLEADO
Identificación nombre departamento
12345 Pedro Murcia Sistemas
24680 María Dolores Rosas Contabilidad
12232 Juan José Muñoz Gerencia
12232 Juan José Muñoz Recursos Humanos
25
6.1.2 Segunda forma Normal (2FN)
Si una tabla está en primera forma normal y además cada atributo que no
sea clave, depende de forma funcional completa respecto de cualquiera
de las claves. Toda la clave principal debe hacer dependientes al resto de
atributos, si hay atributos que depende sólo de parte de la clave, entonces
esa parte de la clave y esos atributos formarán otra tabla.
Para asignar una competencia a un instructor es necesario que

esté legalmente contratado por el centro o que tenga resolución de
nombramiento y según su especialidad se le asignan las competencias
que va a orientar.
Alumno
identificacion codCurso nombre apellido nota
11 34 Sofia Loren 5
11 25 Sofía Loren 4
12 34 Marcos Pinto 3.5
13 25 Mireya Ruano 4.5
13 34 Mireya Ruano 5
Suponiendo que la identificación y el código del curso formen una clave

principal para esta tabla, sólo la nota tiene dependencia funcional completa.
El nombre y el apellido dependen de forma completa de la identificación.
La tabla no es 2FN, para convertirla debemos convertir esa tabla en dos
tablas así:
Alumno
identificacion nombre apellido
11 Sofia Loren
11 Sofía Loren
12 Marcos Pinto
13 Mireya Ruano
13 Mireya Ruano
NotasCurso
identificacion codCurso nota
26
11 34 5
11 25 4
12 34 3.5
13 25 4.5
13 34 5
6.1.3 Tercera forma Normal (3FN)
Ocurre cuando una tabla está en 2FN y además ningún atributo que no
sea clave depende transitivamente de las claves de la tabla. Es decir no
ocurre cuando algún atributo depende funcionalmente de atributos que
no son clave.
Ejemplo:
ALUMNOS
Identificación nombre apellido codCiudad ciudad
31 Pedro Picapiedra 100 Cali
32 Mónica Galindo 100 Cali
33 Amparo Grisales 101 Popayán
34 Roberto Gómez 102 Neiva
35 Blanca Moreno 102 Neiva
En la tabla anterior la ciudad depende funcionalmente del código de la

ciudad, lo que hace que no esté en 3FN. La manera de solucionar el
problema sería dividiendo la tabla en dos así:
En la primera tabla creamos la tabla Alumnos con los atributos propios de

él y solo le agregamos el atributo de codCiudad para saber a que ciudad
pertenece.
ALUMNOS
Identificación Nombre Apellido codCiudad

31 Pedro Picapiedra 100
32 Mónica Galindo 100
33 Amparo Grisales 101
27
34 Roberto Gómez 102

35 Blanca Moreno 102
La segunda tabla corresponde a la ciudad con sus atributos.
CIUDAD
codCiudad Ciudad
100 Cali
100 Cali
101 Popayán
102 Neiva
102 Neiva
6.1.4 Forma normal de Boyce-Cood(FNBC o BCFN)
Ocurre si una tabla está en tercera forma normal y además todo

determinante es una clave candidata. Ejemplo:
EMPRESA
Empleado Departamento Responsable
Pedro Dirección Juan
Mari Ventas Luis
Jose Mercadeo Erika
Rosa Ventas Roció
Blanca Gerencia Andrés
Julian Ventas Mireya
La cuestión es que un empleado puede trabajar en varios departamentos.

En cada departamento hay varios responsables, pero cada empleado sólo
tiene asignado uno. El detalle importante que no se ha tenido en cuenta,
es que el o la responsable sólo puede ser responsable en un departamento.
Este detalle último produce una dependencia funcional ya que:
Responsable Departamento
Por lo tanto hemos encontrado un determinante que no es clave candidata.

No está por tanto en FNBC. En este caso la redundancia ocurre por mala
28
selección de clave. La redundancia del departamento es completamente

evitable. La solución sería:
PERSONAL
Empleado Responsable
Pedro Juan
Mari Luis
Jose Erika
Rosa Roció
Blanca Andrés
Julian Mireya
RESPONSABLES
Responsable Departamento
Juan Dirección
Luis Ventas
Erika Mercadeo
Roció Ventas
Andrés Gerencia
Mireya Ventas
En las formas de Boyce-Codd hay que tener cuidado al descomponer ya

que se podría perder información por una mala descomposición.
6.1.5 Cuarta Forma Normal (4FN) Dependencias

Multievaluadas.
Dependencia Multivaluada
Para el resto de formas normales (las diseñadas por Fagin, mucho más
complejas), es importante definir este tipo de dependencia, que es distinta
de las funcionales. Si las funcionales eran la base de la segunda y tercera
forma normal (y de la de Boyce-Codd), éstas son la base de la cuarta
forma normal.
Una dependencia multivaluada de X sobre Y (es decir X->>Y), siendo X e Y

atributos de la misma tabla, ocurre cuando Y tiene un conjunto de valores
29
bien definidos sobre cualquier valor de X. Es decir, dado X sabremos los

posibles valores que puede tomar Y.
Se refiere a posibles valores (en plural) y se trata de que los valores de

ese atributo siempre son los mismos según el valor de un atributo y no
del otro.
Ejemplo:
Código Curso Instructor Material

11 Marta 1
11 Marta 2
11 Jaime 1
11 Jaime 2
12 Marta 1
12 Marta 2
12 Marta 3
La tabla cursos, instructores y materiales del curso. La tabla está en FNBC

ya que no hay dependencias transitivas y todos los atributos son clave
sin dependencia funcional hacia ellos. Sin embargo hay redundancia.
Los materiales se van a repetir para cualquier instructor dando cualquier
curso, ya que los instructores van a utilizar todos los materiales del curso
(de no ser así no habría ninguna redundancia).
Los materiales del curso dependen de forma multivaluada del curso y

no del instructor en una dependencia multivaluada (no hay dependencia
funcional ya que los posibles valores son varios). Para el Código curso e
Instructor podemos saber los materiales; pero lo sabemos por el curso
y no por el instructor.
Cuarta Forma Normal
Ocurre esta forma normal cuando una tabla está en forma normal de
BoyceCodd y toda dependencia multivaluada no trivial es una dependencia
funcional. Son triviales aquellas dependencias multivaluadas en las
que el conjunto formado por el determinante y el implicado no forman
la clave primaria de la tabla y además el implicado no forma parte del
determinante: es decir si X->>Y y además Y ¢ X y X,Y no es la clave de
30
la tabla, tenemos una dependencia multivaluada no trivial (como ocurre

en el ejemplo anterior).
Codigo Curso Material

11 1
11 2
12 1
12 2
12 3
Codigo Curso Instructor

11 Marta
11 Jaime
12 Marta
6.1.6 Quinta Forma Normal (5FN)
Dependencias de Join o de reunión
Una proyección de una tabla es la tabla resultante de tomar un

subconjunto de los atributos de una. Es decir una tabla formada por unas
cuantas columnas de la tabla original.
La operación JOIN procedente también del álgebra relacional, consiste

en formar una tabla con la unión de dos tablas. La tabla resultante estará
formada por la combinación de todas las columnas y filas de ambas,
excepto las columnas y filas repetidas.
Se dice que se tiene una tabla con dependencia de unión (o de tipo

JOIN) si se puede obtener esa tabla como resultado de combinar mediante
la operación JOIN varias proyecciones de la misma.
Quinta forma normal o forma normal de proyección-unión
Ocurre cuando una tabla está en 4FN y cada dependencia de unión (JOIN)
en ella es implicada por las claves candidatas.
31
Es la más compleja y polémica de todas. Polémica pues no está claro en

muchas ocasiones está muy claro que el paso a 5FN mejore la base de
datos. Fue definida también por Fagin. Es raro encontrarse este tipo de
problemas cuando la normalización llega a 4FN. Se deben a restricciones
semánticas especiales aplicadas sobre la tabla.
Ejemplo:
Proveedor Material Proyecto

1 1 2
1 2 1
2 1 1
1 1 1
Indican códigos de material suministrado por un proveedor y utilizado en

un determinado proyecto. Así vista la tabla, no permite ninguna proyección
en la que no perdamos datos. Pero si ocurre una restricción especial como
por ejemplo: Cuando un proveedor nos ha suministrado alguna vez
un determinado material, si ese material aparece en otro proyecto,
haremos que el proveedor anterior nos suministre también ese
material para el proyecto.
Eso ocurre en los datos como el proveedor número 1 nos suministró el

material número 1 para el proyecto 2 y en el proyecto 1 utilizamos el
material 1, aparecerá la tupla proveedor 1, material 1 y proyecto 1. Si un
nuevo proyecto necesitara el material 1, entonces habrá que pedirlo a los
proveedores 1 y 2 (ya que en otros proyectos los hemos utilizado)
La dependencia de reunión que produce esta restricción es muy difícil de

ver ya que es lejana. Para esa restricción esta proyección de tablas sería
válida:
Proveedor Material
1 1
1 2
2 1
32
Proveedor Proyecto
1 2
1 1
2 1
Material Proyecto
1 2
2 1
1 1
Esa descomposición no pierde valores en este caso, sabiendo que si el

proveedor nos suministra un material podremos relacionarle con todos
los proyectos que utilizan ese material. Una tabla no está en quinta forma
normal si hay una descomposición de esa tabla que muestre la misma
información que la original y esa descomposición no tenga como clave la
clave original de la tabla.
Forma Normal de Dominio Clave (FNDC)
Se la conoce más con sus siglas en inglés DKNF. Se trata de una forma
normal enunciada también por Faginen 1981 al darse cuenta de los
problemas de redundancia que ocurrían con algunos dominios. En este
caso no se basó en dependencias entre los datos, sino que se basó en
restricciones de dominio y restricciones de clave.
Restricciones de dominio: Se trata de la restricción que hace que

un determinado atributo obtenga sólo ciertos valores, los que estén de
acuerdo a la definición de un determinado dominio.
Restricción de clave: Es la restricción que permite que un atributo o un

conjunto de atributos forme una clave candidata.
Fagin dice que una tabla está en FNDC si toda restricción sobre la tabla es
consecuencia lógica de aplicar las restricciones de dominio y clave sobre
la misma. Fagin demostró que si esto ocurría la tabla incluso estaba en
5FN.
33
Ejemplo:
Alumno Nivel Logrado Nota

Rosa Muy alto y eficiente 9
María Muy alto aunque sin trabajo constante 9
Juan Alto con trabajo habitual 7
José Medio aunque con trabajo 5
Observando los datos de la tabla se observa que cuando la nota es igual

o superior a 9, en el nivel aparece la palabra alto, cuando es un 7 o un 8
medio, y un 5 o 6 sería medio. Es decir tenemos restricciones que no son
ni de dominio ni de clave en esa tabla. Lo lógico sería:
Alumno Nivel Logrado Nota

Rosa Eficiente 9
María Trabajo constante 9
Juan Trabajo habitual 7
José Trabajo Medio 5
Nivel Académico Nota Mínima Nota Máxima

Rosa 9 10
María 7 8,99
Juan 5 6,99
José 0 4,99
No se pierde información al diseñar las tablas de esta forma y de hecho

es más eficiente para la base de datos.
34
GLOSARIO
Modelo Entidad Relación: Modelo que consta de entidades, atributos

y relaciones y permite modelar conceptualmente una base de datos
relacional.
Modelo Entidad Relación Extendido: Modelo que permite modelar
nuevos tipos de relaciones, que no incluye el MER normal, tales como
agregación, generalización, exclusión e inclusión.
Modelo Relacional: Es un modelo que se obtiene de la transformación
de un MER, el cual contiene tablas, atributos y relaciones entre las tablas.
Tabla: Es la representación de una entidad en un modelo relacional, la
cual incluye atributos.
Campo: Es la representación de un atributo en un modelo relacional el
cual contiene su nombre, tipo de dato y descripción de si es clave primaria
o llave foránea.
Clave Primaria: Atributo único que no se repite, es identificado en un
modelo relacional porque esta subrayado o tiene el estereotipo <pk> y en
un esquema relacional se encuentra subrayado.
Calve Foránea: Atributo que es pasado a una tabla, según la regla de
transformación, se distingue en un modelo relacional porque tiene el
estereotipo <fk> y en un esquema relacional porque despliega una flecha
hacia la tabla de la cual proviene.
Relación: Es una asociación que existe entre dos entidades, en un MER
se distinguen tres tipos de relaciones: uno a uno (1..1), uno a muchos
(1..M) y muchos a muchos (M..M).
Esquema Relacional: Expresar el modelo relacional por medio un
esquema de palabras y asociaciones entre ellas (flechas) que representan
las relaciones.
1FN: Abreviatura de Primera Forma Normal.
2FN: Abreviatura de Segunda Forma Normal.
3FN: Abreviatura de Tercera Forma Normal.
4FN: Abreviatura de Cuarta Forma Normal.
5FN: Abreviatura de Quinta Forma Normal.
FNBC: Abreviatura de Froma Normal de BoyceCoodd.
35
LABORATORIO 7.
ARQUITECTURA LÓGICA DEL
SISTEMA DE INFORMACIÓN
GUÍA DE LABORATORIO Nº 7
Actividad de Proyecto: DETERMINAR LA ESTRUCTURA LÓGICA DEL

SISTEMA
Estructura de contenidos.
1. Introducción. 2
2. Objetivos. 2
3. Consideraciones. 3
4. Procedimiento. 4
5. Evidencias a entregar. 7

Arquitectura lógica del sistema de información
GUÍA DE LABORATORIO 7
Arquitectura lógica del

sistema de información
ACTIVIDAD DE PROYECTO
Determinar la estructura lógica

del sistema
INTRODUCCIÓN
1. INTRODUCCIÓN
La definición de la arquitectura lógica de un sistema se basa en modelos o

abstracciones de la realidad, donde se debe determinar la arquitectura
(modelo de capas) junto con diferentes diagramas de modelado UML. El
presente laboratorio tiene como intención que usted como aprendiz
aprenda a diseñar una arquitectura lógica del sistema a implementar.
2. OBJETIVOS
Objetivo general
Diseñar y construir la arquitectura lógica del sistema de información.
Objetivo específicos:
Construir arquitectura de un sistema de información.
Desarrollar diagramas para la arquitectura de un sistema de
información.
Aplicar los conceptos adquiridos en el desarrollo y diseño de arquitectura
de un sistema de información.
2
3. CONSIDERACIONES
Para el desarrollo del laboratorio es importante que tenga en cuenta los

siguientes aspectos relacionados en la tabla:
Ítem Descripción
Soporte Teórico • Revisar los Objetos de Contenido sobre

Arquitectura lógica de un sistema de información.
• Video tutoriales Desarrollo de diagramas
Arquitectura Lógica en Herramienta
WhiteStartUml.
Productos • Ejercicios de ejemplo que se muestran en los

requeridos objetos de contenido y en los Video tutoriales.
Productos Para el desarrollo del Laboratorio se requiere

requeridos tener instalada la Herramienta WhiteStartUml de
acuerdo con las instrucciones suministradas en el
Videotutorial correspondiente.
3
4. PROCEDIMIENTO
Para el Desarrollo de cada uno de los ejercicios tenga en cuenta el

siguiente procedimiento:
Para iniciar se requiere que usted primero planifique la estructura de

solución en una hoja de papel y después lo haga utilizando la herramienta
WhiteStartUml.
Pasos:
Leer detenidamente y por completo el enunciado, hasta que pueda

identificar claramente qué es lo que se está solicitando.
Identifique el tipo de arquitectura que va a desarrollar para el ejemplo
dado.
Repase como se realizan diagramas de componentes.
Retome el diagrama de clases, realizado en diseños anteriores.
Identifique los componentes que utilizara en la aplicación
Identifique si tiene interfaces
Repase como se realizan diagramas de paquetes.
Identifique los paquetes que tendrá la aplicación
¿Tiene claro cómo realizar cada diagrama?
Inicie la construcción de diagrama de componentes
Inicie la construcción de diagramas de paquetes.
Realice los diagramas de componentes y de paquetes en la herramienta
StarUml.
Guarde el archivo en una carpeta para después ser enviados al Tutor.
4
EL SIGUIENTE DIAGRAMA REPRESENTA

EL PROCEDIMIENTO GENERAL DEL LABORATORIO
Inicio
Leer el enunciado y entender

¿Que se requiere?
Identificar los datos que se

requieren para la interfaz
Identificar objetos que permiten

capturar cada uno de los datos
Hacer prototipo en hoja de papel
Hacer el diseño en las herramientas

Software Balsamiq Mockups o
Mockingbird
Agregue objetos de la herramienta

para el diseño de la interfaz teniendo
en cuenta el prototipo
¿Esta completa NO
la interfaz?
SI
Escanear el prototipo de la hoja

de papel
Guarde el archivo generado por

cada una de las herramientas
Exporte el archivo a formato PNG
FIN
5
EJERCICIOS:
Según los enunciados construya:

1. Arquitectura del sistema (n capas).
2. Diagrama de componentes
3. Diagrama de paquetes.
Enunciados
1. El propietario del centro médico “Humana Vivir” requiere un sistema

que permita administrar los datos básicos de las citas, consultas,
pacientes, diagnósticos e historias clínicas del centro médico. Un paciente
debe solicitar su cita vía web, donde el sistema asigna el médico que lo va
atender y le agenda la consulta; cuando el paciente asiste a la consulta se
le genera la historia clínica y el diagnostico junto con su tratamiento. Es
importante destacar que este sistema puede también utilizarse desde
dispositivos móviles.
2. En un centro de formación educativo necesitan un sistema web que

permita registrar los proyectos desarrollados por los docentes, cada
proyecto tiene un formato estándar que almacena la justificación,
objetivos, alcance y productos a obtener; así como también las líneas de
interés de cada proyecto. El objetivo principal es generar informes que los
directivos puedan acceder en cualquier momento desde sus dispositivos
móviles para generar estadísticas ya que deben reportar a las centrales los
avances y totalidades de proyectos que cada docente está generando
dentro de sus aulas de trabajo.
3. Una organización desea incorporar en su política de contratación

criterios de calidad del personal basados en la medición de sus habilidades
o competencias. La empresa desea medir las competencias intelectuales
de todos sus empleados y además desea conocer las competencias
emocionales de sus directivos (por ejemplo, la capacidad de trabajo en
grupo, la motivación, capacidad de liderazgo, etc), en el área de gestión
humana se cuenta con un paquete de pruebas para medir estas
competencias. Cada competencia está asociada a un conjunto de test que
permiten medirla. Un test puede medir una única competencia. Cada test
se identifica por un nombre y debe tener asociado un conjunto de
preguntas, una plantilla para su corrección así como el modo en que se
deberán interpretar los resultados.
Se requiere diseñar una aplicación que permita gestionar y medir las
6
competencias emocionales e intelectuales de los empleados, así como

también configurar los test junto con sus preguntas y respuestas. Al final
generar un informe con las medidas de las competencias emocionales e
intelectuales de los empleados. Recuerde que las competencias se miden
o califican con un numero llamado umbral.
5. EVIDENCIAS
• Archivo comprimido en formato .zip con los 3 archivos fuentes de cada

uno de los ejercicios realizados en la herramienta StartUml
• En un documento, mostrar evidencias mediante pantallazos de la

ejecución de cada uno de los ejercicios.
7
GLOSARIO
Arquitectura Software: Estructura del sistema que contiene sistemas, subsis-

temas, componentes e interfaces, así como las relaciones entre ellos.

LABORATORIO 8.
Diseño Modelo Relacional de una Base de Datos
Actividad de Proyecto: DETERMINAR LA ESTRUCTURA LÓGICA

DEL SISTEMA
1. Introducción. 2
2. Objetivos. 2
4. Procedimiento. 4
RECURSOS BIBLIOGRÁFICOS 8

Diseño Modelo Relacional

de una Base de Datos
Determinar la estructura
lógica del sistema.
INTRODUCCIÓN
1. INTRODUCCIÓN
Continuando con el Proceso de Construcción de la Base de Datos, después de

realizar el Modelo Entidad Relación, debemos construir el Modelo Lógico o
Modelo Relacional de la Base de Datos.
Para ello partimos del MER identificando las Entidades y Relaciones que se
convierten en Tablas, para que en cada una de ellas le agreguemos los
campos que la componen. De la misma forma un paso importante es
identificar el tipo de dato que se va almacenar para cada uno de los campos.
En el nombrado de tablas y campos se sugiere tener un estándar para

minimizar errores en la interpretación.
Como parte de los procesos de calidad en el desarrollo de software se requiere

de una documentación. En el Modelo Relacional podemos documentar las
tablas mediante una descripción de cada uno de los campos, permitiendo
generar el documento conocido como el Diccionario de Datos.
2. OBJETIVOS
• Emplear los símbolos y convenciones propias del Modelo Relacional para

la solución de ejercicios propuestos.
• Convertir Entidades y Relaciones del Modelo Entidad Relación a Tablas en
el Modelo Relacional.
2
• Identificar que tipo de datos se va almacenar en cada uno de los campos

de las tablas.
• Identificar claves primarias y foráneas.
• Identificar los campos que pueden participar en la construcción de las
relaciones entre las tablas.
• Utilizar un estándar para los nombres de las tablas y campos.
• Utilizar la Herramienta DBDesigner en el Diseño del Modelo Relacional de
una Base de Datos.
3. CONSIDERACIONES
Ítem Descripción
Soporte Teórico • Revisar el Objeto de Contenido Conversión

MER a Modelo Relacional.
• Seguir los procedimientos y explicaciones
proporcionadas en los Video tutoriales para el
Diseño del Modelo Relacional de una Base de
Datos utilizando la Herramienta DBDesigner.
Productos • Ejercicios de ejemplo que se muestran en los

requeridos Video Tutoriales.
• Desarrollo de Ejercicios en la Herramienta
DBDesigner.
• Lista con los ejercicios a realizar en este
laboratorio
Herramientas SW • Para el desarrollo del Laboratorio se requiere

tener instalada la Herramienta DBDesigner de
acuerdo con las indicaciones ofrecidas en el
videotutorial respectivo.
3
4. PROCEDIMIENTO

1. Analizar detenidamente cada uno de los MER a convertir a Modelo

Relacional
2. Convertir Entidades y Relaciones del MER a sus respectivas tablas del
Modelo Relacional. (Conversión en documento Word, pdf)
3. Identificar Claves Primarias Y Claves Foránes para cada Tabla.
4. En la Herramienta DBDesigner agregue tabla por tabla
5. Después vaya agregando los campos identificando el tipo adecuado
para cada uno de los campos.
6. Asigne un campo como Clave Primary.
7. Agregue las relaciones identificando los campos con los que va a
realizar la relación.
8. Verifique que al realizar una relación en una de las tablas el campo se
convierte en FK y en la tabla en la parte inferior agrega un índice.
9. Documentar cada uno de las tablas mediante los comentarios a cada
uno de los campos de las tablas.
10.Generar el Diccionario de datos en formato html para cada uno de
los ejercicios.
11.Guardar cada uno de los ejercicios en su respectivo archivo xml
generado por la herramienta DBDesigner.
12.Exportar a formato PNG cada Modelo Relacional.
4
DIAGRAMA
PASOS DISEÑO MODELO RELACIONAL
BASE DE DATOS
Inicio
Analizar detenidamente cada uno de los

1. MER a convertir a Modelo Relacional (MR).
Convertir Entidades y Relaciones del MER

2. a sus respectivas Tablas del
Modelo Relacional.
Identificar Claves Primarias y Foraneas

3. para cada una de las tablas.
En la Herramienta DBDesigner vaya

4. agregando Tabla por Tabla.
Agregue los campos a cada tabla y

5. configure cada campo asignado el tipo de
dato, si es No Nulo o es Autoincrementado.
6. Seleccione un campo como clave primary.
Agrege las Relaciones entre tablas

7. identificando los campos que participan
en cada una de ellas.
Verifique que en una de las tablas uno de

8. los campos de las relación se convierte
FK clave foranea.
Documentar cada una de las tablas

9. mediante los comentarios a cada uno de
los campos de las tablas.
Generar el Diccionario de datos en

10. formato html para cada uno de
los ejercicios.
Guardar cada uno de los ejercicios en su

11. respectivo archivo xml generado por
la herramienta DBDesigner.
12. Exporte el archivo a formato PNG.
FIN
5
EJERCICIOS:
Convertir a Modelo Relacional los siguientes ejercicios planteados en

Modelo Entidad Relación.
1. Tienda.
Cedula nombre id compra id producto
Referencia
N M
id cliente Cliente Compra Producto
dirección Fecha Valor Descripción Precio
2. Empresa de transporte de encomiendas.
identificacion
Placa
nombre
N:M
(0,m) (0,m) modelo
telefono Camionero Conduce Camion
potencia
direccion (0,1)
tipo
Distribuye 1:N
Codigo
(1,m)
1:M
descripcion (0,m) (1,1) Codigo
Paquete Destinado Ciudad
destinatario Nombre
direccion
6
3. Compañía de Seguros. Marca

Modelo
Placa
IDCompania
IDAutomovil tipos
NIT
FechaInicio 1:N Fecha
Experiación
Nombre Compañia Asegura Automovil Año

Fabricacion
Fecha Estado Costo

Fundacion
Valor Cilindraje SerialChasis
Representante Asegurado
Legal
N:M Involucra Pasajeros
IDAccidente Fecha
Accidente
Accidente
Automotores Lugar
Fatalidades Heridos
IDCategoria Nombre
4. Biblioteca.
Categoria
Fecha dias
1
IDUsuario Pertenece
Nombre IDEjemplar
Apellido N Prestamo M N Titulo
Autor
Usuario Ejemplar
Edicion
Genero
N Reserva M N Cantidad
Identificacion ISSN
Fecha Publicado
Ingreso
1
Fecha
IDEditorial Editorial Registro
Nombre
7
2. EVIDENCIAS
• Documento en formato .pdf, doc o docx con el nombre

Solucion_Laboratorio_Modelo_Relacional que contenga los 4 ejercicios
con la conversión del MER a Modelo Relacional, como lo muestra el
objeto de contenido Conversión del MER a Modelo Relacional.
• Diccionario de datos de cada uno de los ejercicios en formato html,
generado por la herramienta DBDesigner. Comprima los 4 en uno solo
en formato .zip.
• Documento en formato comprimido .zip, con los 4 archivos xml
generados por la herramienta DBDesigner.
8
RECURSOS BIBLIOGRÁFICOS
Clave Primaria: Atributo único que no se repite, es identificado en un modelo

relacional porque esta subrayado o tiene el estereotipo <pk>.
Clave Foránea: Atributo que es pasado a una tabla, según la regla de transfor-
mación, se distingue en un modelo relacional porque tiene el estereotipo <fk> y
en un esquema relacional porque despliega una flecha hacia la tabla de la cual
proviene.
Diccionario de Datos: Es aquel que contiene una descripción de las característi-

cas de cada uno de los datos representados por cada uno de los campos de una
tabla.
MR: Modelo Relacional de la Base de Datos

Modelo Relacional: Es un modelo que se obtiene de la transformación de un MER,
el cual contiene tablas, atributos y relaciones entre las tablas.
Tabla: Es la representación de una entidad en un modelo relacional, la cual inclu-

ye atributos.
9
LABORATORIO 9.
DISEÑO DE INTERFACES
Actividad de Proyecto: DETERMINAR LA ESTRUCTURA LÓGICA DEL

SISTEMA
1. Introducción. 2
2. Objetivos. 2
4. Procedimiento. 4

Diseño de interfaces
Diseño de Interfaces
Determinar la estructura lógica

del sistema
INTRODUCCIÓN
1. INTRODUCCIÓN
Una parte fundamental en todo software es la interfaz de usuario, quien es

la encargada de interactuar el software con el usuario. Se requiere
entonces Diseñar interfaces de acuerdo a los requerimientos del Sistema
pero siempre teniendo en cuenta a los usuarios. “Como dice el dicho, todo
entra por los ojos”. Por lo anterior es importante que las interfaces sean
funcionales, pero teniendo en cuenta los detalles de diseño y los atributos
de usabilidad.
En el presente laboratorio usted podrá iniciar ese proceso de diseño de

interfaces utilizando algunas herramientas disponibles en la web.
2. OBJETIVOS
Diseñar interfaces de usuario utilizando las herramientas balsamiq

mockups y gomockingbird.
2
3. CONSIDERACIONES
Para el desarrollo del laboratorio es importante que tenga en cuenta los

siguientes aspectos relacionados en la tabla:
Ítem Descripción
Soporte Teórico • Revisar los Objetos de Contenido sobre Diseño

de Interfaces de Usuario
• Tutorial Diseño de Interfaces mediante Balsamiq
Mockups.
• Tutorial Diseño de Interfaces mediante
gomockingbird.
Productos • Ejercicios ejemplo que se muestran en los

requeridos objetos de contenido y en los tutoriales.
Productos Para el desarrollo del Laboratorio se requiere tener

requeridos instalada la herramienta Balsamiq Mockups, su
proceso de descarga e instalación se suministra en
el tutorial correspondiente.
Para el desarrollo del ejercicio utilizando

gomockingbird se requiere tener conexión a
internet ya que es una herramienta de uso en
línea.
3
4. PROCEDIMIENTO

Leer detenidamente el enunciado de la actividad, donde le quede claro

qué es lo que se esta solicitando.
Identifique los datos de entrada y salida que son necesarios en el diseño
de la interfaz, investigue con otras fuentes de ser necesario.
Identifique que elemento grafico sirve para la captura de cada uno de los
datos.
Hacer el prototipo en una hoja de papel.
Hacer el diseño en la herramienta balsamiq mockups o gomockingbird.
En el diseño utilice los objetos de acuerdo al prototipo realizado en el
papel.
Escanear los prototipos de las hojas de papel para después ser enviado
al tutor.
Exporte los archivos a formato PNG.
Guarde el archivo en una carpeta para después ser enviados al Tutor.
4
EL SIGUIENTE DIAGRAMA REPRESENTA

EL PROCEDIMIENTO GENERAL DEL LABORATORIO
Inicio
Leer el enunciado y entender

¿Que se requiere?
Identificar los datos que se

requieren para la interfaz
Identificar objetos que permiten

capturar cada uno de los datos
Hacer prototipo en hoja de papel
Hacer el diseño en las herramientas

Software Balsamiq Mockups o
Mockingbird
Agregue objetos de la herramienta

para el diseño de la interfaz teniendo
en cuenta el prototipo
¿Esta completa NO
la interfaz?
SI
Escanear el prototipo de la hoja

de papel
Guarde el archivo generado por

cada una de las herramientas
Exporte el archivo a formato PNG
FIN
5
EJERCICIOS:
1. Diseñar la interfaz de usuario para la captura de los datos de un libro

que debe ser registrado en la Biblioteca.
2. Diseñar la Interfaz de usuario para la captura de los datos del registro

de una persona en un hotel.
3. Diseñar la interfaz de usuario para la captura de datos cuando una

persona compra un tiquete para un vuelo nacional.
4. Diseñar una interfaz de usuario para un sistema de votación que incluye

tres (3) candidatos, uno de ellos corresponde al voto en blanco.
Nota: Se deben crear 2 ejercicios utilizando la herramienta Balsamiq

mockups y los otros 2 ejercicios utilizando la herramienta Gomockingbird
6
5. EVIDENCIAS
• Para cada una de las actividades del laboratorio se requiere que usted
haga primero la interfaz en una hoja de papel. Cada una de ellas se debe
escanear. Al finalizar comprimir los archivos en uno solo, y enviar el archivo
comprimido.
• Cada uno de los archivos fuente generados por las herramientas de

diseño, deben ser almacenados y adicionalmente exportar cada uno de ellos
a formato PNG. Enviar todos estos archivos en uno solo en formato
comprimido.
7
GLOSARIO
Interfaz de usuario: Es el medio como el usuario puede comunicarse con una

máquina, un equipo o una computadora, y comprende todos los puntos de
contacto entre el usuario y el equipo.
Usabilidad: Se refiere a la facilidad con que las personas pueden utilizar una
herramienta particular o cualquier otro objeto fabricado por humanos con el fin de
alcanzar un objetivo concreto. La usabilidad también puede referirse al estudio de
los principios que hay tras la eficacia percibida de un objeto.

LABORATORIO 11.
Arquitectura Lógica del Sistema de Información
Actividad de Proyecto: ESPECIFICAR EL MODELO CONCEPTUAL DEL

SISTEMA DE INFROMACIÓN.
1. Introducción. 2
2. Objetivos. 2
4. Procedimiento. 3
GLOSARIO 7

Arquitectura Lógica del

Sistema de Información
Especificar el Modelo Conceptual del

Sistema de Infromación
INTRODUCCIÓN
1. INTRODUCCIÓN
La definición de la arquitectura hardware de un sistema de información se

basa en modelos o abstracciones de la realidad, donde desarrollan diferentes
diagramas de modelado UML (diagramas de despliegue). El presente
laboratorio tiene como intención que usted como aprendiz aprenda a diseñar
una arquitectura hardware del sistema de información a implementar.
2. OBJETIVOS
Objetivo general
• Diseñar y construir la arquitectura hardware del sistema de
información.
Objetivos específicos:
• Construir arquitectura hardware de un sistema de información.
• Desarrollar diagramas para la arquitectura hardware de un sistema
de información.
• Aplicar los conceptos adquiridos en el desarrollo y diseño de
arquitectura hardware de un sistema de información.
• Utilizar el programa StartUml para el desarrollo de los diferentes
diagramas para la arquitectura hardware de un sistema de
información.
2
3. CONSIDERACIONES
Ítem Descripción
Soporte Teórico • Revisar los Objetos de Contenido sobre

Arquitectura hardware de un sistema de
información.
• Video tutoriales Desarrollo de diagramas
Arquitectura Hardware en Herramienta
StartUml.
Productos • Ejercicios ejemplo que se muestran en los

requeridos objetos de contenido y en los Video tutoriales.
Herramientas SW Para el desarrollo del Laboratorio se requiere

tener instalada la Herramienta WhiteStartUml de
acuerdo con las instrucciones suministradas en el
Videotutorial correspondiente.
4. PROCEDIMIENTO

Para iniciar se requiere que usted primero planifique la estructura de

solución en una hoja de papel y después lo haga utilizando la herramienta
WhiteStartUml.
Pasos:
• Leer detenidamente y por completo el enunciado, hasta que pueda

identificar claramente qué es lo que se está solicitando.
• Repase como se realizan diagramas de despliegue.
• Identifique los nodos que utilizar en el diagrama (dispositivos físicos,
procesadores, computadores, u otros dispositivos).
• Modele los nodos identificados según los dispositivos y las relaciones
existentes.
• Repase como se realizan diagramas de despliegue en WhiteStartUml.
• Tiene claro como realizar cada diagrama?
3
• Inicie la construcción de diagrama de despliegue

• Realice los diagramas de despliegue en la herramienta WhiteStarUml.
• Guarde el archivo en una carpeta para después ser enviados al Tutor.
DIAGRAMA
PASOS PARA DESARROLLAR LA ARQUITECTURA

HARDWARE SISTEMA DE INFORMACIÓN.
Inicio
Leer el enunciado para

entender el problema
Repasar como realizar

Diagrama Despliegue
Identificar los Nodos

(dispositivos fisicos del sistema)
No Modele los nodos y relacione entre ellos
¿Tiene claro como

realizar los
diagramas?
Construya los diagramas en StartUML
FIN
4
Diagramas a desarrollar:
Según los enunciados construya el diagrama de despliegue según lo visto

en el objeto de aprendizaje arquitectura hardware del sistema de
información.
Enunciados
1. En una empresa se cuenta con un sistema de información con una

arquitectura de 3 capas, que manipula la seguridad de ingreso y salida
de los empleados de la empresa “Tecniques &+D” a través de
dispositivos de RFID; dicho sistema maneja el patrón vista controlador,
La vista corresponde a una aplicación web en Asp Net de Visual Studio
.Net y el cliente accede desde un browser de internet; su lógica de
datos está desarrollada con librerías de clase denominada Logica.dll y
la persistencia (base de datos) se encuentra con un servicio web xml
llamado Serviciobd.asmx.
2. El propietario del centro médico “Humana Vivir” cuenta con un sistema

que permite administrar los datos básicos de las citas, consultas,
pacientes, diagnósticos e historias clínicas del centro médico. Un
paciente debe solicitar su cita vía web, donde el sistema asigna el
médico que lo va atender y le agenda la consulta; para poder asistirá a
la consulta debe identificarse por medio de lector de huella digital,
cuando el paciente asiste a la consulta se le genera la historia clínica y
el diagnostico junto con su tratamiento. Es importante destacar que
este sistema permite gestionar las citas a través de dispositivos
móviles. El sistema está configurado sobre una arquitectura de 3 capas
con su lógica y base de datos en librerías tipo dll y su aplicación
desarrollada en Html5.
3. En una tienda de venta y compra de productos de canasta familiar se

cuenta con un sistema de información que maneja estaciones de
trabajo que permiten capturar las compras de un cliente, este sistema
está diseñado para generar las facturas de compra de un cliente y tiene
su base de datos almacenada en un servidor, el sistema tiene una
arquitectura de 3 capas.
5
5. EVIDENCIAS
• Archivo comprimido en formato .zip con los 3 archivos fuentes de cada

uno de los diagramas de despliegue que corresponde con los ejercicios
realizados en la herramienta WhiteStartUml.
• En un documento, describir cada una de las soluciones a los ejercicios

planteados incluyendo el diagrama de despliegue correspondiente.
6
GLOSARIO
Diagramas de despliegue: Modelan las conexiones físicas entre los

componentes hardware y software que se utilizara en la implementación final del
sistema y la relación entre sus componentes.
7

3 - Diseño

Cargado por

Información del documento

Descripción:

Título original

Derechos de autor

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Descripción:

Copyright:

3 - Diseño

Título original:

Cargado por

Descripción:

Copyright:

EL MERCADO

Programa: ANÁLISIS Y DESARROLLO DE SISTEMAS DE

Duración estimada de estudio (horas): 3 horas

FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

El término mercado se ha utilizado en los diversos entornos a través de

El mercado es un concepto y actividad que ha estado

El éxito y logro de cualquier emprendimiento o proyecto

Según el Diccionario de Marketing, de Cultural S.A., el mercado son “todos

En la antigüedad este intercambio comercial se daba a través del trueque,

De manera general se puede definir el concepto de mercado

Los esfuerzos principales cuando se habla

1 Diccionario de Marketing. Cultural S.A.

La categorización del mercado se hace necesaria en la medida en que

2.1. Según su ubicación geográfica

Corresponde a uno o más

Abarca todo el territorio

Corresponde a una zona

De Intercambio Se desarrolla en áreas de

2.2. Según los tipos de cliente

Mercado del Consumidor

Mercado del Productor o Industrial

Mercado del Revendedor

Mercado del Gobierno

2.3. Según el tipo de producto

Mercado de Productos o Bienes Mercado de Servicios

Corresponde a productos o bienes Actividades que se realizan para

2.4. Según el tipo de competencia

Mercado de Competencia Perfecta

Mercado de Competencia Imperfecta

3. Segmentación del mercado

La segmentación de mercados es un proceso que consiste en la división de

La segmentación permite identificar aspectos comunes entre los

Al segmentar adecuadamente el mercado se puede identificar los

En general se aplican técnicas estadísticas y una vez caracterizado se

Adicionalmente, se encuentran, al interior de los grupos segmentados, los

3.1. Características Generales

Los segmentos o subgrupos resultantes deben contar con las siguientes

Al interior de cada segmento el grupo de consumidores debe compartir

Cada segmento debe tener consumidores visiblemente distintos en cuanto

3.1.3. Viabilidad Monetaria.

Se requiere que el segmento tenga las dimensiones que permitan

3.1.4. Capacidad Operativa.

Considerar las características demográficas que faciliten su ubicación y

3.2. Criterios de Segmentación

Luego de decidir cuál será el segmento al que se dirigirán todas las

3.2.1. Segmentación por criterios

Los elementos que miden los segmentos

Las variables que intervienen para el análisis

3.2.2. Segmentación por criterios

Dentro de este contexto de segmentación,

El perfil que se encarga de analizar los comportamientos y preferencias de

Con el fin de fraccionar el mercado, es común que se usen varios criterios

3.2.3. Segmentación por criterios psicográficos

Al interior de este aspecto, se deben tener en cuenta la personalidad, el

estilo de vida, las actividades, las actitudes,

Este criterio de la segmentación alcanza

• Se compone de una compleja cuantificación.

• Es complicado identificar las necesidades básicas de los consumidores.

• Las porciones de consumidores resultantes pueden ser de difícil acceso.

3.2.4. Segmentación por criterios

Este tipo de fraccionamiento del mercado

La segmentación que se encarga de