によって SEBASTIAN NARVAEZ BARON 2年前.
127
もっと見る
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.
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.
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.
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.
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.
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 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 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 plataformas: se refiere a una herramienta con un conjunto común de servicios proporcionados por el ambiente operativo. Por ejemplo, el ambiente UNIX.
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.
Herramientas Case
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
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
Programas para efectuar las transacciones.
Especificación de funciones necesarias (transacciones). - Fases dependientes del SGBD, para obtener:
Esquema Interno: Ficheros donde almacenar datos, directorios...
Esquema Conceptual: Definición de datos, relaciones...
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:
Es una herramienta muy utilizada directamente o a través de otras herramientas o programas (como Data-Architect de Sybase).
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
Otros símbolos para los elementos de un DFD
Elementos de un diagrama de flujo de datos
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.
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.
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
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.
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.
Relaciones
Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si.
Agregación: Para modelar objetos complejos, bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres.
(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).
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.
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.
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:
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
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.
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
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.
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
MTBF: tiempo medio entre fallas (mean time between fairules) MTTR: tiempo medio de reparación (mean time to repair)
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.
Una llamada a una subrutina que involucra 100 parámetros, será más compleja que una que involucra solo 3.
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.
Estos factores determinan la probabilidad de error humano en el procesamiento de información de todo tipo. Mientras que la complejidad de todo tipo de sentencias de programas pueden evaluarse según estos criterios, enfocaremos la atención en aquellas que establecen relaciones intermodulares.
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.
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
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).
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
Es particularmente útil cuando se procesa secuencialmente la información y no existe ninguna estructura jerárquica formal.
El diseño orientado al flujo de datos es compatible con un amplio rango de áreas de aplicación
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
. Los datos bien diseñados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida
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
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.
Intervalo
Deben incluirse en la misma unidad de carga los módulos con intervalos breves de tiempo entre activaciones.
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.
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.
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.
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.
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.
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 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.
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 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 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 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
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
Final
Primer nivel de Factorización
Diagrama de flujo de datos
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.
6. Para cada acción en una transacción, especificar un módulo de acción subordinado al módulo de transacción correspondiente.
5. Para cada transacción, o colección cohesiva de transacciones, especificar un módulo de transacción para procesarlo completamente.
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.
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.
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.
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
Centro de Transaccion
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.
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.
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
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.
Una transacción es cualquier elemento de datos, control, señal, evento, o cambio de estado, que causa, dispara, o inicia alguna acción o secuencia de acciones.
El análisis de transacción es sugerido por un DFD del siguiente tipo:
Similarmente existe un salto mayor entre la cohesión lógica y la temporal que entre casual y lógica.
La cohesión secuencial es más próxima al óptimo funcional que a su antecesor de comunicación
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
En ella, los datos de salida (resultados) de un elemento de procesamiento sirven como datos de entrada al siguiente elemento de procesamiento.
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
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.
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.
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.
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).
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 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.
Otras técnicas para reducir el acoplamiento son
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.
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.
Estandarización de las conexiones.
Convertir las referencias implícitas en explícitas. Lo que puede verse con mayor facilidad es más fácil de comprender.
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.
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.
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.
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
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
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
Tipos de conexiones entre módulos
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.
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.
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
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.
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 conexión entre módulos: los sistemas normalmente conectados, tienen menor acoplamiento que aquellos que tienen conexiones patológicas.
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:
Almacén: Representa una colección de paquetes de datos que permanecen en estado de reposo
Flujo de datos: El flujo describe el movimiento de paquetes de datos que viajan desde una parte del sistema a otra.
Firmar y sellar actas: Proceso manual que se limita a autenticar las Copias Certificadas previa su entrega al solicitante
Registro automático de libros; en él se almacena una serie de datos proveniente del procesamiento de las solicitudes
Generar copias certificadas; encargado de procesar los reportes generados por el sistema, en este caso la emisión directa de las Copias Certificadas solicitadas.
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.
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
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.
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.
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.
Diagrama de flujo de datos: Es la base para otros componentes y describe como navegan los datos entre procesos y elementos relacionados.
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
Diseño procedimental. Transforma elementos estructurales de la arquitectura del programa en una descripción procedimental de los componentes del software.
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 arquitectónico. Define la relación entre los principales elementos estructurales del programa
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.
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
Mantenimiento: Es la etapa más difícil de desarrollo del sistema, actualiza y modifica el sistema si surgen nuevos requerimientos.
Testeo: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios de- terminados por el grupo correspondiente
Implementación: Dado el lenguaje de programación elegido se implementa el sistema
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.
Análisis: Modela los requerimientos del usuario.
Especificación de requerimientos: Se realizan entrevistas con el usuario identificando los requerimientos y necesidades del usuario.
- 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.
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:
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.
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
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.
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).
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.
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.
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).
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
Reduciendo el número de relaciones necesarias: Cuanto menos conexiones existan entre módulos, menor será la posibilidad del efecto en cadena
Eliminando relaciones innecesarias: Por ejemplo, un módulo puede recibir algunos datos, innecesarios para él, porque debe enviarlos para un módulo subordinado
