Sistemas de Informacin II

Unidad I
Sistemas de Informacin II

Objetivo General del Curso:

El estudiante conocer y dominar mtodos de la ingeniera del software para el diseo,

construccin y documentacin de sistemas de informacin.
Unidad I Fundamentos del diseo
1.1 Panorama general del diseo fsico y lgico
La fase de diseo lgico y fsico del nuevo sistema, deben ser realizadas de manera secuencial. La
fase relacionada con el diseo fsico no puede empezar hasta que el diseo lgico est finalizado, las
dos fases de la etapa de diseo de sistemas tienen semejanzas y diferencias, ambas fases tienen el
propsito de encontrar una solucin que cumpla los requerimientos de los usuarios sin embargo,
mientras que el modelo lgico del nuevo sistema se centra en que funciones lgicas deben
implementarse en el sistema sin tener en cuenta ningn tipo de tecnologa, el modelo fsico describe
que tecnologa se va a utilizar para implementar la solucin propuesta en el modelo lgico, adems
de la manera en como ser aplicado. El modelo lgico del nuevo sistema representa las funciones
lgicas y la informacin de como se descompone el nuevo sistema, determinando qu debe hacerse
para cumplir con los requerimientos encontrados previamente, pero no cmo va a implementarse a
travs de la tecnologa. Por otra parte, el modelo fsico del nuevo sistema representa las funciones y
como se van a llevar a cabo en una plataforma tecnolgica especifica de hardware y de software
ahora bien, trataremos de detallar un poco ms estas dos fases:
Cuando el analista formula el diseo lgico, escribe las especificaciones detalladas del nuevo
sistema, es decir aquellas que describen sus caractersticas: salidas, entradas, archivos y bases de
datos de los procedimientos, todo en una forma que satisfaga los requerimientos del proyecto. El
conjunto formado por todas estas caractersticas recibe el nombre de especificaciones de diseo del
sistema.
El diseo lgico de un sistema de informacin es similar al proyecto de ingeniera de un automvil:
muestra las caractersticas ms sobresalientes y la relacin que guardan entre si. Los reportes y
salidas generadas por el analista son similares a los componentes de diseo del ingeniero. Los
procedimientos y datos se enlazan entre si para producir un sistema que trabaja. Al disear un
sistema de inventarios, por ejemplo, las especificaciones del mismo incluyen definiciones de reportes
y pantallas de presentacin que describen las existencias disponibles, el abastecimiento y retiro de
artculos, y el resumen de transacciones realizadas durante, por ejemplo, un mes de operacin. El
diseo lgico tambin especifica los formatos de entrada y la distribucin de la salida en pantalla para
todas las transacciones y archivos que son necesarios para dar mantenimiento a los datos del
inventario, a los detalles de las transacciones y a los datos de los proveedores. Las especificaciones
de procedimientos describen los mtodos utilizados para ingresar datos en el sistema, copiar archivos
y detectar problemas, si stos se presentaran.
La construccin fsica, que es la siguiente actividad despus del diseo lgico, produce el software,
los archivos y un sistema que funciona. Las especificaciones de diseo indican a los programadores
lo que el sistema debe hacer. A su vez, los programadores escriben programas que aceptan la
entrada proporcionada por los usuarios, procesan los datos, producen los reportes y guardan los
datos en los archivos.
El diseo fsico para el sistema de inventarios ya mencionado, est formado por instrucciones de
programa, escritas en un lenguaje de programacin. Estos pasos revisan los registros de mercanca
en existencia utilizando para ello los datos asentados en la transaccin, imprimen los reportes y
1

Sistemas de Informacin II

Unidad I

guardan los datos. El analista especifica los algoritmos necesarios para cambiar las cantidades de
mercanca en existencia. Durante la construccin fsica, los programadores escriben las instrucciones
necesarias del programa para calcular los cambios y producir los resultados.
Ejercicio 1.1_1
De manera individual deber realizar una aportacin propia significativa para los conceptos de diseo
fsico y lgico, esta se entregara escrita a mano y en una hoja tamao carta, puede discutir el tema con
los integrantes de su equipo, pero la aportacin es individual.

1.2 Conceptos del diseo de sistemas

El diseo puede definirse como el acto de delinear, planear, bosquejar y disponer muchos elementos
separados, reunindolos en un conjunto viable y unificado. Mientras que en la fase de anlisis de
sistemas se responde a preguntas tales como qu est haciendo el sistema? Y qu debera hacer
para satisfacer las necesidades de los usuarios?, La fase de diseo se ocupa de cmo debe
desarrollarse el sistema para que pueda satisfacer esas necesidades? Durante el proceso de diseo,
el analista plantea soluciones alternativas y finalmente determina cul es la mejor. La fase de diseo
es de naturaleza tcnica, hasta el punto que el analista debe responder esta pregunta"Cmo vamos
a hacerlo?".Por otra parte, el diseo tambin es un arte creativa, hasta el punto de que el analista se
pregunta continuamente: qu ocurrir si pasa esto? y por qu no hacemos esto? El diseo es una
solucin: la conversin de los requerimientos en formas que los satisfagan. El diseo determina el
xito del sistema. A travs del diseo, los analistas de sistemas pueden tener gran influencia sobre la
efectividad del usuario, ya sea para el manejo de transacciones o de procesos administrativos, en
trminos generales el diseo construye una solucin con base en el anlisis sin embargo en el diseo
se encuentran constantemente factores que podran asegurar el xito del nuevo sistema.
1.2.1

Acoplamiento y coherencia.

Muchos aspectos de la modularizacin pueden ser comprendidos solo si se examinan mdulos en

relacin con otros. En principio veremos el concepto de independencia: diremos que dos mdulos son
totalmente independientes si ambos pueden funcionar completamente sin la presencia del otro. Esto
implica que no existen interconexiones entre los mdulos, y que se tiene un valor cero en la escala de
dependencia. En general veremos que a mayor nmero de interconexiones entre dos mdulos, se
tiene una menor independencia.
El concepto de independencia funcional es una derivacin directa del de modularidad y de los
conceptos de abstraccin y ocultamiento de la informacin. La cuestin aqu es: cuanto debe
conocerse acerca de un mdulo para poder comprender otro mdulo? Cuanto ms debamos conocer
acerca del mdulo B para poder comprender el mdulo A, menos independientes sern A de B.
La simple cantidad de conexiones entre mdulos, no es una medida completa de la independencia
funcional. La dependencia funcional se mide con dos criterios cualitativos: acoplamiento y cohesin.
El termino acoplamiento es un concepto abstracto que nos indica el grado de interdependencia entre
mdulos, se dice que mdulos altamente acoplados estarn unidos por fuertes interconexiones,
mdulos dbilmente acoplados tendrn pocas y dbiles interconexiones, en tanto que los mdulos
desacoplados no tendrn interconexiones entre ellos y sern independientes.
Ejercicio 1.2.1_2
El alumno deber construir un ejemplo que muestre de manera grfica lo expuesto en el prrafo anterior
y escribir cuando menos dos causas que se dan en el mundo real a nivel funcionamiento de mdulos
dentro del desarrollo de un sistema para cada uno de los conceptos de acoplamiento.

En la prctica podemos materializarlo como la probabilidad de que en la codificacin, depuracin, o

modificacin de un determinado mdulo, el programador necesite tomar conocimiento acerca de
2

Sistemas de Informacin II

Unidad I

partes de otro mdulo. Si dos mdulos estn fuertemente acoplados, existe una alta probabilidad de
que el programador necesite conocer uno de ellos en orden de intentar realizar modificaciones al otro,
claramente, el costo total del sistema se ver fuertemente influenciado por el grado de acoplamiento
entre los mdulos, de esta forma podemos entender el trmino acoplamiento como una medida de
interconexin entre mdulos dentro de una estructura de software, bsicamente el acoplamiento
depende de la complejidad de interconexin entre los mdulos, el punto donde se realiza una entrada
o referencia a un mdulo, y los datos que pasan a travs de la interfaz. En el diseo del software,
intentamos conseguir el acoplamiento ms bajo posible. Una conectividad sencilla entre los mdulos
da como resultado un software ms fcil de entender y menos propenso a tener un efecto ola
causado cuando ocurren errores en un lugar y se propagan por el sistema.

Figura 1.2.1.1 Tipos de acoplamiento

La Figura 1.2.1.1 proporciona ejemplos de diferentes tipos de acoplamiento de mdulos. Los mdulos
a y d son subordinados a mdulos diferentes. Ninguno est relacionado y por tanto no ocurre un
acoplamiento directo. El mdulo c es subordinado al mdulo a y se accede a l mediante una lista de
argumentos por la que pasan los datos. Siempre que tengamos una lista convencional simple de
argumentos (es decir, el paso de datos; la existencia de correspondencia uno a uno entre elementos),
se presenta un acoplamiento bajo (llamado acoplamiento de datos) en esta parte de la estructura.
Una variacin del acoplamiento de datos, llamado acoplamiento de marca (stamp), se da cuando una
parte de la estructura de datos (en vez de argumentos simples) se pasa a travs de la interfaz. Esto
ocurre entre los mdulos b y a. En niveles moderados el acoplamiento se caracteriza por el paso de
control entre mdulos. El acoplamiento de control es muy comn en la mayora de los diseos de
software y se muestra en la Figura 1.2.1.1 en donde un indicador de control (una variable que
controla las decisiones en un mdulo superior o subordinado) se pasa entre los mdulos d y e.
Cuando los mdulos estn atados a un entorno externo al software se dan niveles relativamente altos
de acoplamiento. Por ejemplo, la E/S acopla un mdulo a dispositivos, formatos y protocolos de
comunicacin. El acoplamiento externo es esencial, pero deber limitarse a unos pocos mdulos en
una estructura. Tambin aparece un acoplamiento alto cuando varios mdulos hacen referencia a un
rea global de datos. El acoplamiento comn, tal y como se denomina este caso, se muestra en los
mdulos c, g y k ya que estos acceden a elementos de datos en un rea global (por ejemplo, un
archivo de disco o un rea de memoria totalmente accesible). El mdulo c inicializa el elemento. Ms
tarde el mdulo g vuelve a calcular el elemento y lo actualiza. Supongamos que se produce un error y
que g actualiza el elemento incorrectamente. Mucho ms adelante en el procesamiento, el mdulo k
lee el elemento, intenta procesarlo y falla, haciendo que se interrumpa el sistema. El diagnstico de
problemas en estructuras con acoplamiento comn es costoso en tiempo y es difcil. Sin embargo,
esto no significa necesariamente que el uso de datos globales sea malo. Significa que el diseador
del software deber ser consciente de las consecuencias posibles del acoplamiento comn y tener
especial cuidado de prevenir sede ellos. El grado ms alto de acoplamiento, acoplamiento de
contenido, se da cuando un mdulo hace uso de datos o de informacin de control mantenidos dentro
de los lmites de otro mdulo. En segundo lugar, el acoplamiento de contenido ocurre cuando se
realizan bifurcaciones a mitad de mdulo. Este modo de acoplamiento puede y deber evitarse.
3

Sistemas de Informacin II

Unidad I

Ejercicio 1.2.1_3
Construir un mapa mental en donde se ejemplifique la explicacin del prrafo anterior referente a los
tipos de acoplamiento, el ejercicio podr hacerse en equipo y se entregar un solo mapa, cada
integrante debe conservar una copia del mismo para futuras revisiones.

Cohesin
La cohesin es una extensin natural del concepto de ocultacin de informacin, un mdulo cohesivo
lleva a cabo una sola tarea dentro de un procedimiento de software, lo cual requiere poca interaccin
con los procedimientos que se llevan a cabo en otras partes de un programa. Dicho de manera
sencilla, un mdulo cohesivo deber (idealmente) hacer una sola cosa. La cohesin se puede
representar como un espectro. Siempre debemos buscar la cohesin ms alta, aunque la parte
media del espectro suele ser aceptable. La escala de cohesin no es lineal. Es decir, la parte baja de
la cohesin es mucho peor que el rango medio, que es casi tan bueno como la parte alta de la
escala. En la prctica, un diseador no tiene que preocuparse de categorizar la cohesin en un
mdulo especfico, ms bien, se deber entender el concepto global, y as se debern evitar los
niveles bajos de cohesin al disear los cdigos, en la parte inferior (y no deseable) del espectro,
encontraremos un mdulo que lleva a cabo un conjunto de tareas que se relacionan con otras
dbilmente, si es que tienen algo que ver. Tales mdulos se denominan coincidentalmente cohesivos.
Un mdulo que realiza tareas relacionadas lgicamente (por ejemplo, un mdulo que produce todas
las salidas independientemente del tipo) es lgicamente cohesivo. Cuando un mdulo contiene tareas
que estn relacionadas entre s por el hecho de que todas deben ser ejecutadas en el mismo
intervalo de tiempo, el mdulo muestra cohesin temporal. Como ejemplo de baja cohesin, tomemos
en consideracin un mdulo que lleva a cabo un procesamiento de errores de un paquete de anlisis
de ingeniera. El mdulo es invocado cuando los datos calculados exceden los lmites
preestablecidos. Se realizan las tareas siguientes:
(1) calcula los datos complementarios basados en los datos calculados originalmente;
(2) produce un informe de errores (con contenido grfico) en la estacin de trabajo del usuario;
(3) realiza los clculos de seguimiento que haya pedido el usuario;
(4) actualiza una base de datos, y
(5) activa un men de seleccin para el siguiente procesamiento.
Aunque las tareas anterior es estn poco relacionadas, cada una es una entidad funcional
independiente que podr realizarse mejor como un mdulo separado. La combinacin de funcin es
en un solo mdulo puede servir slo para incrementarla probabilidad de propagacin de errores
cuando se hace una modificacin a alguna de las tareas procedimental es anteriormente
mencionadas.
Los niveles moderados de cohesin estn relativamente cerca unos de otros en la escala de
independencia modular. Cuando los elementos de procesamiento de un mdulo estn relacionados, y
deben ejecutarse en un orden especfico, existe cohesin procedimental. Cuando todos los elementos
de procesamiento se centran en un rea de una estructura de datos, tenemos presente una cohesin
de comunicacin. Una cohesin alta se caracteriza por un mdulo que realiza una nica tarea. Como
ya se ha mencionado anteriormente, no es necesario determinar el nivel preciso de cohesin, ms
bien, es importante intentar conseguir una cohesin alta y reconocer cuando hay poca cohesin para
modificar el diseo del software y conseguir una mayor independencia funcional.
Ejercicio 1.2.1_4
El alumno deber elaborar de manera individual una definicin del termino Cohesin en un prrafo no
mayor de tres lneas.

Sistemas de Informacin II
1.2.2

Unidad I

Arquitectura del software

La arquitectura del software alude a la estructura global del software y a las formas en que la
estructura proporciona la integridad conceptual de un sistema. En su forma ms simple, la
arquitectura es la estructura jerrquica de los componentes del programa (mdulos), la manera en
que los componentes interactan y la estructura de datos que van a utilizar los componentes. Sin
embargo, en un sentido ms amplio, los componentes se pueden generalizar para representar los
elementos principales del sistema y sus interacciones. Un objetivo del diseo del software es derivar
una representacin arquitectnica de un sistema. Esta representacin sirve como marco de trabajo
desde donde se llevan a cabo actividades de diseo ms detalladas. Un conjunto de patrones
arquitectnicos permiten que el ingeniero del software reutilice los conceptos a nivel de diseo.
Shaw y Garlan estudiosos del tema, describen un conjunto de propiedades que debern especificarse
como parte de un diseo arquitectnico:
Propiedades estructurales. Este aspecto de la representacin del diseo arquitectnico define los
componentes de un sistema (por ejemplo, mdulos, objetos, filtros) y la manera en que esos
componentes se empaquetan e interactan unos con otros. Por ejemplo, los objetos se empaquetan
para encapsular tanto los datos como el procesamiento que manipula los datos e interactan
mediante la invocacin de mtodos
Propiedades extra-funcionales. La descripcin del diseo arquitectnico deber ocuparse de cmo la
arquitectura de diseo consigue los requisitos para el rendimiento, capacidad, fiabilidad, seguridad,
capacidad de adaptacin y otras caractersticas del sistema.
Familias de sistemas relacionados. El diseo arquitectnico deber dibujarse sobre patrones
repetibles que se basen comnmente en el diseo de familias de sistemas similares. En esencia, el
diseo deber tener la habilidad de volver a utilizar los bloques de construccin arquitectnicos. Dada
la especificacin de estas propiedades, el diseo arquitectnico se puede representar mediante uno o
ms modelos diferentes. Los modelos estructurales representan la arquitectura como una coleccin
organizada de componentes de programa. Los modelos del marco de trabajo aumentan el nivel de
abstraccin del diseo en un intento de identificar los marcos de trabajo (patrones) repetibles del
diseo arquitectnico que se encuentran en tipos similares de aplicaciones. Los modelos dinmicos
tratan los aspectos de comportamiento de la arquitectura del programa, indicando cmo puede
cambiar la estructura o la configuracin del sistema en funcin de los acontecimientos externos. Los
modelos de proceso se centran en el diseo del proceso tcnico de negocios que tiene que adaptar el
sistema. Finalmente los modelos funcionales se pueden utilizar para representar la jerarqua funcional
de un sistema
Se ha desarrollado un conjunto de lenguajes de descripcin arquitectnica (LDAs) para representar
los modelos destacados anteriormente. Aunque se han propuesto muchos LDAs diferentes, la
mayora proporcionan mecanismos para describir los componentes del sistema y la manera en que se
conectan unos con otros.
Ejercicio 1.2.2_5
El alumno analizara en equipo un caso prctico que se da en la vida real y que pueda ser utilizado para
ejemplificar lo referente al tema de la arquitectura del software, se deber entregar un ejemplo por
equipo manteniendo la misma regla, todos los miembros del equipo debern de conservar una copia
para futuras revisiones.
Ejercicio 1.2.2_6
El alumno deber elaborar de manera individual una definicin del termino Arquitectura del software en
un prrafo no mayor de tres lneas.

Sistemas de Informacin II

Unidad I

1.3 Heursticas de diseo

Una vez que se ha desarrollado una estructura de programa, se puede conseguir una modularidad
efectiva aplicando los conceptos de diseo que se introdujeron al principio de esta unidad. La
estructura de programa se puede manipular de acuerdo con el siguiente conjunto de heursticas:
I. Evaluar la primera iteracin de la estructura de programa para reducir al acoplamiento y
mejorarla cohesin. Una vez que se ha desarrollado la estructura del programa, se pueden
explosionar o implosionar los mdulos con vistas a mejorar la independencia del mdulo. Un mdulo
explosionado se convierte en dos mdulos o ms en la estructura final de programa. Un mdulo
implosionudo es el resultado de combinar el proceso implicado en dos o ms mdulos.
Un mdulo explosionado se suele dar cuando existe un proceso comn en dos o ms mdulos y
puede redefinirse como un mdulo de cohesin separado. Cuando se espera un acoplamiento alto,
algunas veces se pueden implosionar los mdulos para reducir el paso de control, hacer referencia a
los datos globales y a la complejidad dela interfaz
II. Intentar minimizar las estructuras con un alto grado de salida; esforzarse por la entrada a medida
que aumenta la profundidad. La estructura que se muestra dentro de la nube en la Figura 1.3.1 no
hace un uso eficaz de la factorizacin. Todos los mdulos estn planos, al mismo nivel y por
debajo de un solo mdulo de control. En general, una distribucin ms razonable de control se
muestra en la estructura superior. La estructura toma una forma oval, indicando la cantidad de capas
de control y mdulos de alta utilidad a niveles inferiores.

Figura 1.3.1 Estructuras de Programa

III. Mantener el mbito del efecto de un mdulo dentro del mbito de control de ese mdulo. El mbito
del efecto de un mdulo e se define como todos lo otros mdulos que se ven afectados por la
decisin tomada en el mdulo e. El mbito de control del mdulo e se compone de todos los mdulos
subordinados y superiores al mdulo e. En la Figura 1.3.1, si el mdulo e toma una decisin que
afecta al mdulo r, tenemos una violacin de la heurstica III, porque el mdulo r se encuentra fuera
del mbito de control del mdulo e.
IV. Evaluar las interfaces de los mdulos para reducirla complejidad y la redundancia, y mejorar la
consistencia. La complejidad de la interfaz de un mdulo es la primera causa de los errores del
software. Las interfaces debern disearse para pasar informacin de manera sencilla y debern ser
consecuentes con la funcin de un mdulo. La inconsistencia de interfaces (es decir, datos
aparentemente sin relacionar pasados a travs de una lista de argumento su otra tcnica) es una
indicacin de poca cohesin. El mdulo en cuestin deber volverse a evaluar.

Sistemas de Informacin II

Unidad I

V. Definir mdulos cuya funcin se pueda predecir, pero evitar mdulos que sean demasiado
restrictivos. Un mdulo es predecible cuando se puede tratar como una caja negra; es decir, los
mismos datos externos se producirn independientemente de los datos internos de procesamiento.
Los mdulos que pueden tener memoria interna no podrn predecirse a menos que se tenga
mucho cuidado en su empleo. Un mdulo que restringe el procesamiento a una sola subfuncin
exhibe una gran cohesin y es bien visto por el diseador. Sin embargo, un mdulo que restringe
arbitrariamente el tamao de una estructura de datos local, las opciones dentro del flujo de control o
los modos de interfaz externa requerir invariablemente mantenimiento para quitar esas restricciones.
VI. Intentar conseguir mdulos de <<entrada controlada>>, evitando conexiones patolgicas. Esta
heurstica de diseo advierte contra el acoplamiento de contenido. El software es ms fcil de
entender y por tanto ms fcil de mantener cuando los mdulos que se interaccionan estn
restringidos y controlados. Las conexiones patolgicas hacen referencia a bifurcaciones o referencias
en medio de un mdulo.
Ejercicio 1.3.1
El alumno analizara en equipo un caso prctico que se da en la vida real y que pueda ser utilizado para
ejemplificar lo referente al tema de heursticas de diseo, se deber entregar un ejemplo por equipo
manteniendo la misma regla, todos los miembros del equipo debern de conservar una copia para
futuras revisiones.

------------------------------ FIN UNIDAD I ------------------------------