CONCEPTOS Y PRINCIPIOS BSICOS

El Diseo de Software es la actividad del ciclo de vida del software en la cual se

analizan los requisitos para producir una descripcin de la estructura interna del software que

sirva de base para su construccin

PRINCIPIOS

Los Principios del Diseo Software son nociones clave consideradas fundamentales en

muchas aproximaciones y conceptos de diseo diferentes.

ABSTRACCIN

Olvidar informacin que diferencia ciertas cosas y as poder tratarlas como si fueran

similares.

DESCOMPOSICIN

Descomponer un software en diversas unidades ms pequeas, habitualmente con el

fin de situar diferentes funcionalidades o responsabilidades en diferentes componentes.

ENCAPSULAMIENTO

Consiste en agrupar y empaquetar los elementos y detalles internos de una abstraccin

y hacer que dichos detalles sean inaccesibles desde fuera.

 SEPARACIN DE INTERFAZ E IMPLEMENTACIN

Definir un componente especificando una interfaz pblica, conocida por otros

componentes o clientes, separada de los detalles de cmo dicho componente est

realizado (implementado)

SUFICIENCIA Y COMPLETITUD

Asegurar que un componente software captura todas las caractersticas importantes

de una abstraccin y ninguna ms.

ELEMENTOS CLAVE DE DISEO DE SOFTWARE

CONCURRENCIA

La concurrencia se da precisamente en el rea de la programacin. Y es que si bien el

desarrollo se realiza despus del diseo, existen metodologas donde el orden no se efecta

de esta manera y pueden combinarse. Lo que si, es que en el diseo se determinan muchas

cosas que pueden afectar la concurrencia del software, como la forma en que se acomodan

los procesos, la relacin que existe entre los hilos o las tareas, la sincronizacin y algunos

aspectos ms que se relacionan con la programacin. Aspectos que en cuestiones de

desarrollo puede incrementar o disminuir la calidad del software.

EVENTOS

Actualmente, el desarrollo de software no trabaja solo como hace muchos aos. Hoy en

da tenemos llamados al servidor, llamados a la base de datos en caso de usarse y cosas de

este tipo, las cuales pueden definir el flujo de datos con el cul trabajar el sistema. El punto

es que parte del diseo de software, es determinar la cantidad de llamadas que se deben

realizar, tratando de no abusar para no saturar un servidor. En este aspecto hay que tener

cuidados para tener una muy buena organizacin de datos y precisamente controlar su flujo

en ejecucin.

DISTRIBUCIN Y RENDIMIENTO

El diseo de software, tambin interviene en lo que es el rendimiento del sistema y el

como se va a distribuir el software en el hardware. Por eso cuando tienes un software nuevo

o vas a instalar una aplicacin, esta te especifica algunos detalles, como el espacio necesario
en disco, la memoria RAM que utilizar preferentemente y algunos puntos ms, los cules

tiene que ver con la forma en que se comunican los componentes y sobretodo en como estn

distribuidos para dar un mejor rendimiento.

TOLERANCIA A FALLOS

Posiblemente una de las claves fundamentales del diseo de software, es que un buen

anlisis, seguido por un buen diseo posteriormente analizado de nuevo, har que nuestro

sistema tenga una gran tolerancia a fallos.

Bsicamente, es necesario detectar cuales son los riesgos potenciales a los cuales nos

enfrentamos y se calcula la probabilidad de que este surja dentro del proceso de la ingeniera,

para posteriormente ordenarlo de acuerdo a la importancia o preocupacin que puede generar

en caso de aparecer. Por ltimo se tendr que establecer un plan para controlar el riesgo, ya

sea evitndolo o tratando de encontrar una solucin al problema.

 ARQUITECTURA Y ESTRUCTURA DEL SOFTWARE

ARQUITECTURA

La arquitectura de un sistema es la descripcin de los elementos que lo forman y de las

interrelaciones entre ellos.

Disponer de la Arquitectura de forma explicita supone las siguientes ventajas:

Comunicacin con los interesados: Puede utilizarse para la discusin sobre como

ser el sistema.

Anlisis del sistema: Permite el anlisis del cumplimiento de los requisitos no

funcionales

Reutilizacin a gran escala: Puede servir para un grupo de sistemas parecidos.

Los atributos de calidad del sistema (requisitos no funcionales ) se ven afectados por la

arquitectura:

-Rendimiento: Utilizar componentes grandes en vez de grano fino para concentrar

las operaciones criticas y minimizar las comunicaciones.

Seguridad: Usar una arquitectura por capas con los activos crticos en las capas mas

internas.

Proteccin: Localizar las caractersticas de proteccin criticas en un pequeo numero

de componentes.

Disponibilidad: Incluir componentes redundantes y mecanismos de tolerancia a

fallos.

Mantenibilidad: Usar componentes de grano fino mas fcilmente sustituibles.

Pero pueden aparecer conflictos:

-Rendimiento vs mantenibilidad: Usar componentes grandes mejora el rendimiento

pero reduce mas difcil la seguridad.

-Disponibilidad vs seguridad: Introducir datos redundantes mejora la disponibilidad

pero hace mas difcil la seguridad-

-Proteccin vs rendimiento: Localizar las caractersticas de proteccin en diversos

componentes suele significar mas comunicacin y por tanto, un rendimiento peor.

Se suele expresar mediante un diagrama de bloque que resume la estructura del sistema.

EJEMPLO: La arquitectura del sistema de un robot donde el primer componente en

procesar datos es el visor ptico que manda la imagen a un reconocedor de objetos, utiliza

su brazo mecnico para tomar el objeto y llevarlo al rea de empaquetado y despus llevarlo

a rea de envos.
 ESTILOS ARQUITECTURALES

Principales estilos arquitecturales:

-Estructura general: Capas, tuberas y filtros, repositorio compartido

-Sistemas distribuidos: Cliente- servidor , tres capas, brker.

Sistemas interactivos: MVC( MODELO-VISTA-CONTROLADOR), PAC

(PRESENTACION-ABSTRACION- CONTROL)

Sistemas adaptables: Micro- nucle, reflexin

Otros: Batch (lotes), interpretes, control de procesos, basado en reglas

CAPAS (MAQUINA ABSTRACTA)

Organiza el sistema en un conjunto de capas, cada una de las cuales provee una serie de

servicios a las capas superiores usando los de las capas anteriores.

SISTEMA OPERATIVO > SISTEMA DE BASE DE DATOS > SISTEMA DE

GESTIN DE OBJETOS > SISTEMA DE GESTIN DE LA CONFIGURACIN

DEL SOFTWARE.
 REPOSITORIO COMPARTIDO

Los datos comunes a los subsistemas se almacenan en una base de datos central o

repositorio.

Se emplea cuando se comparten muchos datos.

-VENTAJAS:

o Eficiente para compartir grandes cantidades de datos.

o los subsistemas no necesitan "preocuparse" de la gestin de los datos.

o Existe un modelo de datos compartido ( esquema de repositorio).

-DESVENTAJAS:

o Todos los subsistemas deben usar el mismo modelo de datos.

o La evolucin de datos es difcil y costosa.

o No cabe polticas de gestin de datos especficos.

o Es difcil hacer una distribucin eficiente.

 CLIENTE SERVIDOR

La comunicacin cliente servido utiliza un sistema distribuido donde un cliente o

usuario entre a la plataforma o interfaz y este solicita un servicio el cual la pagina procesa y

enva hacia el cliente que lo a pedido.

VENTAJAS

o La distribucin de datos es mas real y directa ;

o Se hace uso eficaz de sistemas en red. El hardware para ello puede ser barato;

o Es fcil aadir nuevos servidores o actualizar los existentes.

DESVENTAJAS

o Los subsistemas usan diferentes modelos de datos. Esto puede hacer ineficiente el

intercambio de datos;

o Gestin redundante en cada servidor;

o Nos existe un registro central de nombres y servicios. Puede ser difcil averiguar que

servidores y servicios estn disponibles

 SISTEMAS INTERACTIVOS

En estos sistemas se encuentra el de tipo MVC (modelo-vista-controlador) y el PAC

(presentacin-abstraccin-control) los cuales el usuario es el primer elemento en introducir

informacin o ejecutar un proceso mediante la vista o presentacin la cual manda las acciones

al controlador o control y esta intercambia datos con el modelos para llamar a otros mtodos

y as sucesivamente hasta guardar en la base de datos toda la informacin introducida si as

es necesario.

MVC: Modelovistacontrolador (MVC) es un patrn de arquitectura de software, que

separa los datos y la lgica de negocio de una aplicacin de la interfaz de usuario y el
mdulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone
la construccin de tres componentes distintos que son el modelo, la vista y el controlador,
es decir, por un lado define componentes para la representacin de la informacin, y por
otro lado para la interaccin del usuario.12 Este patrn de arquitectura de software se basa
en las ideas de reutilizacin de cdigo y la separacin de conceptos, caractersticas que
buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento
 CONCLUSIN

Para poder realizar un software, valindome la redundancia, usando la Ing. De Software, es

sumamente importante conocer todos los conceptos, principios, todas las bases. Saber qu es

lo que realmente se est haciendo. En lugar de solo presionar botones y escribir lneas de

cdigo y que en un abrir y cerrar de ojos el programa est listo [a menos que nos

consideremos (o seamos) semi-dioses de la programacin,] es necesario tener un

conocimiento de las herramientas a nuestro favor, para as poder determinar cuando, porqu

y cmo utilizar cada una de estas herramientas para llegar al fin que previamente hemos

planeado.
 FUENTE BIBLIOGRAFICA

o IEEE Computer Society (2004) SWEBOK - Guide to the Software

Engineering Body of Knowledge, 2004 Version.

o INGENIERIA DEL SOFTWARE, IAN SOMMERVILLE , 2005, Editorial:

ADDISON-WESLEY