antologia de sistemas de ion ii oko

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Departamento:

Licenciatura en Informtica

Materia:

SISTEMAS DE INFORMACION II

1


Departamento:


Materia:


OBJETIVO:

El estudiante conocer y dominar mtodos de la ingeniera del software para el diseo, construccin y documentacin de sistemas de informacin.

INTRODUCCION

Hasta hace poco la informacin misma no se consideraba un activo importante en una compaa. El proceso administrativo se consideraba un arte personal, de cara a cara, y no un proceso de coordinacin global a grandes distancias.

Hoy da se reconoce ampliamente que para los administradores es indispensable entender los sistemas de informacin, porque casi todas las organizaciones necesitan este sistema para sobrevivir y prosperar.

Ahora los sistemas de informacin son muy importantes en nuestro entorno para poder generar calidad en nuestro trabajo.

Un sistema de informacin se puede definir tcnicamente como un conjunto de componentes interrelacionados que rene, procesa, almacena y distribuye informacin para apoyar la toma de decisiones y el control en una organizaron adems de apoyar la toma de decisiones, la coordinacin y el control, los sistemas de informacin tambin ayudan a los administradores y trabajadores a analizar problemas, visualizar aspectos complejos y crear nuevos productos.

2


Departamento:


Materia:


Los sistemas de informacin tambin requieren retroalimentacin, que consiste en salidas que se devuelven a los miembros apropiados de la organizacin para ayudarles a evaluar o corregir la etapa de entrada.

Tambin, pueden ayudar a los administradores y trabajadores a analizar problemas, visualizar sujetos completos y crear productos nuevos.

Para entender los sistemas de informacin un sistemas de informacin es una solucin organizacional y administrativa basadas en tecnologa de informacin para un desafo del ambiente o el entorno en que se est realizando.

Son efectivamente una valiosa herramienta para el desarrollo de las organizaciones, pero es importante resaltar que todos los sistemas de informacin no son iguales y la implementacin de estos en las diferentes empresas, no siempre son de beneficio si no se verifica previamente el tipo de empresa y si el sistema a implementar es el adecuado.

Si nosotros queremos crear un sistema de informacin econmico para una empresa grande no nos servir de mucho y abra sido una inversin en vano y si la empresa es grande y tenemos un sistema de informacin bajo que no cumpla con las caractersticas para ayudarnos de manera eficaz en todo el manejo de la empresa entonces ser en vano esta implementacin porque tenemos que estar consientes de lo que necesita la empresa para poder actuar.

En los siguientes temas nosotros podremos verificar como poder crear un sistema de informacin que cumpla con las caractersticas necesarias para poder llevar a nuestra empresa al xito.

3


Departamento:


Materia:


JUSTIFICACION

Este documento es titulado sistemas de informacin es elaborado para poder tomarse como gua de la materia y poder utilizar para impartir clases, tambin para que pueda servir de apoyo didctico a los maestros y alumnos ya que cabe mencionar que el contenido de esta antologa trata bsicamente de la culminacin tota e implementacin de un proyecto desde el concepto de un diseo de un sistema pasando por todos los lineamientos que debemos seguir para la realizacin de un sistema desde su diseo fsico y lgico, su arquitectura ,su programacin y elaboracin hasta su implementacin en el rea que se va a utilizar este sistema.

Esta informacin referente a los sistemas de informacin es un documento muy importante para poder guiarnos a un mejor desempeo en el transcurso de la elaboracin de nuestro proyecto y la manera de poder implementarlo de manera que aunque haya fallas podremos detectarlas y corregirlas para obtener la satisfaccin de un trabajo total y completo elaborado por nosotros mismos, es posible que no encontremos todo lo que buscamos porque siempre hay muchas cosas nuevas que aprender y poner en prctica pero la decisin es nuestra esta antologa es solo para apoyarte y guiarte para que ests encaminado a un buen desempeo en el sistemas que se desee realizar. Animo que aun ai mucho por aprender.

INDICE Pg.

4


Departamento:


Materia:


Objetivo .II Introduccin..II Justificacin..IV ndice.........5

UNIDAD I: FUNDAMENTOS DEL DISEO

1.1 Panorama general del diseo fsico y lgico ...9 1.2 Concepto del diseo de sistemas ...16 1.2.1 Acoplamiento y coherencia.23 1.2.2 Arquitectura de software .35 1.3 Heursticas de diseo 38

UNIDAD II: DISEO DE SISTEMAS

2.1 Modelo estructurado..55 2.2 Modelo orientado a objetos.62 2.3 Modelo basado en componentes69 2.4 Diseo de la arquitectura del software .77 2.5 Diseo de interfaz de usuario .94 2.6 Diseo de bases de datos 118 2.7 Diseo de controles y procesos 126

5


Departamento:


Materia:


2.8 Aplicacin de mtricas para la evaluacin del diseo138

UNIDAD III : CONSTRUCCION

3.1 Seleccin del ambiente operativo y lenguaje de desarrollo..150 3.2 Elaboracin de programas.153 3.2.1 Implementacin.159 3.3 Mtricas para evaluar el software .162 3.4 Pruebas de programa y del sistema..169 3.5 Implementacin.. .178 3.6 Documentacin.180 3.6.1 Elaboracin del manual de usuario183 3.6.2 Elaboracin del manual de administracin189 3.6.3 Elaboracin del manual tcnico .212

UNIDAD IV: ESTUDIAS DE CASOS PRACTICOS PARA MANTENIMIENTO

4.1 Tipos de mantenimiento..219 4.2 Tcnicas de mantenimiento234 4.3 4.4 Anlisis de casos244 Viabilidad del mantenimiento246

4.5 Administracin del mantenimiento250 Conclusiones.253

6


Departamento:


Materia:


Glosario..255 Anexos 259 Fuentes de consultas..261

7


Departamento:


Materia:


UNIDAD I FUNDAMENTOS DEL DISEO

1.1

PANORAMA GENERAL DEL DISEO FISICO Y LOGICO

8


Departamento:


Materia:


El diseo fsico es el proceso de traduccin del modelo lgico abstracto a un diseo tcnico especfico para el nuevo sistema. Produce las especificaciones reales para el hardware, software y bases de datos fsicas, medios de entrada/salida, procedimientos manuales y controles especficos. Proporciona las especificaciones que transforman el diseo lgico abstracto en un sistema de funciones de personas y mquinas. Cuando el analista est listo para comenzar a disear el nuevo sistema, ya deben estar establecidos ciertos elementos. Debe hacer una definicin del problema, informacin general de antecedentes sobre el rea bajo estudio, una idea aproximada de las interacciones

Tambin el diseo el diseo fsico de sistemas es la forma en que se lograrn las tareas del sistema, lo que incluye la manera de conjuntar sus componentes y las funciones que realizar cada uno de stos.

En el diseo fsico se especifican las caractersticas de los componentes del sistema requeridos para poner en prctica el diseo lgico. En esta fase deben delinearse las caractersticas de cada uno de los componentes que se enumeran a continuacin.

9


Departamento:


Materia:


Diseo de hardware: Debe especificarse todo el equipo de cmputo, lo que incluye dispositivos de entrada, procesamiento y salida, con sus caractersticas de rendimiento. Por ejemplo, si el diseo lgico especifica que la base de datos debe contener grandes volmenes de datos histricos, se requerir que los dispositivos de almacenamiento del sistema sean de gran capacidad.

Diseo de software: De todo el Software Por ejemplo, si en el diseo lgico se indica la necesidad de que de que los usuarios actualicen al mismo tiempo la base de datos, en el diseo fsico deben especificarse un sistema de administracin de base de datos que lo permita algunos casos se puede adquirir el software, mientras que en otros se desarrollan internamente. Las especificaciones de diseo lgico, en cuanto a requisitos de salidas, entradas y procesamiento de los programas, tambin se toman en cuenta durante el diseo fsico del software. As pues, se especificara la capacidad de acceder a datos almacenados en ciertos archivos de disco que el programa utiliza.

Diseo de bases de datos: Es necesario detallar el tipo, estructura y funciones de las bases de datos. Las relaciones entre los elementos de datos establecidos en el diseo lgico deben reflejarse tambin en el diseo fsico. Estas relaciones incluyen aspectos tales como las rutas de acceso y la organizacin de la estructura de archivos. Por fortuna, existen muchos sistemas excelentes de administracin de bases de datos que son tiles para esta actividad.

10


Departamento:


Materia:


Diseo de telecomunicaciones: Deben especificarse las caractersticas necesarias del software, medios y dispositivos de telecomunicaciones. De tal suerte, si el diseo lgico indica que todo los miembros de un departamento deben compartir datos y software, ha de hacerlo posible la configuracin de la red de rea local y el software de telecomunicaciones especificados en el diseo fsico.

Diseo de personal: Este paso incluye especificar los antecedentes y experiencia de los individuos que ms probablemente satisfagan las descripciones de empleos que se incluyen en el diseo lgico.

Diseo de procedimientos y controles: Comprende detallar la forma en que se ejecuta cada aplicacin y las medidas para minimizar las probabilidades de delitos y fraudes. Tales especificaciones incluyen mtodos de auditora, soporte y distribucin de salidas.

Diseo lgico

Es aquel que representa los componentes del sistema y sus relaciones mutuas, como se mostrara ante el usuario. Muestra lo que la solucin sistemtica har en contraposicin con el modo como lo es en la actualidad impactada

11


Departamento:


Materia:


fsicamente. controles.

Tambin

describe

las

entradas

y

salidas,

las

funciones

de

procesamiento a realizar, los procedimientos de negocios, los modelos de datos y los

El diseo lgico de sistemas se refiere a lo que har el nuevo sistema, el diseo lgico es una descripcin de los requisitos funcionales de un sistema. En otras palabras, es la expresin conceptual de lo que har el sistema para resolver los problemas identificados en el anlisis previo. A falta de este paso, los aspectos tcnicos del sistema (como los dispositivos de hardware que deban adquirirse) con frecuencia oscurecen la solucin.

El diseo lgico incluye planear el propsito de cada elemento del sistema, sin relacin con consideraciones de hardware y software. Las especificaciones de diseo lgico que se determinar, y documentan se detallan en los prrafos siguientes.

Diseo de salida: Es una descripcin de todas las salidas del sistema e incluye sus tipos, formato, contenido y frecuencia. Por ejemplo, el requisito de que toda< las facturas de la compaa incluyan el nmero de factura original de los clientes es una especificacin de diseo lgico. Las herramientas de diseo de pantallas e informes pueden usarse durante la fase de diseo de salidas para satisfacer los requisitos de salidas del sistema.

12


Departamento:


Materia:


Diseo de entrada: Una vez que se completa el diseo de salidas, puede iniciarse el de entradas. En ste se especifican los tipos, formato, contenido sistema capture los nmeros telefnicos de los clientes cuando stos llaman a la organizacin y use tal dato para buscar de manera automtica la informacin de su cuenta, es una especificacin de diseo lgico. Es posible utilizar diagramas y diseos de pantallas e informes diversos para especificar el tipo, formato y contenido de los datos de entrada.

Diseo de procesamiento: Los tipos de clculos, comparaciones y manipulaciones de datos en general que requiere el sistema se determinan durante esta fase. Por ejemplo, un programa de nmina requiere clculos de los sueldos brutos y netos, retenciones de impuestos federales y locales, y otras deducciones y planes de ahorro.

Diseo de archivos y bases de datos: En muchos sistemas de informacin se requieren subsistemas de archivos y bases de datos. Las caractersticas de estos subsistemas se especifican tambin en la fase de diseo lgico. Por ejemplo, la capacidad para obtener la actualizacin instantnea de los registros de los clientes es una especificacin de diseo lgico. En muchos casos, un administrador de bases de datos participa en este aspecto del diseo. Los diagramas de flujo de datos y de entidad relacin por lo comn se emplean durante el diseo de archivos y bases de datos.

13


Departamento:


Materia:


Diseo de telecomunicaciones: Durante el diseo lgico es necesario especificar los sistemas de redes y telecomunicaciones. Por ejemplo, en un hotel podra especificarse un sistema de cliente/servidor con un cierto nmero de estaciones de trabajo enlazadas con el servidor. A partir de estos requisitos, podra optarse por una topologa hbrida. Los programas de grficos y las herramientas de CASE son tiles para facilitar el diseo de redes lgicas.

Diseo de procedimientos: Lo dos sistema de informacin requiere procedimientos para la ejecucin de aplicaciones y la solucin de los problemas que surjan. Estos requisitos importantes se capturan durante el diseo de procedimientos. Una vez diseados, los procedimientos se pueden describir con programas de procesamiento de texto. A manera de ejemplo, los pasos necesarios para aadir una nueva cuenta de cliente podran incluir una serie de tareas manuales y computarizadas. Deben redactarse procedimientos escritos para que sean eficaces y todo mundo los siga.

Diseo de controles y seguridad: Otra parte importante del diseo lgico es determinar la frecuencia y caractersticas necesarias de los sistemas de respaldo. En general, debe tenerse apoyo de todo, lo que incluye el hardware, software, datos, personal, insumos e instalaciones. Adems, en esta fase del diseo lgico ha de considerarse la planeacin de cmo prevenir un desastre del equipo de cmputo y la forma de recuperarse de l si ocurre.

14


Departamento:


Materia:


Diseo de personal y empleos: Algunos sistemas requieren contratar empleados adicionales, mientras que con otros es necesario modificar las tareas relacionadas con uno o ms empleos de SI existentes. Los nombres y descripciones de los puestos se especifican durante el diseo de personal y empleos. Los organigramas son tiles en el diseo de personal para diagramar los empleos y sus nombres. Tambin se utilizan procesadores de textos para describir las funciones de cada puesto.

1.2 CONCEPTOS DEL DISEO DE SISTEMAS.

La tecnologa de informacin y su historia.

A lo largo de la historia el hombre ha necesitado manejar y transmitir informacin para ello ha estado creando mquinas y mtodos.

15


Departamento:


Materia:


La informtica surge como la ciencia encargada del estudio y desarrollo de estas mquinas y mtodos que constituyen la tecnologa de informacin.

La tecnologa de informacin abarca desde artefactos, como papel, plumas, libros, cmaras, videograbadoras, computadoras, etc., hasta herramientas simblicas como el lenguaje escrito, smbolos matemticos, modelos qumicos etc. Sin estas mquinas y mtodos no seriamos capaces de visualizar nuestro ambiente, entenderlo ni controlarlo creativamente.

La historia de la tecnologa de informacin se ha seccionado en diferentes eras:

La era pre mecnica: 3000 a.C. 1450 d.C. (el nacimiento de la informacin) Primer sistema de escritura y alfabetos Herramientas: papel y plumas Libros y bibliotecas de numeracin y baco. La era mecnica: 1450 1840 ( la explosin de la informacin) Imprenta *peridicos y revistas *reglas de clculo y mquinas analticas.

16


Departamento:


Materia:


La era electromecnica: 1840 1940 (telecomunicaciones) Telgrafo y telfono La era electrnica 1940 presente

Primeras computadoras electrnicas digitales Generaciones de computadoras digitales

UNIVAC, ENIAC, etc.

Los continuos avances en tecnolgica de informacin tienen un fuerte impacto sobre la forma en que las personas trabajan, pues facilita el trabajo en equipo y la comunicacin a distancia.

Con frecuencia la informacin generada por un medio computarizado se trata con menos escepticismo que la obtenida por otros medios.

Las organizaciones cada vez son ms conscientes de la necesidad de contar con la mejor infraestructura tecnolgica para operar sus negocios de una manera eficiente y competitiva, pero tambin del alto costo que esto puede representar.

17


Departamento:


Materia:


Ante esta situacin ha surgido la necesidad de crear un rol conocido como Arquitecto de Sistemas en el cual se ha delegado la responsabilidad de investigar, evaluar y seleccionar las mejores alternativas tecnolgicas para atender las necesidades especficas del negocio a un costo razonable.

Dmosle un vistazo al origen de este rol, su analoga con los arquitectos de edificaciones, las competencias y el perfil requerido para desempearlo y la importancia que ha venido cobrando en las organizaciones el anlisis de la arquitectura de sistemas.

El diseo del sistema es la estrategia de alto nivel para resolver problemas y construir una solucin.

El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica.

La etapa del diseo del Sistema encierra cuatro etapas:

El diseo de los datos

18


Departamento:


Materia:


Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para implementar el Software.

El diseo Arquitectnico

Define la relacin entre cada uno de los elementos estructurales del programa.

El diseo de la Interfaz

Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean.

El diseo de procedimientos

19


Departamento:


Materia:


Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseo del Software se puede definir en una sola palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de materializar con precisin los requerimientos del cliente.

El diseo del Software

Es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas:

El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente.

Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software.

20


Departamento:


Materia:


El Diseo debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementacin.

Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios tcnicos para un buen diseo como son:

Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software.

El diseo debe ser modular, es decir, se debe hacer una particin lgica del Software en elementos que realicen funciones y subfunciones especificas.

Un diseo debe contener abstracciones de datos y procedimientos.

Debe producir mdulos que presenten caractersticas de funcionamiento independiente.

21


Departamento:


Materia:


Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno exterior.

Debe producir un diseo usando un mtodo que pudiera repetirse segn la informacin obtenida durante el anlisis de requisitos de Software.

Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software exige buena calidad a travs de la aplicacin de principios fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva.

Cuando se va a disear un Sistema de Computadoras se debe tener presente que el proceso de un diseo incluye, concebir y planear algo en la mente, as como hacer un dibujo o modelo o croquis.

1.2.1 ACOPLAMIENTO Y COHERENCIA

Cohesin

22


Departamento:


Materia:


Grado de relacin entre los elementos de un modulo. Si evaluamos el acoplamiento y la cohesin nos puede dar la calidad de un buen sistema de informacin.

La cohesin tiene que ser alta para que el sistema sea bueno, a mayor cohesin menor acoplamiento.

Tipos de Cohesin:

Cohesin funcional: Los elementos de la unidad de software estn relacionados en el desarrollo de una nica funcin. Es decir, las unidades de software trabajan juntas con un mismo fin. En general, es el criterio de agrupacin ms deseable. Probablemente haya entre las unidades un acoplamiento relativamente alto, por lo tanto es conveniente que estn juntas.

Cohesin secuencial: Una unidad de software realiza distintas tareas en secuencia, de forma que las entradas de cada tarea son las salidas de la tarea

23


Departamento:


Materia:


anterior. En otras palabras, se agrupan las unidades que cumplen que los resultados o salidas que produce una sirven como entrada para que la prxima contine trabajando.

Cohesin comunicacional o de datos: La unidad de software realiza actividades paralelas usando los mismos datos de entrada y salida. En otras palabras, cuando todas las unidades agrupadas trabajan sobre el mismo conjunto de datos.

Cohesin procedimental: La unidad de software tiene una serie de funciones relacionadas por un procedimiento efectuado por el cdigo. Es similar a la secuencial, pero incluyendo el paso de controles.

Cohesin lgica: Cuando las unidades de software agrupadas realizan un trabajo en una misma categora lgica, pero no necesariamente tienen relacin entre s. Por ejemplo: bibliotecas de funciones matemticas, slo se agrupan porque realizan clculos matemticos, pero no tienen necesariamente relacin entre ellas.

Cohesin temporal: Los elementos de la unidad de software estn implicados en actividades relacionadas con el tiempo. En otras palabras, se agrupan unidades de

24


Departamento:


Materia:


software que tienen que ejecutarse ms o menos en el mismo perodo de tiempo, sin que haya otro tipo de relacin entre ellas. En general debe evitarse.

Cohesin casual o coincidente: Los elementos de la unidad de software contribuyen a las actividades relacionndose mutuamente de una manera poco significativa. En otras palabras, es cualquier criterio que no caiga dentro de los anteriores. Este tipo de cohesin viola el principio de independencia y de caja negra de las unidades de software, por lo tanto debe evitarse

Qu ocurre en el caso de la cohesin?

La cohesin de un componente mide la identidad de su comportamiento. El comportamiento de un componente se define mediante una serie de operaciones (contrato), cada una de ellas con una responsabilidad y funcin. La suma de todas las operaciones que definen dicho comportamiento integra una identidad.

La cohesin no es buena cuando nos encontramos con que hay operaciones con un objetivo junto a otras con otro objetivo dentro de un mismo componente, cuya definicin funcional es una y clara. Un ejemplo claro y sencillo de esto es el siguiente. Imaginemos un componente que gestiona el estado de una ficha de datos personales. Lo lgico sera que su contrato tuviese operaciones como "Actualizar nombres y apellidos", "Eliminar telfono de contacto" y dems.

25


Departamento:


Materia:


Si defino una operacin que calcula el pronstico del tiempo en Tombuct para el prximo fin de semana, pues la cohesin se anula completamente, ya que nada tiene que ver con el resto de operaciones y, sobretodo, con el fin del componente.

Con esto propongo un debate sobre estos dos conceptos, para enriquecernos entre todos y mejorar el uso que hacemos de ello a diario en nuestros diseos. Aunque no lo parezca, aplicamos estas ideas constantemente, en todos los niveles de un equipo de desarrollo de soluciones informticas.

Acoplamiento

Grado de interdependencia entre las unidades de software (mdulos, funciones, subrutinas, bibliotecas, etc.) de un sistema informtico. El acoplamiento da la idea de lo dependiente que son las unidades de software entre s, es decir, el grado en que una unidad puedefuncionar sin recurrir a otras.

Por ejemplo: Dos funciones son absolutamente independientes entre s (es decir, el nivel ms bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la otra. En este caso se dice que ambas estn desacopladas.

El consenso general es que debe haber bajo acoplamiento entre las unidades de software para lograr una buena programacin o un buen diseo.

26


Departamento:


Materia:


O sea, mientras menos dependientes sean entre s las partes que constituyen un sistema informtico, mejor ser el resultado. Obviamente es imposible un desacoplamiento total de las unidades.

El bajo acoplamiento permite:

Mejorar la mantenibilidad de las unidades de software. Aumentar la reutilizacin de las unidades de software. Evitar el efecto onda, ya que un defecto en una unidad puede propagarse a otras, haciendo incluso ms difcil de detectar dnde est el problema. Minimiza el riesgo de tener que cambiar mltiples unidades de software cuando se debe alterar una. El acoplamiento, junto con la modularidad, la cohesin y otros factores, permiten mejorar la programacin y el diseo de sistemas informticos y aplicaciones, y son cruciales en el incremento de la reutilizacin de los cdigos.

Tipos de acoplamiento

Acoplamiento normal: una unidad de software llama a otra de un nivel inferior y tan solo intercambian datos (por ejemplo: parmetros de entrada/salida). Dentro de este tipo de acoplamiento podemos encontrarnos 3 subtipos, dependiendo de los datos que intercambien las unidades de software. Para ms informacin ver Acoplamiento normal.

27


Departamento:


Materia:


Acoplamiento externo: las unidades de software estn ligadas a componentes externos, como por ejemplo dispositivos de entrada/salida, protocolos de comunicaciones,etc. Acoplamiento comn: dos unidades de software acceden a un mismo recurso comn, generalmente memoria compartida, una variable global o un fichero.

Acoplamiento de contenido: ocurre cuando una unidad de software necesita acceder a una parte de otra unidad de software.

Qu quiere decir reducir el acoplamiento?

Bsicamente, lo ms importante es saber definir las responsabilidades de cada componente para garantizar que la dependencia sea funcional o arquitectnica, no de implementacin.

Un ejemplo simple de acoplamiento es cuando un componente accede directamente a un dato que pertenece a otro componente. Qu ocurre en ese caso? Pues que el resultado del comportamiento del componente A depender del valor del componente B, por lo tanto, estn acoplados. Cabe destacar que el acoplamiento no

28


Departamento:


Materia:


es malo, ojo. Simplemente hay que saber eliminar el acoplamiento que no sea funcional o arquitectnico.

En el caso de acoplamiento funcional, est bien que un componente de clculo de probabilidades dependa de un componente de clculo matemtico bsico, ya que es evidente que para calcular probabilidades ser necesario aplicar frmulas matemticas y resolver operacines aritmticas.

En el caso de acoplamiento arquitectnico, se puede ver un ejemplo en el esquema MVC (modelo-vista-controlador). La capa del modelo realizar cambios de acuerdo con los parmetros que recibe del controlador, por lo tanto hay cierta dependencia, pero slo como separacin de capas de una arquitectura claramente definida.

Propiedad que se define entre dos mdulos, es el grado de relacin que hay entre estos dos mdulos.

Para tener modularidad efectiva, hay que tratar de tener menos acoplamiento.

29


Departamento:


Materia:


Con el menor acoplamiento logramos que si hay que cambiar un modulo no impacte en otro modulo y as se produzca el efecto onda. Si hay demasiado acoplamiento, hay que analizar si no conviene juntarlos. Adems si un modulo no esta tan relacionado con otro, lo puedo usar en otro lado.

Parmetros tipo dato (se puede procesar). Parmetros tipo flag (no se pueden procesar).

Dentro del acoplamiento podemos encontrarnos tres subtipos, dependiendo de los datos que intercambien las unidades de software:

De datos: Cuando existe conexin entre los mdulos y la comunicacin es a travs de estructuras de datos simples (variables).

Se envan datos simples y se devuelven simples.

Estampado: Estn conectados y la comunicacin es a travs de estructuras de datos compuestas (registros).

30


Departamento:


Materia:


Se envan datos compuestos y devuelve simples.

Como el segundo modulo retorna datos simples la relacin es de datos y estampado. En estos caso se toma el de mayor acoplamiento. En ese caso sera estampado.

De control: Estn conectados y la comunicacin es a travs de un indicador, flag o seal a partir de la cual se pueden tomar deciciones en el modulo subordinado o superior.

La desventaja es que hay mucha relacin entre los mdulos, depende mucho uno de otro.

El modulo subordinado, debe saber que opcin le manda el superior. El modulo subordinado no le puede informar al superior que datos debe enviarle.

31


Departamento:


Materia:


Soluciones:

Que el subordinado devuelva un mensaje de error, y el superior decida qu hacer. Que el subordinado cometa error, y no devuelva nada.

Comn o por rea global: Pueden o no estar conectados, pero si comparten un rea global de datos (variables globales).

Si en una DB, tengo tres mdulos que comparten una tabla y decido sacar una columna de la tabla, debo modificar los mdulos que hagan referencia a la tabla.

32


Departamento:


Materia:


El objetivo final del diseo de software (o soluciones informticas) en materia de estos dos conceptos es: Reducir al mximo el acoplamiento entre componentes y aumentar la cohesin interna de cada componente.

1.2.2

ARQUITECTURA DEL SOFTWARE

Una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construccin del software para un sistema de informacin.

La Arquitectura de Software establece los fundamentos para que analistas, diseadores, programadores, etc. trabajen en una lnea comn que permita alcanzar los objetivos del sistema de informacin, cubriendo todas las necesidades.

Una arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como la

33


Departamento:


Materia:


mantenibilidad, adaptabilidad, flexibilidad e interaccin con otros sistemas de informacin.

Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin ente ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea.

La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema.

Una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco

34


Departamento:


Materia:


de referencia necesario para guiar la construccin del software para un sistema de informacin.

La Arquitectura de Software establece los fundamentos para que analistas, diseadores, programadores, etc. trabajen en una lnea comn que permita alcanzar los objetivos del sistema de informacin, cubriendo todas las necesidades.

Una arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interaccin con otros sistemas de informacin.

Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin entre ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea.

35


Departamento:


Materia:


La arquitectura de software, tiene que ver con el diseo y la implementacin de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeo de un sistema, as como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.

1.3

HEURISTICA DE DISEO

Heurstica de diseo: Las heursticas de diseo son un conjunto de datos que ayudan a mejorar la estructura del sistema, optimizando la secuencia.

La generacin de estas recomendaciones depende en gran medida del diseo especfico, as como de las caractersticas del equipo fsico donde se desarrolla la probabilidad estadstica del sistema.

Tamao de mdulo: El tamao del mdulo est relacionado con la modularidad, ms no solo de manera simple de "cortar en programa en ms piezas". Esto es, la modularidad tcnica no se incrementa simplemente cuando el tamao de mdulo decrece, mientras otros aspectos permanecen igual.

36


Departamento:


Materia:


Para la mayora de los propsitos, mdulos de mucho ms de cien sentencias, estn fuera del tamao ptimo con respecto a la economa de deteccin y correccin de errores. En el otro extremo de la escala el lmite es menos obvio. Excepto para ocasionales programadores "descarrilados", que piensan que modularidad es equivalente a partir un programa en mdulos de una sentencia, encontraremos que los mdulos muy pequeos, han sido diseados concisa y deliberadamente, y usualmente por razones funcionales.

Sin embargo, normalmente, mdulos menores a cinco a nueve lneas, deben considerarse para un replanteo.

Esto es especialmente relevante cuando existen muchos de estos mdulos muy pequeos en el sistema.

Sugerencias para el tamao ptimo de un mdulo han provenido de diferentes fuentes en el transcurso de los aos.

Una de las sugerencias conocidas es la de Baker quin recomienda que un mdulo debe consistir de aproximadamente cincuenta lneas, lo que coincide con el nmero de lneas que se pueden poner en una hoja de listado comn.

37


Departamento:


Materia:


Otra recomendacin proviene de Weinberg, cuyos estudios muestran que la comprensin de un programador se disipa fcilmente si el mdulo tiene ms de treinta lneas.

No siempre mdulo muy grandes o muy pequeos son necesariamente malos. La cuestin importante es que los mdulos reflejen la estructura del problema lo ms fielmente posible.

Descomponer un mdulo simplemente para llevarlo a un tamao ptimo, an perdiendo su significado con respecto a la estructura del problema, no es una buena estrategia.

Debemos examinar separadamente cada caso de mdulos muy grandes o muy pequeos.

Un mdulo demasiado grande a menudo puede deberse a dos razones principales:

Una factorizacin incompleta en mdulos subordinados apropiados. Dos o ms funciones han sido combinadas (frecuentemente con cohesin lgica) en un mismo mdulo. En el primer caso, se puede realizar una reduccin a travs de la identificacin y extraccin de subfunciones.

38


Departamento:


Materia:


Figura 1.1

MODULOS SOBRE LA HEURISTICAS DE DISEO

En el segundo caso, podemos descomponer el mdulo en sus funciones constitutivas.

FIGURA 1.2 SEGUNDO EJEMPLO DE FUNCION DE MODULOS

En cualquier caso, los diagramas de estructura pueden usarse como herramienta, y las modificaciones estructurales deben probarse sobre papel.

39


Departamento:


Materia:


Recalcamos que lo importe es dar sentido a la nueva estructura dentro del contexto del problema. Si no es posible dar una interpretacin razonable a la nueva estructura, debe mantenerse la original.

Cuando tratamos con mdulos muy pequeos, debemos distinguir dos casos: El mdulo atmico (nivel ms bajo) y modulo atmico.

En el caso de mdulos atmicos, las cuestiones a considerar son: la cantidad de llamadas desde mdulos superiores que recibe el mdulo (fan-in), y la sobrecarga (overhead) producido por el proceso de llamada a subrutina.

Un mdulo muy pequeo puede ser comprimido en sus mdulos superiores. Cuando el mdulo tiene un uso simple (fan-in = 1 ) esta es una alternativa a considerar.

Pero si el mdulo tiene usos mltiples (alto fan-in) puede ser muy peligroso absorberlo en sus mdulos superiores, porque se duplicar el esfuerzo de implementacin y mantenimiento del mismo.

En el caso de que la sobrecarga producida por el mecanismo de llamada a subrutina sea intolerable, se puede testear y depurar el mdulo independientemente

40


Departamento:


Materia:


y luego utilizar la inclusin en lnea del mdulo subordinado en sus superiores (ligado en tiempo de compilacin).

La mayora de los lenguajes dan facilidades para esto como ser el COPY del Cobol, #include del C, %INCLUDE del PL/I, las macros de la mayora de los assembler., etc., o utilizar facilidades de los preprocesadores de compilacin.

Cuando el mdulo es no atmico, el anlisis es ms complicado. Las opciones son comprimir el mdulo hacia arriba en su superior, o hacia abajo en un subordinado. Ambas opciones deben ser consideradas.

Un caso especial es el llamado mdulo fantasma, un mdulo que lo nico que contiene son llamadas a otros mdulos subordinados. Obviamente estos mdulos son el caso lmite de mdulos muy pequeos.

A travs de esta discusin, se asumi que el diseador conoce previo a la implementacin el tamao que tendrn los mdulos. Normalmente esto no requiere un proceso de estimacin sustancial.

La experiencia ha demostrado que el tamao comparativamente pequeo de mdulos en sistemas razonablemente modulares simplifica el proceso de estimacin. En adicin, el proceso de estimacin se torna ms exacto cuando el diseador tiene experiencia con la funcin que realizarn varios mdulos.

41


Departamento:


Materia:


Amplitud del Control (Fan-out)

La amplitud del control o ancho de salida (fan-out), es el nmero de subordinados inmediatos de un mdulo. Al igual que en con el tamao de mdulo, amplitudes de control muy altas o muy bajas, son indicadores de un posible diseo pobre.

Ya se ha visto anteriormente que la funcin de un administrador se torna muy compleja si el nmero de subordinados excede 7 2 subordinados inmediatos. En general deben verificarse anchos de salida mayores a 10 y aquellos de solamente 1 o 2. Tambin observaremos que una amplitud de control muy alta es ms peligroso que una baja.

Una amplitud de control demasiado baja puede incrementarse en la mayora de los casos descomponiendo el mdulo en subfunciones subordinadas adicionales, o comprimiendo el mdulo en sus superiores. Como se dijo en el punto anterior, esto es vlido si se puede dar a los nuevos mdulos un sentido dentro de la estructura del problema.

Una amplitud de control demasiado alta puede ser un indicativo de una reticencia por parte del diseador a delegar responsabilidades en mdulos subordinados. Sin embargo en la mayora de los casos, esto proviene de estructuras "panqueque" o fallas en la definicin de niveles intermedios. Para solucionar este

42


Departamento:


Materia:


problema, debe considerarse la posibilidad de agruparse varios subordinados en una funcin combinada. El principio de cohesin debe guiar este proceso para evitar mdulos de baja cohesin.

Ancho de Entrada (Fan-In)

Siempre que sea posible, desearemos maximizar el ancho de entrada de un mdulo (fan-in) durante el proceso de diseo. Cada instancia de mltiples entradas de un mdulo, representa que ha podido evitarse duplicidad de cdigo.

Sin embargo, un gran ancho de entrada no es algo que deba buscarse a cualquier costo. Por ejemplo, es ridculo combinar muchas funciones "no relacionadas" en un mdulo bajamente cohesivo, con el propsito de incrementar el fan-in.

Un gran ancho de entrada es alcanzado a travs de un proceso analtico que acompaa los pasos del proceso de diseo estructurado. Cada vez que vamos a dibujar un nuevo mdulo en el diagrama de estructura, primero debemos verificar si no existe ya algn otro mdulo que realice la funcin requerida.

Si es as, dibujaremos una flecha hacia la caja del mdulo ya existente en el diagrama, en lugar de dibujar una nueva. En orden de evitar un "enriedo" de flechas

43


Departamento:


Materia:


en el diagrama, pueden utilizarse conectores dentro de la pgina (un crculo) y fuera de pgina (un polgono), similarmente a la que se hace en los diagramas de flujo.

Es importante notar que la especificacin del fan-in es una tarea del diseador, no del implementador (codificador).

Un problema puede producirse cuando el nuevo mdulo es parecido pero no exactamente igual al mdulo existente. Si el diseador no distingue la diferencia subyacente entre ambos mdulos, pueden generarse problemas durante la integracin del sistema. Podrn fallar el nuevo mdulo, el anterior uso del mdulo existente.

En la sig. Figura La clave est en comprender cual es la parte comn de ambos mdulos, y aislarlo en un nuevo mdulo. Por ejemplo, supongamos que tenemos una funcin Q1 que parece ser similar a Q2. Si Q es la parte comn de ambas funciones, podemos reestructurar nuestro diseo de la siguiente manera:

44


Departamento:


Materia:


FIGURA 1.3 EJEMPLO FUNCIONES DE Q1 Y Q2

Las porciones remanentes Q1 y Q2 pueden reestructurarse absorbindolas en sus mdulos superiores si fueran pequeas. Podemos tener as una serie de alternativas diferentes.

FIGURA 1.4

REESTRUCTURACIOND E LOS MODULOS

45


Departamento:


Materia:


Alcance de Efecto / Alcance de Control

Cada decisin o sentencia condicional (if-then-else) en un sistema tiene algunas consecuencias: ciertos procesos se realizarn o no como resultado de una decisin. Equivalentemente podemos decir que cierto procesamiento es condicional en base a la salida o resultado de una decisin.

Es importante aprender donde se encuentran los resultados de una determinada decisin, dentro de una estructura modular. En orden de este estudio, introduciremos dos trminos nuevos: alcance de efecto y alcance de control.

El alcance de efecto de una decisin es la coleccin de todos los mdulos que contienen algn procesamiento que est condicionado por dicha decisin.

Aunque solo una pequea parte del procesamiento de un mdulo se vea afectada por la decisin. Si la activacin de un mdulo completo est condicionada por la decisin, el mdulo superior (invocador) tambin se incluye dentro del alcance de efecto.

El alcance de control de un mdulo es el mdulo mismo y todos sus subordinados.

46


Departamento:


Materia:


El alcance de control es un parmetro puramente estructural independiente de las funciones del mdulo.

Estamos en condiciones ahora de plantear la siguiente heurstica de diseo que involucra al alcance de efecto y al alcance de control:

En otras palabras, todos los mdulos que son afectados o influenciados por una determinada decisin deben estar subordinados finalmente al mdulo que toma la decisin.

La toma de decisiones y la estructura modular se interrelacionan mejor cuando las decisiones se toman a un nivel no ms alto que lo necesario dentro de estructura jerrquica, con el objetivo de ubicar el alcance de efecto dentro del alcance de control. Examinemos los siguientes cuatro casos:

47


Departamento:


Materia:


FIGURA 1.5 EJEMPLO DE MODULOS Y EFECTOS

El alcance de efecto de la decisin se representa por los mdulos sombreados. La Fig.1 ilustra un caso en el cual el alcance de efecto no es un subconjunto del alcance del control.

48


Departamento:


Materia:


La Fig.2 muestra una estructura en la cual el alcance de efecto est contenido dentro del alcance del control, pero puede discutirse que la decisin es realizada demasiado alta dentro de la jerarqua.

En la Fig. 3 se ha llevado la decisin al nivel justo para incluir el alcance de efecto dentro del alcance de control. La Fig. 4 muestra el caso ideal en el los mdulos a quienes afecta la decisin son subordinados inmediatos del mdulo que toma la decisin.

49


Departamento:


Materia:


UNIDAD II DISEO DE SISTEMAS

2.1 MODELO ESTRUCTURADO

Segn el modelo estructurado

El Anlisis Estructurado, fue seleccionado como tcnica de investigacin de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle.

50


Departamento:


Materia:


Este es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes.

Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a travs de un sistema, la representacin grfica de los procesos del sistema estar a cargo de los Diagramas de Flujos de Datos (DFD).

Que se relacionan con el Anlisis Estructurado

Smbolos grficos: iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

Diccionario de datos; descripciones de todos los datos utilizados en el sistema. Descripciones de procesos y procedimientos; declaraciones formales que emplean tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas; estndares para describir y documentar el sistema en forma correcta y completa.

51


Departamento:


Materia:


Fase de diseo:

En esta fase, el diseo estructurado produce el modelo de diseo con los siguientes elementos:

Diseo de datos: Transforma el modelo de dominio de la informacin creado durante el anlisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidadrelacin y el contenido detallado de datos del diccionario de datos constituyen la base para el diseo de datos.

Diseo arquitectnico: Define la relacin entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de anlisis y de la interaccin de subsistemas definidos dentro del modelo de anlisis.

Diseo de interfaz: Describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la informacin necesaria para el diseo de la interfaz.

52


Departamento:


Materia:


Diseo procedimental: Transforma elementos estructurales de la arquitectura del programa en una descripcin procedimental de los componentes del software. Se obtiene a partir de la especificacin del proceso, la especificacin del control y el diagrama de transicin de estados.

Componentes:

Smbolos grficos: Identifica y describe los componentes de un sistema y las relaciones entre estos.

Diccionarios de datos: Describe todos los datos utilizados en el sistema pueden ser manual o automatizado.

Descripciones de procesos y procedimientos: descripcin tcnica para describir las actividades que se realizan los procesos.

Reglas: Pasos a seguir para describir y documentar el ven forma correcta y completa.

53


Departamento:


Materia:


Herramientas:

Diagrama de flujo de datos: Es la base para otros componentes y describe como navegan los datos entre procesos y elementos relacionados.

Diccionario de datos: Contiene las caractersticas de los campos y/o descripcin detallada de los diferentes objetos que componen el sistema

Diagrama de estructuras de datos: describe la relacin entre las entidades y los objetos (conjunta de informacin que contienen las entidades)

Segn el modelo estructurado

El Anlisis Estructurado, fue seleccionado como tcnica de investigacin de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle.

Este es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes.

54


Departamento:


Materia:


Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a travs de un sistema, la representacin grfica de los procesos del sistema estar a cargo de los Diagramas de Flujos de Datos (DFD).

Diseo del sistema

El uso de los Diagramas de Flujos de Datos (DFDs), es una herramienta que permite mostrar grficamente y de manera general, el funcionamiento del sistema y los procesos necesarios para su desarrollo.

Los DFDs se pueden dibujar con slo cuatro notaciones sencillas, en este caso, la notacin utilizada est basada en el enfoque de Gane y Sarson.

Origen/Destino de Datos: Representan entidades externas al sistema que se comunican con l y que estn fuera de su control. Las relaciones existentes entre las entidades no se representan en el DFD, ya que no son parte del sistema bajo estudio.

55


Departamento:


Materia:


Para este diseo forman parte de las entidades los Justiciables, la cual incluye a todas aquellas personas que tienen relacin directa con el proceso. Las entidades Secretaria, Juez y Asistente, quienes conforman al rgano jurdico y son los garantes de llevar a cabo el proceso judicial.

Procesos: Muestran la parte del sistema que transforma las entradas de datos en salida; en tal sentido, el diagrama (DFD Propuesto) muestra cinco (5) procesos considerados vitales para el funcionamiento y operatividad de la aplicacin:

Solicitar Copias Certificadas: en el cual se supervisa que las solicitudes a procesar estn conforme a los requisitos establecidos por el Cdigo de Procedimiento Civil, o alguna otra Ley que condicione la puesta en marcha de stas.

Verificar existencia de actas en el sistema: en el se constata que el acta que tiene relacin con la copia certificada solicitada est o no en los archivos del circuito y de ese modo se tenga acceso directo a l.

Generar copias certificadas: encargado de procesar los reportes generados por el sistema, en este caso la emisin directa de las Copias Certificadas solicitadas.

Registro automtico de libros: en l se almacena una serie de datos proveniente del procesamiento de las solicitudes.

56


Departamento:


Materia:


Firmar y sellar actas: Proceso manual que se limita a autenticar las Copias Certificadas previa su entrega al solicitante.

Flujo de datos: El flujo describe el movimiento de paquetes de datos que viajan desde una parte del sistema a otra. Estn representados por una flecha para mostrar su origen y su destino.

Almacn: Representa una coleccin de paquetes de datos que permanecen en estado de reposo. No est referido exclusivamente a medios de almacenamiento electrnico como bases de datos en discos duros, sino tambin a archiveros metlicos o cualquier otro medio que permita guardar datos en carpetas u hojas de papel.

2.2 MODELO ORIENTADO A OBJETOS

57


Departamento:


Materia:


Las tcnicas orientadas a objetos pretenden satisfacer tanto las necesidades de los usuarios finales como las de los desarrolladores de software mediante una cierta capacidad de modelar el mundo real.

El Modelado y Diseo Orientado a Objetos se funda en pensar acerca de problemas a resolver empleando modelos que se han organizado tomando como base conceptos del mundo real.

La unidad bsica es el objeto que combina las estructuras de datos con los comportamientos en una entidad nica.

La fase de anlisis determina lo que debe hacer la implementacin y la fase de diseo del sistema determina el plan de ataque.

La fase de diseo de objetos determina las definiciones completas de las clases y asociaciones que se utilizarn en la implementacin, as como las interfaces y algoritmos de los mtodos utilizados para implementar las operaciones. La fase de diseo de objetos aadir objetos internos para la implementacin y optimizar las estructuras de datos y los algoritmos. El diseo de objetos es anlogo a la fase preliminar de diseo del ciclo de vida de desarrollo de software tradicional.

58


Departamento:


Materia:


Aspectos generales del diseo de objetos

Durante el diseo de objetos, se ejecuta la estrategia seleccionada durante el diseo del sistema y se rellenan los detalles.

Se produce un desplazamiento del nfasis pasando de los conceptos del dominio de la aplicacin a los propios de las computadoras. Los objetos descubiertos durante el anlisis sirven como esqueleto del diseo, pero el diseador debe escoger distintas formas de implementarlos con el objetivo de minimizar el tiempo de ejecucin, la memoria y el costo. En particular, las operaciones identificadas durante el anlisis deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones internas ms sencillas. Las clases, atributos y asociaciones del anlisis deben de implementarse en forma de estructuras de datos especficas.

Es necesario introducir nuevas clases de objetos para almacenar resultados intermedios durante la ejecucin del programa y para evitar la necesidad de recalcularlos.

59


Departamento:


Materia:


La optimizacin del diseo no debera llevarse a extremos exagerados porque la facilidad de implementacin y mantenimiento y la extensibilidad son tambin objetivos importantes.

La Metodologa OMT se extiende desde el anlisis hasta la implementacin pasando por el diseo. En primer lugar, se construye un modelo de anlisis para abstraer los aspectos esenciales del dominio de la aplicacin sin tener en cuenta la implementacin eventual.

En este modelo se toman decisiones importantes que despus se completan para optimizar la implementacin en segundo lugar. Los objetos del dominio de la aplicacin constituyen el marco de trabajo del modelo de diseo, pero se implementan en trminos de objetos del dominio de la computadora.

Por ltimo, el modelo de diseo se implementa en algn lenguaje de programacin, base de datos o hardware.

60


Departamento:


Materia:


Tipos de modelos

Modelo de Objetos

Describe la estructura esttica (de datos), de los objetos del sistema (identidad, atributos y operaciones) y tambin sus relaciones. El modelo de objetos contiene diagramas de objetos.

Un diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones entre las clases.

El diagrama contiene clases de objetos organizados en jerarquas que comparten una estructura y comportamiento comunes y que estn asociadas a otras clases. Estas clases definen los atributos que lleva cada instancia de objeto y las operaciones que efecta o sufre cada uno. En cada instancia de la clase se guardan los valores de esos atributos.

61


Departamento:


Materia:


Modelo dinmico Describe los aspectos de comportamiento (de control) de un sistema que cambian con el tiempo. El modelo dinmico se utiliza para especificar e implementar los aspectos del control del sistema.

Los modelos dinmicos contienen diagramas de estados. Un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por sucesos o eventos.

Se especifican en este modelo la temporizacin y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos), y la organizacin de sucesos y de estados.

El modelo dinmico captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en la que estn implementadas.

62


Departamento:


Materia:


Las acciones de los diagramas de estado se corresponden con funciones procedentes del modelo funcional; los sucesos de un diagrama de estado pasan a ser operaciones que se aplican a objetos dentro del modelo de objetos.

Modelo funcional

Describe las transformaciones (de funcin), de valores de datos que ocurren dentro del sistema, captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se haga.

El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las dependencias entre los valores y el clculo de valores de salida a partir de los de entrada y de funciones, sin considerar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. Las funciones se invocan como acciones en el modelo dinmico y se muestran como operaciones que afectan a objetos en el modelo de objetos.

63


Departamento:


Materia:


2.3 MODELO BASADO EN COMPONENTES

Un componente es una pieza de cdigo pre elaborado que encapsula alguna funcionalidad expuesta a travs de interfaces estndar.

Es algo muy similar a lo que podemos observar en el equipo de msica que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseado para acoplarse perfectamente con sus pares, las conexiones son estndar y el protocolo de comunicacin est ya preestablecido. Al unirse las partes, obtenemos msica para nuestros odos. El paradigma de ensamblar componentes y escribir cdigo para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes.

64


Departamento:


Materia:


Desarrollo basado en componentes

El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Sin embargo, el modelo de desarrollo basadoen componentes configura aplicaciones desde componentes preparados de software (clases).

El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software.

Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un ndice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software.

65


Departamento:


Materia:


El proceso unificado de desarrollo de software representa un nmero de modelos de desarrollo basado en componentes que han sido propuestos en la industria.

El lenguaje de modelado unificado define los componentes. Utilizando una combinacin del desarrollo incremental e interactivo, el proceso unificado define la funcin del sistema aplicando un enfoque basado en escenarios.

El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos ms efectivos para la construccin de grandes sistemas y aplicaciones de software.

Una vez que la mayor parte de los aspectos funcionales de esta disciplina comienzan a estar bien definidos, la atencin de la comunidad cientfica comienza a centrarse en los aspectos extra funcionales y de calidad, como un paso hacia una verdadera ingeniera.

66


Departamento:


Materia:


En este artculo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen, con especial nfasis en los estndares internacionales que los definen y regulan, y en los problemas que se plantean en este tipo de entornos.

Beneficios del desarrollo de Software basado en componentes

El uso de este paradigma posee algunas ventajas:

Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.

67


Departamento:


Materia:


Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes del sistema. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del tiempo.

La notacin de componentes

Un componente puede ser algo como un control Actives; tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio.

El diagrama de componentes

El diagrama de componentes muestra la relacin entre componentes de software, sus dependencias, su comunicacin su ubicacin y otras condiciones.

68


Departamento:


Materia:


Interfaces

Los componentes tambin pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente est ofreciendo y dejando disponibles a otros componentes de software y clases. Tpicamente, un componente est compuesto por numerosas clases y paquetes de clases internos. Tambin se puede crear a partir de una coleccin de componentes ms pequeos.

Los componentes y los nodos

Un diagrama de despliegue muestra el despliegue fsico del sistema en un ambiente de produccin (o de prueba). Muestra dnde se ubican los componentes, en qu servidores, mquinas o hardware. Puede representar los enlaces de redes.

Restricciones

69


Departamento:


Materia:


Los componentes pueden restricciones asignadas que indican el entorno en el que operan.

Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna funcin; las post-condiciones indican lo que debe ser verdadero despus de que un componente haya realizado algn trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente.

Anlisis del riesgo

Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.

Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad.

70


Departamento:


Materia:


Ventajas:

El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. - Reduce riesgos del proyecto - Incorpora objetivos de calidad - Integra el desarrollo con el mantenimiento

Desventajas:

Genera mucho tiempo en el desarrollo del sistema - Modelo costoso Requiere experiencia en la identificacin de riesgos.

Inconvenientes:

71


Departamento:


Materia:


Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).

2.4 DISEO DE LA ARQUITECTURA DEL SOFTWARE

Para poder entender el diseo, es necesario comprender que es la arquitectura de software.

Diseo de software: El diseo se ha descrito como un proceso multifase en el que se sintetizan representaciones de la estructura de los datos, la estructura del programa, las caractersticas de la interfaz y los detalles procedimentales desde los requisitos de la informacin.

El diseo:

72


Departamento:


Materia:


Una actividad en la que se toman decisiones importantes, frecuentemente de naturaleza estructural. Comparte con la programacin un inters por la abstraccin de la representacin de la informacin y de las secuencias de procesamiento, pero el nivel de detalle es muy diferente en ambos casos. El diseo construye representaciones coherentes y bien planificadas de los programas, concentrndose en las interrelaciones de los componentes de mayor nivel y en las operaciones lgicas implicadas en los niveles inferiores.

Se considera que:

El diseo est dirigido por la informacin. Los mtodos de diseo del software se obtienen del estudio de cada uno de los tres dominios del modelo de anlisis:

La arquitectura de software de un sistema de programa o computacin es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos.

La arquitectura no es el software operacional, Ms bien, es la representacin que capacita al ingeniero del software para:

73


Departamento:


Materia:


analizar la efectividad del diseo para la consecucin de los requisitos fijados, considerar las alternativas arquitectnicas en una etapa en la cual hacer cambios en el diseo es relativamente fcil, y Reducir los riesgos asociados a la construccin del software. Por qu es importantela arquitectura?

Facilitan la comunicacin entre todas las partes interesadas en el desarrollo de un sistema basado en computadora. Destaca decisiones tempranas de diseo que tendrn un profundo impacto en todo el trabajo de ingeniera del software. Constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo est estructurado el sistema y de cmo trabajan juntos sus componentes.

El diseo de la arquitectura del software tiene en cuenta 2 niveles de la pirmide, el diseo de datos y el diseo arquitectnico.

El diseo de datos nos facilita la representacin de los componentes de datos de la arquitectura.

74


Departamento:


Materia:


El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e interacciones.

En el contexto del diseo arquitectnico:

Un componente del software puede ser tan simple como un mdulo de programa, pero tambin puede ser algo tan complicado como incluir bases de datos y software intermedio middleware) que permiten la configuracin de una red de clientes y servidores

El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e interacciones.

Para Ben van Berkel la introduccin del diagrama informtico en el proceso de diseo permite huir del uso reiterativo de tipologas arquitectnicas, es decir, permite huir de la idea preconcebida de quela arquitectura debe basarse en arquitectura, abriendo el campo de miras hacia otras ciencias ms avanzadas (sociopoltica, matemticas, biologa, fsica) que no comportan la carga de la tradicin.

75


Departamento:


Materia:


De este modo UNStudio pone en tela de juicio toda la historia de la arquitectura, afirmando que sta conduce equivocadamente a valorar con excesivo empeo el resultado formal de una obra y negar conceptos mucho ms importantes como el uso o el contexto. Como en un 'remake' de lo ocurrido con la aparicin del Movimiento Moderno, UNStudio establece que en arquitectura todo debe ser repensado para ajustarse a la nueva realidad social, el consumismo y la tecnificacin.

Ejemplo de un diseo arquitectnico:

76


Departamento:


Materia:


FIGURA 2.1 EJEMPLO DE DISEO ARQUITECTONICO

Por qu es importante la arquitectura?

Las representaciones de la arquitectura de software facilitan la comunicacin entre todas las partes (partcipes) interesadas en el desarrollo de un sistema basado en computadora.

El modelo de diseo arquitectnico y los patrones arquitectnicos contenidos dentro son transferibles.

Esto es, los estilos y patrones de arquitectura pueden ser aplicados en el diseo de otros sistemas y representados a travs de un conjunto de abstracciones que facilitan a los ingenieros del software la descripcin de la arquitectura de un modo predecible.

77


Departamento:


Materia:


Estilos arquitectnicos

Cada estilo describe una categora del sistema que contiene: un conjunto de componentes, que realiza una funcin requerida por el sistema, un conjunto de conectores que posibilitan la comunicacin, la coordinacin y la cooperacin entre los componentes; restricciones que definen como se puede integrar los componentes que forman el sistema; y modelos semnticos que permiten al diseador entender las propiedades globales de un sistema para analizar las propiedades conocidas de sus partes constituyentes.

Arquitecturas centradas a datos

En el centro de esta arquitectura se encuentra un almacn al que otros componentes acceden con frecuencia para actualizar, aadir, borrar o modificar los datos del almacn. El software del cliente accede a l almacn central, es decir accede a lo datos independientes de cualquier cambio en los datos o de las acciones de de cliente.

78


Departamento:


Materia:


Arquitecturas de flujo de datos

Se aplica cuando los datos de entrada son transformados a travs de una serie de componentes computacionales o manipulativos en los datos de salida. Un patrn tubera y filtro tiene un grupo de componentes llamados filtros, conectados por tuberas que transmiten datos de un componente al siguiente. El filtro est diseado para recibir entrada de datos de una forma y producir la salida de datos de una forma especfica. Si el flujo de datos degenera en una simple lnea de transformadores se le llama Secuencial por Lotes.

Arquitecturas de llamada y retorno

Permite al diseador del software construir una estructura de programa relativamente fcil de modificar y ajustar a escala. Existen 2 sub estilos:

Arquitectura de programa principal: Clasifica de programacin descompone las funciones en una jerarqua de control donde un programa principal llama a un nmero de componentes del programa, los cuales pueden tambin llamar a otros componentes.

79


Departamento:


Materia:


Arquitectura de llamada de procedimiento remoto: Los componentes de una arquitectura de programa principal/subprograma, estn distribuidos entre varias computadoras en una red.

Arquitecturas orientadas a objetos: Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos. La comunicacin y la coordinacin entre componentes se consiguen a travs del paso de mensaje.

Arquitecturas Estratificadas: Se crean diferentes capas y cada una realiza operaciones que progresivamente se aproximan mas al cuadro de instrucciones de la mquina. En la capa externa, los componentes sirven a las operaciones de interfaz de usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las capas intermedias proporcionan servicios de utilidad y funciones de software de aplicaciones.

Complejidad arquitectnica: Para evaluar la complejidad total de una arquitectura dada una tcnica consiste en consideran las relaciones de dependencias entre los componentes de la arquitectura.

80


Departamento:


Materia:


Existen tres tipos de dependencias:

Dependencias de compartimiento: Representan las relaciones de dependencia entre los consumidores que utilizan los mismos recursos o los productores que producen para los mismos consumidores.

Dependencias de flujo: Representan las relaciones de dependencias entre los productores y los consumidores de recursos.

Dependencias restrictivas: Representan las restricciones de un relativo flujo de control entre un cuadro de actividades.

Flujo de transformacin

La informacin debe introducirse y obtenerse del software en forma de mundo exterior, la informacin entra en el sistema a lo largo de caminos que transforman los datos externos a un formato interno. Estos caminos se identifican como flujo de

81


Departamento:


Materia:


entrada. La informacin entrante se pasa a travs de un centro de transformacin y empieza a moverse a lo largo de caminos que ahora conducen hacia fuera del software. Los datos que se mueven a lo largo de este camino se denominan flujo de salida.

Flujo de transaccin

El flujo de transaccin se caracteriza por datos que se mueven a lo largo de un camino de entrada que convierte la informacin del mundo exterior en una transaccin. La transaccin se evala y, basndose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de accin. El centro de flujo de informacin del que parten muchos de los caminos de accin se denomina centro de transaccin.

Diseo de datos

El diseo de datos (a veces llamado arquitectura de datos) crea un modelo de datos y/o informacin que se representa con un alto nivel de Abstraccin (la visin de datos del cliente/usuario).

82


Departamento:


Materia:


Este modelo de datos, es refinado en progresivas representaciones especficas de la implementacin, que pueden ser procesadas por un sistema basado en computadora.

Al nivel de los componentes del programa, el diseo de las estructuras de datos y de los algoritmos asociados requeridos para su manipulacin, son la parte esencial en la creacin de aplicaciones de alta calidad. Al nivel de aplicacin, la traduccin de un modelo de datos en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema.

Al nivel de negocios, el conjunto de informacin almacenada en las diferentes bases de datos y reorganiza en el almacn de datos facilita la minera de datos o el descubrimiento de conocimiento que puede influir en el prximo xito del negocio. Los objetos de datos son modelados utilizando diagramas de entidad-relacin y el diccionario de datos.

La actividad de diseo de datos traduce esos elementos del modelo de requisitos en estructuras de datos a nivel de los componentes del software y, cuando es necesario a arquitecturas de base de datos a nivel aplicacin.

83


Departamento:


Materia:


Un almacn de datos es un entorno de datos separado, que no est directamente integrado con las aplicaciones del da a da, pero que abar

antologia de sistemas de ion ii oko

Documents