Sistemas de Informacin II Sistemas de Informacin II Objetivo General del Curso:

Unidad I

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 Arquitectura del software

Unidad I

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 1.3 Heursticas de diseo

Unidad I

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 ------------------------------