Diseño de Softwares.

Heliut Sánchez Cuevas, AS15592345, UNADM, Propedéutico, Actividad 1 (Lectura y escritura exploratoria), 19 de Noviembre del 2014

1. Introducción.

En este trabajo se explicará, en forma resumida y más sencilla de acuerdo a nuestro nivel de conocimientos sobre el tema, lo que el autor quiso dar a entender a sus lectores, tratare de citar palabras y lenguaje menos técnico pero más entendible a personas que no tenemos el conocimiento básico de lo que es el “Diseño de Software”, el objetivo es contar con conocimientos básicos de cada tema tratando de abordar la totalidad del texto.

Resumen hecho del escrito denominado “Diseño de Software”, Editado por internet en la dirección URL: http://www.ciens.ucv.ve:8080/senasig/sites/disist/archivos/clase2.pdf

2. Desarrollo.

Contenido.

Diseño de Software Principios del Diseño Arquitectura de Software

Especificación de Arquitecturas

Diseño de Software

Descripción de la estructura del programa especifico de que se trate, las conexiones entre los componentes del sistema, y algunas veces, los algoritmos utilizados.

El diseño incluye: formalidad y detalles durante el desarrollo del

diseño, y regresar a los diseños anteriores y corregirlos.

El proceso de diseño incluye el desarrollo de varios modelos con diferentes niveles de abstracción

Especificación La retroalimentación entre estas actividades y la consecuente

repetición del trabajo es inevitable en todo proceso de diseño.Especificación

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

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

3. Diseño de interfaz: describe cómo se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean.

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

Los sistemas grandes siempre se descomponen en subsistemas que suministran algún conjunto relacionado de servicios.

El proceso de diseño inicial para identificar estos subsistemas y

establecer un marco de trabajo para el control y comunicación de los subsistemas se llama diseño arquitectónico y lo que produce este proceso de diseño es una descripción de la Arquitectura de Software.

Principios del Diseño de Software

No debería ponerse “orejas” (considerar enfoques alternativos).

Se debería poder seguir los pasos del diseño desde el modelo de análisis.

No debe inventar nada que ya esté inventado.

Debería “minimizar la distancia intelectual” entre el software y el problema tal y como existe en el mundo real.

Debería presentar uniformidad e integración.

Debería estructurarse para admitir cambios.

Debería estructurarse para degradarse poco a poco, incluso cuando se enfrenta a datos, sucesos o condiciones operativas aberrantes.

No es escribir código y escribir código no es diseñar.

Se debería valorar la calidad del diseño mientras se crea no después de terminarlo.

Se debería revisar el diseño para minimizar los errores conceptuales (semánticos).

ABSTRACCIÓN

La noción psicológica de abstracción permite concentrarse en un problema a un nivel de generalización independiente de los detalles de nivel inferior, la abstracción también permite trabajar con conceptos y términos que son familiares en el entorno del problema sin tener que transformarlos en una estructura poco familiar.

Cada fase del proceso de ingeniería del software es un

refinamiento en el nivel de abstracción de la solución software. Finalmente se alcanza el nivel inferior de abstracción cuando se construye el código.

Abstracción procedimental: es una secuencia dada de instrucciones que tiene una función específica y limitada.

Abstracción de datos: es una colección determinada de datos que describen un objeto de datos.

Abstracción de control: implica un mecanismo de control del programa sin especificar detalles internos

REFINAMIENTO PASO A PASO

La arquitectura de un programa se desarrolla refinando sucesivamente niveles de detalle procedimental.

Se desarrolla una jerarquía descomponiendo un enunciado

macroscópico de función (una abstracción procedimental) al estilo paso a paso hasta que se llega a los enunciados del lenguaje de programación.

MODULARIDAD.

Se divide el software en componentes identificables y tratables

por separado, denominados módulos, que están integrados para satisfacer los requisitos del programa.

La modularidad es el atributo del software que permite a un

programa ser manejable intelectualmente. La complejidad percibida de un problema que combina p’ y p’’; es mayor que la complejidad percibida cuando cada problema se considera por separado.

Hay un número m de módulos que resultarían en un costo de

desarrollo mínimo, pero no tenemos la sofisticación necesaria para predecir m con seguridad.

Meyer define cinco criterios que permiten evaluar un método de diseño con respecto a su capacidad de definir un sistema modular eficaz:

Capacidad de descomposición funcional: mecanismo sistemático de descomposición del problema en sub-problemas.

Capacidad de empleo de componentes modulares: ensamblar componentes de diseño existentes.

Capacidad de comprensión modular: entender un módulo como una unidad por sí sola.

Continuidad modular: cambios en los módulos individuales, en vez de cambios generalizados en el sistema.

Protección modular: los efectos se restringen dentro de ese módulo.

JERARQUÍA DE CONTROL (estructura del programa).

Representa la organización (a menudo jerárquica) de componentes del programa (módulos) e implica una jerarquía de control

PARTICIÓN ESTRUCTURAL.

Partición horizontal: define ramas separadas de la jerarquía modular para cada función principal del programa. El enfoque más simple de partición horizontal define tres particiones: entrada, procesamiento y salida. Es más fácil de probar y de mantener,

propaga menos efectos secundarios, el software es más fácil de ampliar.

Partición vertical: o factoring (descomposición en factores), sugiere que el control (toma de decisiones) y el trabajo se distribuyan descendentemente en la arquitectura del programa.

Los módulos del nivel superior deben realizar funciones de

control y poco trabajo de procesamiento.

Los módulos que residen en la parte baja de la arquitectura deberían ser los trabajadores, realizando todos los trabajos de entrada, cálculo y salida.

Las arquitecturas de partición vertical tienen menos

probabilidad de ser susceptibles a efectos secundarios cuando se hacen cambios y tendrán por tanto mejor capacidad de mantenimiento, un factor clave para la calidad.

PROCEDIMIENTO DEL SOFTWARE.

El procedimiento del software se centra en los detalles de procesamiento de cada módulo individualmente.

El procedimiento debe proporcionar una especificación exacta

del procesamiento, incluyendo la secuencia de acontecimientos, puntos exactos de decisión, operaciones repetitivas e incluso la organización/estructura de los datos.

DISEÑO MODULAR EFECTIVO.

Los conceptos fundamentales de diseño sirven para incentivar diseños modulares.

Un diseño modular reduce la complejidad, facilita los cambios y hace más fácil la implementación al fomentar el desarrollo en paralelo de diferentes partes de un sistema.

1. INDEPENDENCIA FUNCIONAL.

Se consigue desarrollando módulos con una función única y una aversión a excesiva interacción con otros módulos. Cada módulo trate una sub-función específica de los requisitos y tenga una sencilla interfaz cuando se vea desde otras partes de la estructura del programa.

Es más fácil de desarrollar porque la función se puede

compartir y las interfaces se simplifican.

Los módulos independientes son más fáciles de mantener y probar porque los efectos secundarios causados por la modificación del diseño/código están limitados, la propagación de errores es reducida y se pueden usar módulos reutilizados.

La independencia se mide usando dos criterios cualitativos:

cohesión y acoplamiento. La cohesión es una medida de la fuerza relativa funcional de un módulo. El acoplamiento es una medida de la interdependencia relativa de entre los módulos.

2. COHESIÓN.

Es una extensión natural del concepto de ocultamiento de la información. Un módulo con cohesión realiza una sola tarea dentro de un procedimiento de software, requiriendo poca interacción con los procedimientos que se realizan en otras partes del programa. Un módulo con cohesión debería hacer una sola cosa.

Siempre debemos buscar la cohesión más alta, aunque la

parte media del espectro es a menudo aceptable. Disperso De un solo propósito

Coincidencialmente cohesivo: un módulo que realiza un conjunto de tareas poco relacionadas las unas con las otras.

Cohesión lógica: realiza tareas relacionadas lógicamente (produce toda las salidas).

Cohesión temporal: contienen tareas relacionadas por el

hecho de que todas deben hacerse en el mismo intervalo de tiempo.

Cohesión procedimental: cuando los elementos de procesamiento están relacionados y deben ejecutarse en un orden específico.

Cohesión de comunicación: todos los elementos de

procesamiento se concentran en un área de la estructura de datos.

3. ACOPLAMIENTO.

Es una medida de la interconexión entre los módulos de la estructura de un programa. Depende de la complejidad de la interfaz entre los módulos, el punto en el que se entra o se hace referencia al módulo y qué datos pasan a través de la interfaz. Intentamos conseguir el menor nivel posible de acoplamiento. Las conexiones sencillas entre los módulos hacen que el software sea más fácil de entender y menos dado al efecto ola.

Acoplamiento de datos: está subordinado al módulo a y se accede a él por medio de una lista convencional de argumentos a través de la cual se pasan los datos.

Acoplamiento de marca: cuando en vez de argumentos

simples se pasa una porción de la estructura de datos se pasa por la interfaz del módulo.

Acoplamiento de control: se pasa un indicador de control (una

variable que controla las decisiones en el módulo subordinado).

Acoplamiento externo: cuando los módulos están atados a un entorno externo al software. Por ejemplo, las I/O y los dispositivos.

Acoplamiento común: varios módulos hacen referencia a un

área global de datos.

Acoplamiento de contenido: un módulo hace uso de datos o de información de control mantenidos dentro de los límites de otro

módulo. Cuando se realiza una bifurcación hacia la mitad de otro módulo.

Arquitectura de Software

La Arquitectura del Software de un programa o sistema de Computación, es la estructura o estructuras del sistema, la cual comprende componentes de Software, propiedades externas de esos componentes y la interacción entre ellos [Bas el al 2003].

Por otra parte, Clements [SEI, 2001] señala que la Arquitectura del

Software es vagamente definida como la estructura organizacional de un sistema de Software que incluye componentes, conexiones, restricciones.

Se obtiene mediante un proceso de partición que relaciona los elementos de una solución de software con partes de un problema del mundo real definido implícitamente durante el análisis de los requisitos. La solución aparece cuando cada parte del problema está resuelta mediante uno o más elementos de software.

El diseño y la especificación completa de la estructura de los

sistemas de software, según Shaw y Garlan (1996), se está transformando en un aspecto de más importancia que la escogencia de los algoritmos y las estructuras de datos, en virtud del tamaño y la complejidad de estos es la actualidad

Diseñar la arquitectura del software, según estos mismos autores, es definir los aspectos estructurales como una composición de componentes, las estructuras globales de control, los protocolos de comunicación, la sincronización y acceso a los datos, la asignación de la funcionalidad a los elementos del diseño, la composición de estos elementos, su distribución física, su escalabilidad y su desempeño.

Define al sistema en términos de elementos computacionales y de las interacciones entre ellos.

La arquitectura muestra la correspondencia entre los requerimientos

de sistemas y los elementos del sistema construido, proveyendo así una exposición racional para las decisiones de diseño.

ELEMENTOS COMPUTACIONALES. Son entidades tales como clientes, servidores, bases de datos, filtros y capas de un sistema jerárquico. Son además, una parte encapsulada del sistema de software, donde cada uno tiene una interfaz.

INTERACCIONES. Ocurren entre los elementos a nivel de diseño,

pudiendo ser tan simples como las llamadas a procedimientos o variables de acceso, o tan complejas y semánticamente ricas como los protocolos del modelo cliente/servidor, los protocolos de acceso a las bases de datos. (Shaw y Garlan, 1996).

RELACIONES. Denotan las conexiones entre los elementos computacionales y/o componentes.

Una relación puede ser estática o dinámica.

Relaciones estáticas. Se muestran en el código fuente, ellas

reflejan la colocación de los componentes dentro de la arquitectura.

Relaciones dinámicas. Tratan con las conexiones temporales y las interacciones dinámicas entre los componentes. Ellas no son fácilmente visibles a partir del código fuente.

Representación de la Arquitectura

En la actualidad el desarrollo de los sistemas se centra en la arquitectura de software y es especificada utilizando el Modelo 4+1 Vistas de Kruchten (1995).

VISTA LÓGICA. Describe el modelo objeto del diseño cuando un método de diseño O-O es usado; se puede usar un enfoque alterno para desarrollar alguna otra forma de vista lógica.

VISTA DE PROCESO. Describe los aspectos de diseño relacionados

con la concurrencia y la sincronización.

VISTA IMPLANTACIÓN. Describe el mapa del SW dentro del HW refleja los aspectos de distribución.

VISTA DE IMPLEMENTACIÓN. Describe la organización estática del software en el ambiente de desarrollo.

CASOS DE USO. Los diseñadores de software organizan la

descripción de sus decisiones arquitecturales alrededor de estas cuatro (4) vistas, y las ilustran con una pequeña selección de casos de uso o escenarios, constituyendo así la quinta vista. La arquitectura está parcialmente producida por esos escenarios.

Si una propiedad de un elemento arquitectónico no es visible o no es

discernible de cualquier otro elemento arquitectónico, ese elemento no es arquitectónico.

La selección de un manejador de base de datos no es una decisión

arquitectónica. La razón de su existencia “no es materia” (no le concierne) a las metas arquitectónicas.

Las decisiones son arquitectónicas o no de acuerdo al contexto. Si la

estructura es importante para alcanzar las metas del sistema la estructura es arquitectónica.

3. Conclusión

El diseño de software es considerado la base de la programación, del desarrollo de sistemas, puesto que es el estudio de cómo queremos que

funciones una serie de ordenamientos sistematicos para lograr simplificar las funciones, o en si ahorrar trabajo humano y tiempo para llegar al mismo resultado; el empleo de bases de datos, y de información elazada por medio de la tecnología del internet nos da un visión universal con respecto a la información de determinado lugar, tiempo y espacio.

Con este pequeño escriño pudimos darnos cuenta de lo fácil y a la vez complejo que pueden llegar a ser los software, pero al final son requeridos y demandados por la actualización humano en el desarrollo adaptativo de cada persona, de cada sociedad y en si del planeta.

Referencias

Página de internet

http://www.ciens.ucv.ve:8080/senasig/sites/disist/archivos/clase2.pdf

¿Por qué he elegido este tema?

Es un tema que se me facilita, puesto que ya tengo conocimiento en desarrollo de programas, así como el hecho de que me llama mucho la atención sobre el desarrollo en especial, de igual manera pude detectar que el escrito que elegí está muy completo casi no pude resumir nada puesto que lo que expresan es tan importante ya que juega una importante conexión con todo el desarrollo del mismo.

¿De dónde partí para empezar a escribir?

Como en cada estructura lógica, siempre se inicia desde las bases, puesto que no todas las personas tienen la facilidad de entender a la misma velocidad, en la mayoría de la ocasiones se recomienda hacer una retroalimentación de lo ya conocido para poder continuar en forma escalonada con lo que vamos a aprender lo nuevo, es asi como se desarrolla este trabajo.