clase 2

Metodologías de Diseño

24/6/2008

Christian Sifaqui

4 Notaciones en diseño de software y documentación

Existen numerosas notaciones para representar artefactos de diseño. Algunas se usan durante el diseño arquitectónico, otras durante el detallado y otras en ambas

4 Notaciones en diseño de software y documentación

Se han caracterizado las notaciones en términos de caja negra versos caja blanca:

- notación caja negra: se preocupa con las propiedades externas de los elementos del modelo de diseño

- notación caja blanca: se preocupa mayormente con describir algunos aspectos de la realización detalladas de un elemento de diseño

4.1 Notaciones en diseño de software

Otra forma es diferenciarlas entre notaciones para describir propiedades estructurales (estáticas) y las que describen propiedades conductuales (dinámicas)

4.1.a Algunas descripciones estructurales (vista estática)

Diagramas de clase y objeto: se usan para representar un conjunto de clases (y objetos) y sus relaciones. Una notación antigua relacionada son los diagramas entidad-relación, usados para representar modelos conceptuales de datos almacenados en sistemas de información. UML tiene esta notación


Diagramas de componentes: se usan para modelas la vista de implementación estáticas de un sistema, es decir, cosas físicas (y sus relaciones) como ejecutables, librerías, tablas, archivos y documentos. A pesar que si uso principal es durante la construcción, estos diagramas pueden ser usados durante diseño, por ejemplo, para documentar la estructura de un módulo. UML tiene esta notación


Diagramas de deployment: se usan para modelar la vista de deployment estático de un sistema, es decir, la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que viven en ellos. Típicamente estos diagramas pueden ser usados para representar aspectos de distribución, por ejemplo un modelo empotrado, cliente/servidor o sistemas distribuidos. UML tiene esta notación


Cartas de estructuras: se usan para describir la estructura de llamado de un programas, es decir, cuál módulo es invocado por otro módulo. Estos diagramas son inherentes de la aproximación de diseño orientado a la función.


Diagramas de Jackson: se usan para describir las estructuras de datos manipuladas por un programa en términos de secuencia, selección e iteración.

4.1.b Algunas descripciones conductuales (vista dinámica)

Diagramas de actividad: se usan para mostrar el flujo de control de actividad (ejecución continua no-atómica dentro de una máquina de estado) a otra actividad. UML tiene esta notación.


Diagramas de interacción: se usan para mostrar las interacciones entre un grupo de objetos. Estos diagramas vienen en dos tipos: diagramas de secuencia ponen el énfasis en el ordenamiento temporal de los mensajes, mientras que los diagramas de colaboración ponen el énfasis en los objetos, sus enlaces y los mensajes que intercambian en estos enlaces. UML tiene esta notación.


Diagramas de flujo de datos: se usan para mostrar el flujo de datos entre un ocnjunto de procesos.


Diagramas de transición de estados y diagramas de statecharts (utilizados en UML): se usan para mostrar el flujo de control de estado a estado en una máquina de estados.


Pseudocódigo y lenguajes de diseño de programas: son lenguajes estructurados similares a programación que se usan ara describir en la etapa de diseño detallado la conducta de un procedimiento o método.

4.2 Documentación de diseño

Dada la variedad de notaciones disponibles, se presenta la dificultad de cómo combinarlas para confeccionar un documento de diseño coherente.

No hay respuesta definitoria. Depende de muchos aspectos: tipo de software a desarrollar, las personas involucradas, etc.


Una práctica a usar son las vistas (ver 2.1)

La selección de un conjunto apropiado de vistas depende de las personas involucradas: administradores del proyectos, desarrolladores, testeadores e integradores, clientes, usuarios finales, etc.


Satisfacer las diferentes necesidades se puede describir en términos de la importancia relativa de las varias vistas desde cada tipo de vista: módulo, componente-y-conector y asignación (allocation).

Un administrador del proyecto podría requerir vistas de asignación detalladas mientras que un desarrollador podría requerir vistas de módulos y componente-y-conector más detalladas.


Documentar una vista involucra por lo menos, el describir las interfaces de los elementos de esa vista. La definición de esa vista dependerá del tipo de elemento. Una clave característica de cada especificación de interface es que tiene que ser dual: lo que el elemento provee y lo que requiere (los recursos usados por el elemento y las suposiciones que hace del medio ambiente)


Otra idea clave es que el diseño debe ser presentado y documentado en una forma racional, aunque el proceso que lo haya guiado no haya sido perfectamente racional.

5 Estrategias de diseño y métodos

Se han propuesto variados principios generales y estrategias para guiar y mejorar la calidad del software resultante.

En contraste a las estrategias, los métodos son más específicos, ya que sugieren un conjunto particular de notaciones junto con una descripción de un proceso a ser seguido, así como heurísticas para adaptar el proceso a un contexto particular.

5.1 Estrategias generales y técnicas posibilitadoras

Abstracción: el proceso de olvidar información de tal manera que las cosas que son diferentes pueden tratarse como si fueran la misma. Los dos mecanismos son “abstracción por parametrización” abstraer de datos específicos introduciendo parámetros y “abstracción por especificación” abstraer cómo se implementa un módulo referenciando a una especificación apropiada.


Estos mecanismos llevan a los tres grandes tipos de abstracción: abstracción procedural (para introducir nuevos parámetros), abstracciones de datos (para introducir nuevos tipos de datos) y abstracción de control/iteración (para iterar sobre colecciones de elementos)


Cohesión y acoplamiento: acoplamiento se define como la fuerza de las relaciones entre las componentes de software, mientras que cohesión se define por cómo los elementos que conforman un componente se relacionan. Como regla general, acoplamiento ente componentes debe ser débil, mientras que la cohesión (interna) de un componentes debe ser alta


Dividir y vencer: es una técnica para resolver un problema complejo dividiéndolo en problemas más simples, que se resuelven recursivamente y cuyas soluciones se combinan para obtener la solución general. Una estrategia relacionada es la separación de asuntos, que sugiere que responsabilidades diferentes o no relacionadas deben ser separadas entre sí


Ocultamiento de la información y encapsulamiento: ocultamiento de la información se define donde cada módulo se caracteriza por el conocimiento de la decisión de diseño que la oculta de los otros. Un principio clave es la separación de la interfaz y la implementación donde se especifica una interfaz pública conocida por los clientes, que separa los detalles de cómo lo realiza el componente


Encapsulamiento es el agrupamiento de ideas relacionadas en una una unidad, las que pueden ser referenciada después por un solo nombre. Encapsulamiento combina elementos para crear una nueva unidad, cuyos detalles internos son ocultados.


Suficiencia, completitud y primitividad: estas nociones indican que un componente debe capturar todas las características importantes de una abstracción para interactuar con ella y ninguna más

5.2 Diseño orientado a la función (estructurado)

Es uno de los primeros paradigmas de diseño, que se centra en identificar las funciones principales de un sistema, y luego refinarlas en una manera top-down.El diseño estructurado se realiza después del análisis estructurado. Este análisis produce DFDs con descripciones de procesos y también se pueden usar diagramas E-R


Se han propuesto dos estrategias para derivar una arquitectura de software a partir de un DFD:- Análisis de transacción: una transacción se caracteriza por algún evento en el medio ambiente que genera un estímulo al sistema, quien a su vez gatilla alguna actividad que produce una respuesta teniendo un efecto hacia el medio ambiente. El análisis de transacciones consiste en identificar los tipos de transacciones claves de un sistema y usarlos como unidades de diseño, esto es, diseñando separadamente el procesamiento de cada tipo de transacción.


- Análisis de transformación: el paso clave para derivar un diagrama de estructura de un DFD (para una transacción dada) es identificar la transacción central, esto es, la porción de un DFD que contiene las funciones esenciales del sistema y es independiente de la implementación de la entrada y salida. Una carta de estructura borrador se puede obtener “elevando” las burbujas asociadas a la transformación central.


P1

P5

P6

P3

P4

P2 P5

P6P1

a1

a2

a2 a3

e1

e2

a3

e1

e2a1

a2

a2

transformación central

DFD Diagrama de estructura

P2 P3

P4


Los conceptos claves del diseño estructurado son acoplamiento y cohesión. Un buen diseño debe restringir el acoplamiento a tipos normales de acoplamiento (datos, estampado, y control) siendo el de datos el preferido, donde la comunicación entre módulos es a través de parámetros, donde cada parámetro es un pedazo de datos elemental, evitando así las formas patológicas de acoplamientos, como la común y de contenido.


Un buen diseño debe dar preferencia a módulos de alta cohesión, es decir, módulos que exhiban cohesión funcional, que es cuando el módulo contiene todos los elementos que contribuyen a la ejecución de una y sólo una tarea relacionada al problema.

Existen otras formas de cohesión más débiles se han identificado: secuencial, comunicacional, procedural, temporal, lógica y coincidental.


Otras heurísticas se han sugerido para ayudar a mejorar la calidad del diseño resultante:Fan-in/fan-out: un alto fan-in (número de módulos que llaman a un módulo M) es considerado bueno, ya que indica el reuso de M. Por su parte un bajo o moderado fan-out (número de módulos que M invoca) -máximo 5 a 7- es preferible.


Particionamiento de decisiones: se debe evitar la división de decisiones, que ocurren cuando el reconocimiento de una condición y la ejecución de la acción asociada no se mantienen dentro del mismo módulo.


Sistemas balanceados: se prefiere un sistema balanceado, es decir, cuando los módulos de alto nivel tratan con la lógica y datos abstractos (datos limpios y válidos, independientes del formato de implementación)

5.3 Diseño orientado a objeto

La noción de objeto está íntimamente relacionado con las nociones de abstracción de datos, encapsulamiento y tipo abstracto de datos.A través de los años, se han propuesto numerosos métodos de diseño.UML no es un método de diseño, es sólo un conjunto de notaciones neutral con respecto a cualquier método de diseño específico. Revisar proceso unificado

5.4 Diseño orientado a la estructura de datos

También se conoce como programación estructurada de Jackson. El énfasis se basa en los datos que manipula el programa en vez de las funciones que realiza. El énfasis se basa en que los datos son más estables (menos sujetos a cambios) que las funciones que debe desarrollar.

5.4 Diseño orientado a la estructura de datos

El diseñador describe los datos de entrada y salida, usando los diagramas de estructura de Jackson, y desarrolla entonces la estructura de control del programa estableciendo una correspondencia apropiada entre los diagramas de estructura de entrada y salida.

clase 2

Documents