DISEÑO ESTRUCTURADO

Clasifica el grado de independencia entre pares de módulos de un DE.

El objetivo es minimizar el acoplamiento, es decir, maximizar la independencia entre módulos

Un bajo acoplamiento indica un sistema bien particionado y puede obtenerse de tres Maneras:

Eliminando relaciones innecesarias: Por ejemplo, un módulo puede recibir algunos datos, innecesarios para él, porque debe enviarlos para un módulo subordinado

Reduciendo el número de relaciones necesarias: Cuanto menos conexiones existan entre módulos, menor será la posibilidad del efecto en cadena

Debilitando la dependencia de las relaciones necesarias: Ningún módulo se tiene que preocupar por los detalles internos de implementación de cualquier otro

Generalmente el tipo de cohesión de un módulo determina el nivel de acoplamiento que tendrá con otros módulos del sistema

Cohesión es la medida de intensidad de asociación funcional de los elementos de un módulo.

El objetivo del diseño estructurado es obtener módulos altamente cohesivos, cuyos elementos estén fuerte y genuinamente relacionados unos con otros

Es la separación de una función contenida en un módulo, para un nuevo módulo. Puede ser hecha por cualquiera de las siguientes razones.

Reducir el tamaño del módulo

Un buen tamaño para un módulo es alrededor de media página (30 líneas). Ciertamente, toda codificación de un módulo debería ser visible en una página (60 líneas).

Hacer el sistema más claro

La descomposición no debería ser hecha de una manera arbitraria, los módulos resultantes de la descomposición de un módulo deben representar sub-funciones del módulo de más alto nivel en el DE.

Minimizar la duplicación de código

Cuando se reconoce una función que puede ser reutilizada en otras partes del DE, lo más conveniente es convertirla en un módulo separado

Así, se puede localizar más fácilmente las funciones ya identificadas y evitar la duplicación del mismo código en el interior de otro módulo.

Separar el trabajo de la ‘administración’

Si un gerente hace el trabajo de los subordinados no tendrá tiempo suficiente para coordinar y organizar el trabajo de los subordinados y, por otro lado, si hace el trabajo los subordinados no serían necesarios.

Lo mismo se puede aplicar al diseño del DE, relacionado a los módulos de Trabajo (edición, cálculo, etc.) y a los módulos de Gerencia (decisiones y llamadas para otros módulos).

Crear módulos más generales

Otra ventaja de la descomposición es que, frecuentemente, se pueden reconocer módulos más generales y, así, más útiles y reutilizables en el mismo sistema y, además, pueden ser generadas bibliotecas de módulos reutilizables en otros sistemas.

Es usado como una medida de complejidad. Es
el número de subordinados inmediatos de un módulo (cantidad de módulos invocados).

Es usado como una medida de reusabilidad, es el número de superiores inmediatos de un módulo (la cantidad de módulos que lo invocan).

Un alto fan-in es el resultado de una descomposición inteligente. Durante la programación, tener una función llamada por muchos superiores evita la necesidad de codificar la misma función varias veces.

Existen dos características fundamentales que deben ser garantizadas en módulos con un alto fan-in:

Buena Cohesión: Los módulos con mucho fan-in deben tener alta cohesión, con lo cual es muy probable que tengan buen acoplamiento con sus llamadores

Interfaz Consistente: Cada invocación para el mismo módulo debe tener el mismo número y tipo de parámetros. En el ejemplo que sigue, hay un error.

Algunos de los problemas comunes que los desarrolladores encuentran en la construcción de software de cierta complejidad son los siguientes

- El dominio de aplicación no es conocido.
- La comunicación con el usuario.
- La comunicación con el grupo de desarrollo.
- La carencia de buena documentación.

Por esta razón, es necesario seguir una serie de pasos sistemáticos para que los diferentes grupos de desarrollo posean una buena comunicación

Especificación de requerimientos: Se realizan entrevistas con el usuario identificando los requerimientos y necesidades del usuario.

Análisis: Modela los requerimientos del usuario.

Diseño: Se modela la solución del sistema, teniendo en cuenta el ambiente de implementación a utilizar, por ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje de programación, performance deseada, etc.

Implementación: Dado el lenguaje de programación elegido se implementa el sistema

Testeo: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios de- terminados por el grupo correspondiente

Mantenimiento: Es la etapa más difícil de desarrollo del sistema, actualiza y modifica el sistema si surgen nuevos requerimientos.

Fase de diseño: En esta fase, el diseño estructurado produce el modelo de diseño con los siguientes elementos:

Diseño de datos. Transforma el modelo de dominio de la información creado durante el análisis, en las estructuras de datos necesarias para implementar el software.

Diseño arquitectónico. Define la relación entre los principales elementos estructurales del programa

Diseño de interfaz. Describe como se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean.

Diseño procedimental. Transforma elementos estructurales de la arquitectura del programa en una descripción procedimental de los componentes del software.

Componenetes

Símbolos gráficos: 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: descripción técnica para describir las actividades que se realizan los procesos.
- Reglas: Pasos a seguir para describir y documentar el ven forma correcta y completa

Herramientas

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

Según el modelo estructurado

El Análisis Estructurado, fue seleccionado como técnica de investigación de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lógica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle.

DISEÑO DEL SISTEMA

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

Origen/destino de datos

Representan entidades externas al sistema que se comunican con él y que están 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.

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 aplicación:

Solicitar copias certificadas; en el cual se supervisa que las solicitudes a procesar estén conforme a los requisitos establecidos por el Código de Procedimiento Civil

Verificar existencia de actas en el sistema; en él se constata que el acta que tiene relación 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 emisión directa de las Copias Certificadas solicitadas.

Registro automático de libros; en él se almacena una serie de datos proveniente del procesamiento de las solicitudes

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.

Almacén: Representa una colección de paquetes de datos que permanecen en estado de reposo

El acoplamiento es un concepto abstracto que nos indica el grado de interdependencia entre módulos.

Si dos módulos están fuertemente acoplados, existe una alta probabilidad de que el programador necesite conocer uno de ellos en orden de intentar realizar modificaciones al otro.

FACTORES QUE INFLUENCIAN EL ACOPLAMIENTO

Tipo de conexión entre módulos: los sistemas normalmente conectados, tienen menor acoplamiento que aquellos que tienen conexiones patológicas.

Complejidad de la interface: Esto es aproximadamente igual al número de ítems diferentes pasados (no cantidad de datos). Más ítems, mayor acoplamiento.

Tipo de flujo de información en la conexión: los sistemas con acoplamiento de datos tienen menor acoplamiento que los sistemas con acoplamiento de control, y estos a su vez menos que los que tienen acoplamiento híbrido.

Momento en que se produce el ligado de la Conexión: Conexiones ligadas a referentes fijos en tiempo de ejecución, resultan con menor acoplamiento que cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su ver menor acoplamiento que cuando el ligado se realiza en tiempo de linkage-edición

Tipos de conexiones entre módulos

Una conexión en un programa, es una referencia de un elemento, por nombre, dirección, o identificador de otro elemento.
Una conexión intermodular ocurre cuando el elemento referenciado está en un módulo diferente al del elemento referenciante.

Si todas las conexiones de un sistema se restringen a ser completamente parametrizadas (con respecto a sus entradas y salidas), y la transferencia condicional de control a cada módulo se realiza a través de una identidad simple y única, diremos que el sistemas está mínimamente conectado.

Complejidad de la interface

La segunda dimensión del acoplamiento en la complejidad. Cuanto más compleja es una conexión, mayor acoplamiento se tiene. Un módulo con una interface de 100 parámetros generará mayor acoplamiento que un que solo necesite tres parámetros

Flujo de Información

Otro aspecto importante del acoplamiento tiene que ver con el tipo de información que se transmite entre el módulo superior y subordinado

Distinguiremos tres tipos de flujo de información:
- Datos
- Control
- Híbrido

Tiempo de ligado de conexiones intermodulares

El ligado de variables a valores, o más genéricamente, de identificadores a referentes específicos, puede tener lugar en diferentes estadios o períodos en la evolución del sistema

ACOPLAMIENTO DE ENTORNO COMÚN (COMMON ENVIRONMENT COUPLING)

Siempre que dos o más módulos interactúan con un entorno de datos común, se dice que dichos módulos están enacoplamiento por entorno común.

El acoplamiento de entorno común es una forma de acoplamiento de segundo orden, distinto de los tratados anteriormente. La severidad del acoplamiento dependerá de la cantidad de módulos que acceden simultáneamente al entorno común.

DESACOPLAMIENTO

Una disciplina de diseño que favorezca el acoplamiento de entrada-salida y el acoplamiento de control por sobre el acoplamiento por contenido y el acoplamiento híbrido, y que busque limitar el alcance del acoplamiento por entorno común es el enfoque más efectivo.

Otras técnicas para reducir el acoplamiento son

Convertir las referencias implícitas en explícitas. Lo que puede verse con mayor facilidad es más fácil de comprender.

Estandarización de las conexiones.

Uso de "buffers" para los elementos comunicados en una conexión. Si un módulo puede ser diseñado desde el comienzo asumiendo que un buffer mediará cada corriente de comunicación, las cuestiones temporización, velocidad, frecuencia, etc., dentro de un módulo no afectarán el diseño de otros.

Localización. Utilizado para reducir el acoplamiento por entorno común. Consiste en dividir el área común en regiones para que los módulos solo tengan acceso a aquellos datos que les son de su estricta incumbencia.

UNA APLICACIÓN

El programa tendrá dos corrientes de entrada: una carácter a carácter desde teclado de una terminal, y la otra registro a registro desde una archivo en disco.

Se comienza leyendo los caracteres provenientes de tecla hasta que se recibe el carácter "RETURN", entonces se pasa a leer el archivo registro a registro hasta recibir un registro con "//" en su encabezado, lo cual indica que se vuelve a leer desde teclado

El paso anterior se realiza iterativamente, hasta que se recibe una señal de finde-transmisión desde la terminal (EOT). Entonces se continúa leyendo el archivo hasta el final (EOF).

Las corrientes de datos de ambas entradas se analizarán y separarán en palabras las que se pasarán al módulo existente ProcWord, el que realizará algo con ellas.

La cohesión es la medida cualitativa de cuan estrechamente relacionados están los elementos internos de un módulo.

Introducción: Relación funcional

La manera en la cual dividimos físicamente un sistema en piezas (particularmente en relación con la estructura del problema) puede afectar significativamente la complejidad estructural del sistema resultante, así como el número total de referencias inter modulares.

Cohesión de Procedimiento (moderada)

Elementos de procesamiento relacionados proceduralmente son elementos de una unidad procedural común. Estos se combinan en un módulo de cohesión procedural. Una unidad procedural común puede ser un proceso de iteración (loop) y de decisión, o una secuencia linear de pasos.

Cohesión de Comunicación (moderada a buena)

Ninguno de los niveles de cohesión discutidos previamente está fuertemente vinculado a una estructura de problema en particular

Cohesión de Comunicación es el menor nivel en el cual encontramos una relación entre los elementos de procesamiento que es intrínsecamente dependiente del problema

Cohesión Secuencia

En ella, los datos de salida (resultados) de un elemento de procesamiento sirven como datos de entrada al siguiente elemento de procesamiento.

Cohesión Funcional

En el límite superior del espectro de relación funcional encontramos la cohesión funcional. En un módulo completamente funcional, cada elemento de procesamiento, es parte integral de, y esencial para, la realización de una función simple

Cualquier módulo, rara vez verifica un solo principio asociativo. Sus elementos pueden estar relacionados por una mezcla de los siete niveles de cohesión. Esto lleva a tener una escala continua en el grado de cohesividad más que una escala con siete puntos discretos.

La decisión de que nivel de cohesión es aplicable a un módulo dado requiere de cierto juicio humano. Algunos criterios establecidos son:

La cohesión secuencial es más próxima al óptimo funcional que a su antecesor de comunicación

Similarmente existe un salto mayor entre la cohesión lógica y la temporal que entre casual y lógica.

Podemos asignar la siguiente escala de valores para ayudar al diseñador en la calificación de niveles:
• 0: casual
• 1: lógica
• 3: temporal
• 5: procedural
• 7: de comunicación
• 9: secuencial
• 10: funcional

La estrategia del análisis de transacción, simplemente
reconoce que los DFD de la forma planteada previamente pueden mapearse en una estructura de programa particular.

Debe ser capaz de:
- Obtener o responder a transacciones en forma "cruda"
- Analizar cada transacción para determinar su tipo
- Despachar acorde al tipo de transacción
- Completar el procesamiento de cada transacción

Forma Factorizada ->

La raíz de esta estructura (transacción), puede estar subordinada a cualquier parte de un sistema mayor. Cada un de los módulos "Obtener Trans.", "Analizar Trans.", "Hacer tipo 1", "Hacer tipo n", pueden ser en sí mismas raíces de subsistemas enteros.

Forma Ortodoxa ->

La subestructura debajo del módulo de despacho puede ser modelada en un sistema de cuatro niveles. Estos niveles son los siguientes:
- Procesador de transacción (o nivel P)
- Nivel de Transacción (o nivel T)
- Nivel de Acción (o nivel A)
- Nivel de Detalle (o nivel D)

En la forma ortodoxa, el procesador de transacciones (Despachador) esperará recibir una transacción desde su subordinado cuando sea activado.

Un sistema puede incluir cualquier número de centros de transacción

Un centro de transacción puede estar ubicado en una rama aferente, de transformación, o eferente.

1. Identificar las fuentes de transacción. En muchos casos, las transacciones serán mencionadas explícitamente en la definición del problema, en cuyo caso será usual asumir que las transacciones provienen de un medio físico de entrada

2. Especificar la organización centrada en la transacción apropiada. La figura planteada puede ser un buen modelo, pero el diseñador deber sentirse libre de alterarla como considere necesario, basándose en la teoría y las heurísticas vistas.

3. Identificar las transacciones y sus acciones definidas. De nuevo, a menudo encontraremos que todos los requisitos de información serán provistos por la definición del problema mismo.

4. Identificar situaciones potenciales en que puedan combinarse módulos. Como en el caso del análisis de transformación, podemos encontrar situaciones en las que un módulo de nivel intermedio pueda ser creado desde un grupo funcionalmente cohesivo de módulos de bajo nivel.

5. Para cada transacción, o colección cohesiva de transacciones, especificar un módulo de transacción para procesarlo completamente.

6. Para cada acción en una transacción, especificar un módulo de acción subordinado al módulo de transacción correspondiente.

7. Para cada paso detallado en un módulo de acción, especificar un módulo de detalle subordinado a algún módulo de acción que lo necesite.

Diagrama de flujo de datos

Primer nivel de Factorización

Final

El propósito de la estrategia es el de identificar las funciones de procesamiento primarias del sistema, las entradas de alto nivel de dichas funciones, y las salidas de alto nivel.

Se crean módulos de alto nivel dentro de la jerarquía que realizan cada una de estas tareas: creación de entradas de alto nivel, transformación de entradas en salidas de alto nivel, y procesamiento de dichas salidas

La estrategia de análisis de transformación consiste
de cuatro pasos principales:

1. plantear el problema como un diagrama de flujo de datos
2. identificar los elementos de datos aferentes y eferentes
3. factorización del primer nivel
4. factorización de las ramas aferente, eferente, y de transformación

El primer paso: obtención del diagrama de flujo de datos del problema. En orden de llevar adelante la estrategia del análisis de transformación, es necesario estudiar el flujo de datos a través del sistema. Para esto debemos dibujar un diagrama de flujo de datos (DFD) del sistema que estamos diseñando

El Segundo Paso: Identificar los Elementos de Datos Aferentes y Eferentes

Este proceso implica un juicio de valor por parte del diseñador; la idea es llegar lo más lejos posible de las salidas físicas.
Este proceso de identificar elementos aferentes y eferentes dejará algunas transformaciones en el medio entre dichos elementos. Estas son denominadas transformaciones centrales.

Ellas son el trabajo principal del sistema. Ellas transforman las entradas principales
del sistema, en las mayores salidas.

El tercer paso: Factorización del primer nivel Habiendo identificado los elementos aferentes y eferentes de datos del sistema, especificaremos un módulo principal, el cual al ser activado, realizará todas las tareas del sistema invocando a sus subordinados.

El cuarto paso: Factorización de los flujos aferentes, eferentes y de transformación Tres estrategias distintas son usadas para factorizar los tres tipos de módulos subordinados (aferente, eferente, y de transformación) en módulos subordinados de bajo nivel.

El quinto paso: Desviaciones
La estrategia descripta asume una estructura ortodoxa en la cual el flujo de datos es entrante o saliente en cualquier rama, pero nunca los ambos a la vez. Consecuentemente, se espera que los módulos aferentes tengan solo subordinados aferentes y de transformación.

Como finalizar la factorización Varios criterios pueden utilizarse para determinar cuando la factorización funcional de módulos debe terminarse.

El fin puede alcanzarse
cuando para una transformación es
difícil distinguir claramente subtareas.

Se refiere a la asignación de módulos del sistema en secciones manejadas como distintas unidades físicas de ejecución sobre la máquina.
Cada una de estas unidades se llama unidades de carga, y serán consideradas como una porción del sistema procesadas como una unidad por el sistema operativo.

Análisis Procedural

Consiste de un conjunto de criterios para determinar que módulos deben pertenecer a la misma unidad de carga en por de maximizar la eficiencia.

No existen reglas fijas para realizar el empaquetado de módulos en unidades de carga, y será el criterio del diseñador el que deberá determinar como se compongan las unidades de carga.

Iteraciones

Deben incluirse en la misma unidad de carga módulos conectados por referencias iterativas. Este criterio se aplica a las estructuras iterativas o loops.

Volumen

Deben incluirse en la misma unidad de carga módulos con alto volumen de referencias de conexión entre ellos. Para esto debe estimarse la cantidad de veces que un módulo invocará a otro durante la ejecución.

Frecuencia

Cuando la frecuencia de referencia es un criterio observable, la regla de pensamiento es que los módulos relacionados por referencias altamente frecuentes deben ubicarse en al misma unidad de carga.

Intervalo

Deben incluirse en la misma unidad de carga los módulos con intervalos breves de tiempo entre activaciones.

Optimizacion

Un Enfoque para la Optimización de Módulos Existen dos enfoques para optimizar un sistema:
Optimizar el código dentro de los módulos
Cambiar la estructura del sistema para mejorar su performance
Las técnicas para optimizar código son técnicas específicas de programación fuera del alcance de esta discusión, y dependen en la mayoría de los casos de los lenguajes, compiladores, y entornos de desarrollo que se utilicen.

Cambios estructurales por Eficiencia En un determinado número de casos, la optimización del código dentro de los límites de un módulo puede no ser suficiente para alcanzar el nivel de eficiencia deseado

Diseño de Datos

El impacto de la estructura de datos sobre la estructura del programa y la
complejidad procedimental hace que el diseño de datos tenga una gran
influencia en la calidad del software

. Los datos bien diseñados pueden conducir
a una mejor estructura de programa, a una modularidad efectiva y a una
complejidad procedimental reducida

Diseño arquitectónico

El objetivo principal es
desarrollar una estructura de programa modular y
representar las relaciones de control entre los módulos

Mezcla la estructura de programas y la estructura de datos
y define las relaciones que facilitan el flujo de los datos a lo
largo del programa

El diseño orientado al flujo de datos es
compatible con un amplio rango de áreas de aplicación

Es
particularmente útil cuando se procesa secuencialmente la
información y no existe ninguna estructura jerárquica formal.

Descomposición

Un problema complejo cuesta más de resolver que otro más sencillo (de
Perogrullo)

La complejidad de un problema global es mayor que el valor de las
complejidades de cada una de sus partes por separado.

Si
el objetivo es elaborar un programa para resolver
dicho problema grande, cada subproblema (menos

complejo) podrá ser resuelto por un módulo (subalgoritmo) relativamente fácil de

implementar (más que el programa global No dividido).

Problema del refinamiento sucesivo

Un refinamiento excesivo podría dar lugar a un
número tan grande de módulos que haría poco práctica la descomposición.

Se tendrán
en cuenta estos criterios para dejar de descomponer:
Cuando no haya tareas bien definidas.

Cuando la interfaz de un módulo sea tan complicada como el propio módulo

Jerarquía de módulos

Ésta es una consecuencia directa de la descomposición del problema
mediante refinamientos sucesivos, el resultado será un conjunto de módulos
estratificados en capas a modo de pirámide donde en la

cima habrá un único módulo que representará al programa

global

Al final, debe obtenerse una estructura piramidal donde los
módulos de los niveles superiores se encargan de las
tareas de coordinación, lógica de la aplicación y

manipulación de los módulos inferiores

Independencia

Independencia modular

Cuanto más independientes son los módulos entre sí
más fácil y flexiblemente se trabajará con ellos, esto implica que para desarrollar un
módulo no es necesario conocer detalles internos de otros módulos.

Como
consecuencia de la independencia modular un módulo cumplirá:
Características de caja negra, es decir abstracción (ver abstracción en

programación orientada a objetos).

Aislamiento de los detalles mediante encapsulamiento (ver encapsulamiento en

programación orientada a objetos).

Si asumimos que podemos medir por algún método la complejidad de un problema P, diremos que la complejidad del mismo será M(P), y que
el costo de realizar un programa que resuelva el problema P será C(P).

Dados dos problemas P y Q observaremos lo siguiente
Si M (P) > M (Q) entonces C(P) > C(Q)

Es decir el costo de resolver un determinado problema es directamente proporcional al
tamaño del mismo

en la medida que las complejidades se incrementan
somos susceptibles a cometer un mayor número de errores.
M (P+Q) > M (P) + M(Q)

Y consecuentemente
C(P+Q) > C(P) + C(Q)

Siempre será preferible crear dos piezas pequeñas que una sola más grande, si
ambas solucionan el mismo problema.

Todas estas medidas reconocen que la complejidad de los programas percibida por humanos, se ve altamente influenciada por el tamaño del módulo

Tres factores, implícitos en el enfoque previo, han sido identificados como afectando la complejidad de las sentencias:
- La cantidad de información que debe ser comprendida correctamente.
- La accesibilidad de la información.
- La estructura de la información.

Esto se relaciona con el número de argumentos o parámetros que son pasados en la llamada al módulo.

Una llamada a una subrutina que involucra 100 parámetros, será más compleja que una que involucra solo 3.

Cierta información acerca del uso de la interface debe ser comprendida por el programador para escribir o interpretar el código correctamente.

La interface es menos compleja si la información puede ser accedida (por el programador, no por la computadora) directamente; es más compleja si la información referencia indirectamente otros elementos de datos.

La interface es menos compleja si la información es presentada localmente dentro de la misma sentencia de llamada. La interface es más compleja si la información necesaria es remota a la sentencia.

La interface es menos compleja si la información es presentada en forma standard que si se presenta de forma imprevista.

La interface es menos compleja si su naturaleza es obvia es menos compleja que si su naturaleza es obscura.

la información es menos compleja si se presenta en forma lineal y más compleja si se presenta en forma anidada.

La información se menos compleja se se presenta en modo afirmativo o positivo, y es más compleja si
se presenta en modo negativo.

Uno de los aspectos más interesantes del diseño de programas es la relación que
puede establecerse con las estructuras de organización humanas, particularmente la
jerarquía de administración encontrada en la mayoría de las grandes organizaciones.

Diagrama de Organización de una Empresa ->

Es un sistema (o un componente) con entradas conocidas, salidas conocidas, y generalmente transformaciones conocidas, pero del cual no se conoce el contenido en su interior

es una representación de la
relación lógica existente entre los elementos individuales de datos. Debido
a que la estructura de la información afectará invariablemente al diseño

procedimental final, la estructura de datos es tan importante como la

estructura del programa en la representación de la arquitectura del

software

representa la organización (frecuentemente jerárquica) de los componentes
del programa (módulos) e implica una jerarquía de control. No representa
aspectos procedimentales del software, tales como

secuencias de procesos, o la repetición de operaciones.

La arquitectura del software se refiere a dos características importantes del
software de computadoras:
1. la estructura jerárquica de los componentes procedimentales (módulos)

2. la estructura de datos.

La arquitectura implica modularidad, el
software se divide en componentes con
nombres y ubicaciones determinados,

que se denominan módulos, y que se

integran para satisfacer los requisitos del

problema.

La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales. Se desarrolla una jerarquía descomponiendo una declaración macroscópica de una función de una forma sucesiva, hasta que se llega a las sentencias del lenguaje de programación.

El uso de la abstracción también permite trabajar con conceptos y términos que son familiares al entorno del problema, sin tener que transformarlos a una estructura no familiar

Permite concentrarse en un problema al mismo nivel de generalización, independientemente de los detalles irrelevantes de bajo nivel.

El diseño estructurado, tiende a transformar el desarrollo de software de una práctica artesanal a una disciplina de ingeniería.
- Eficiencia
- Mantenibilidad
- Modificabilidad
- Flexibilidad
- Generalidad
- Utilidad

Un concepto muy relacionado a la confiabilidad y de suma importancia es el de mantenibilidad. Podemos definir la mantenibilidad como:

MTBF: tiempo medio entre fallas (mean time between fairules)
MTTR: tiempo medio de reparación (mean time to repair)

En general, se busca diseños que hagan un uso inteligente de los recursos. Estos recursos no incluyen solamente procesador y memoria, también incluyen almacenamiento secundario, tiempo de periféricos de entrada salida, tiempo de líneas de teleproceso, tiempo de personal, y más.

Un programa es bueno si sus algoritmos son astutos y no obvios a otro programador; esto refleja la "inteligencia" del programador

Es el proceso de decidir que componentes, y la interconexión entre los mismos, para solucionar un problema bien especificado".
El diseño es una actividad que comienza cuando el analista de sistemas ha producido un conjunto de requerimientos funcionales lógicos para un sistema, y finaliza cuando el diseñador ha especificado los componentes del sistema y las relaciones entre los mismos.

DIAGRAMA DE CASOS DE USOS

En el Lenguaje de Modelado Unificado, un
diagrama de casos de uso es una especie de
diagrama de comportamiento.

UML mejorado
El Lenguaje de Modelado Unificado define
una notación gráfica para representar casos

de uso llamada modelo de casos de uso

Actor
Se le llama actor a toda entidad externa al sistema que guarda una relación
con éste y que le demanda una funcionalidad. Esto incluye a los operadores

humanos pero también incluye a todos los sistemas externos, además de

entidades abstractas, como el tiempo.

Relaciones
Las tres relaciones principales entre los casos de uso son soportadas por
el estándar UML, el cual describe notación gráfica para esas relaciones.

Veamos una revisión de ellas a continuación:

Inclusión (include o use)
Es una forma de interacción o creación, un caso de uso dado puede "incluir"
otro caso de uso. El primer caso de uso a menudo depende del resultado del

caso de uso incluido

Extensión (Extend)
Es otra forma de interacción, un caso de uso dado (la extensión)
puede extender a otro. Esta relación indica que el comportamiento del caso de

la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre

debe tener extensión o inclusión.

Generalización
"Entonces la Generalización es la actividad de identificar elementos en común
entre conceptos y definir las relaciones de una superclase (concepto general) y

subclase (concepto especializado).

Es una manera de construir clasificaciones
taxonómicas entre conceptos que entonces se representan en jerarquías de
clases

DIAGRAMA DE CLASES

es un tipo de diagrama estático que describe la estructura
de un sistema mostrando sus clases, atributos y las relaciones entre ellos

Los
diagramas de clases son utilizados durante el proceso de análisis y diseño de los
sistemas, donde se crea el diseño conceptual de la información que se manejará

en el sistema, y los componentes que se encargaran del funcionamiento y la

relación entre uno y otro.

Clases

(Atributos, métodos y visibilidad)
 Los atributos: o características de una clase pueden ser de tres tipos, los
que definen el grado de comunicación y visibilidad de ellos con el entorno,

 Métodos: Los métodos u operaciones de una clase son la forma en como

ésta interactúa con su entorno.

Relaciones

(Herencia, Composición, Agregación, Asociación y Uso)
Herencia (Especialización/Generalización): Indica que una subclase hereda los
métodos y atributos especificados por una Super Clase, por ende la Subclase

además de poseer sus propios métodos y atributos, poseerá las características

y atributos visibles de la Super Clase (public y protected).

Agregación: Para modelar objetos complejos, bastan los tipos de datos
básicos que proveen los lenguajes:
enteros, reales y secuencias de

caracteres.

Asociación: La relación entre clases conocida como Asociación, permite
asociar objetos que colaboran entre si.

DIAGRAMA DE TRANSICIÓN DE ESTADOS

muestran el conjunto de estados por los cuales pasa un
objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo,
mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y

acciones.

Estado
- Comportamiento del sistema que es observable en el tiempo. Los sistemas tienen un estado inicial, pero pueden tener múltiples estados finales (mutuamente excluyentes).
- Cambios de estados: condiciones y acciones.
- Un diagrama de transición de estados puede utilizarse como una especificación de proceso de un proceso de control de un DFD.

Transición
- Son grafos dirigidos que especifican el reconocimiento de un token como elemento del lenguaje.
- En un diagrama de transición (DT) se compila un token

DIAGRAMA DE ESTRUCTURA

Es una forma de descomposición funcional, muestra la partición del sistema en módulos y su jerarquía. Es un árbol o diagrama jerárquico que define la arquitectura completa de un sistema mostrando sus módulos y sus interrelaciones.

DIAGRAMA DE FLUJO DE DATOS (DFD)

Muestran en forma visual sólo el flujo de datos entre los distintos procesos, entidades externas y almacenes que conforman un sistema.
- Cuando los analistas de sistemas indagan sobre los requerimientos de información de los usuarios, deben ser capaces de concebir. la manera en que los datos fluyen a través del sistema u organización, los procesos que sufren estos datos y sus tipos de salidas.

Elementos de un diagrama de flujo de datos

Otros símbolos para los elementos de un DFD

MODELO ENTIDAD/RELACION EXTENDIDO

Es un modelo conceptual de datos de alto nivel:
Sirve para representar los conceptos del Mundo que nos interesan con sus relaciones y características

Es una herramienta muy utilizada directamente o a través de otras herramientas o programas (como Data-Architect de Sybase).

FASES en el DISEÑO de una BASE de DATOS:
- Fases independientes del SGBD (Sistema Gestor de Bases de Datos, o DBMS DataBase Management System), para obtener:

Esquema Conceptual: Definición de datos, relaciones...

Especificación de funciones necesarias (transacciones).
- Fases dependientes del SGBD, para obtener:

Esquema Interno: Ficheros donde almacenar datos, directorios...

Programas para efectuar las transacciones.

Herramientas Case

Se consideran CASE a un conjunto de herramientas relacionadas que soportan todos los aspectos del ciclo de desarrollo del software, incluyendo aquellas que soportan fases especificas del ciclo de vida

Conjunto de herramientas que tratan de optimizar la tarea de trabajar con sistemas. Los problemas por los que aparecieron las Herramientas CASE son:

Recursos insuficientes para desarrollar el nuevo software. Tratar de mejorar la productividad.
- Problemas en el software existente: mejorar la calidad del software.
- Altos costos de mantenimiento

QUÉ ES UNA HERRAMIENTA CASE

Las herramientas CASE deberían cumplir las
siguientes funciones:
- Manejo de metodología de ingeniería de software a la medida de la organización, eso incluye notaciones gráficas y reglas de control.
- Manejo de gráficas para múltiples tipos de modelos (DFD, DER, DTE, etc.)
- Módulos de revisión de errores para asegurar la precisión de esos modelos, es decir que sean completos e internamente consistentes.

¿CUÁNDO UNA HERRAMIENTA ES INTEGRADA?

Integración de plataformas: se refiere a una herramienta con un conjunto común de servicios proporcionados por el ambiente operativo. Por ejemplo, el ambiente UNIX.

Integración de presentación: se refiere a la definición de una interfase de usuario consistente entre las diferentes herramientas. Estandarizar las interfases de usuario aumenta la flexibilidad y simplifica la elección de las herramientas por parte de los usuarios.

Integración de control: se refiere a la habilidad de las herramientas para informar a otras herramientas de sus acciones y recibir requerimientos de otras herramientas.

Integración de datos: se refiere a la transferencia de información entre herramientas y al establecimiento de las relaciones entre datos utilizando diferentes herramientas

Integración de procesos: se refiere a la automatización de la secuencia de actividades que la organización ha definido como componentes del ciclo de vida del desarrollo del software.

¿QUÉ SOFTWARE DE BASE USA UNA CASE INTEGRADA?

Son necesarios:
- Un repositorio, que almacena información
- Un sistema de manejo de objetos, para manejar los cambios en la información
- Un control de herramientas, para coordinar su utilización
- Una interfaz de usuario avanzada, para proporcionar una vía consistente entre el usuario y las herramientas contenidas en el entorno.
- Un sistema operativo multitarea, de manera de poder trabajar con varias herramientas simultáneamente.
- Una arquitectura de red, como un entorno CASE es una red distribuida, los mecanismos básicos deben poder funcionar en red.

SERVICIOS DE UN REPOSITORIO CASE

Los servicios que debe proporcionar el gestor de BD de un buen repositorio CASE, son de dos tipos, los normales de cualquier sistema de gestión de base de datos y los específicos del entorno CASE.

Los servicios normales son:
- Almacenamiento no redundante
- Acceso de alto nivel: un único mecanismo de acceso para todas las herramientas.
- Independencia de los datos
- Control de transacciones
- Seguridad
- Consulta de los datos y gestión de informes
- Apertura: mecanismo sencillo para importar/exportar datos.
- Soporte multiusuario.

¿QUÉ VENTAJAS Y DESVENTAJAS TIENEN LAS CASE?

Se pueden llegar a obtener las siguientes ventajas:
- Menor tiempo de mantenimiento
- Mayor independencia entre análisis, diseño y programación
- Mayor independencia del análisis y diseño con respecto a un entorno en particular.
- Trabajar con tareas de mayor nivel que la codificación pura.
- Mejora de la calidad del producto de software
- Aplicaciones más productivas para la empresa.