3.1
DESCOMPOSICIÓN MODULAR.
Descomposición Modular o Modularización es el proceso de descomposición de un sistema en un conjunto de elementos con un índice bajo acoplamiento (independientes) y alto índice de cohesión (con significado propio).
Consiste en descomponer el problema a resolver en módulos
o tareas más simples. Cada tarea representa una actividad completa y se
codifica de manera independiente. Facilita el diseño descendente del problema, centrándonos cada vez en la
resolución de subproblemas de magnitud inferior.
A la resolución de cada uno de
estos subproblemas de complejidad inferior se denomina refinamiento por pasos. Los módulos pueden ser planificados,
codificados, comprobados y depurados independientemente, y a continuación se
combinan uno a uno con otros módulos.
Con este concepto se hace referencia a la necesidad de
separar el propósito de un subprograma de suimplementación.
- Cada
algoritmo que resuelve el diseño de un módulo equivale a una caja negra
que ejecuta una tarea determinada.
- Cada
caja negra especifica lo que hace pero no cómo lo hace.
- Cada
caja negra puede utilizar a cualquiera de las demás cajas negras.
Normalmente, estas cajas negras se implementan como subprogramas: procedimientos y funciones.
Abstracción de datos.
Pretende separar el concepto de datos y operaciones
necesarias para operar con los datos, de su representación e implementación
respectivamente. La materialización de este concepto son los Tipos de Datos Abstractos (TDA)
que se definen como una colección de datos y un conjunto de operaciones sobre
estos datos.
Ocultamiento de información.
Facilitará las diversas abstracciones, ocultando y
evitando que se pueda acceder a la representación e implementación de los
módulos y TDA. Se consigue haciendo uso de facilidades aportadas por el
lenguaje de programación.
Programación orientada a objetos
Paradigma de programación que hace uso de todos conceptos
anteriores y algunos más para el desarrollode software.
Descomposición modular mediante diseño descendente.
Cuando crece un programa las tareas de programación se
hacen más difíciles. La diferencia entre un programa modular grande y pequeño
influye solamente en el número de módulos.
Construcción del programa. Pueden trabajar
diversos desarrolladores gracias a la independencia de los módulos.
Depuración del programa. Se centrará en
cada uno de los módulos por separado y posteriormente se comprobará la
interacción.
Legibilidad del código.
Eliminación
de código redundante.
Ideas fundamentales.
Reducir
el esfuerzo de desarrollo.
Separación
entre estructuras de datos y procedimientos.
Independencia
funcional: Cada módulo debe realizar una tarea concreta que afecte
lo menor posible al resto.
Ocultamiento
de Información: La información de un módulo es inaccesible para el
resto de módulos.
§
Evita la propagación de errores
§
Facilita las interfaces e independiza la codificación
§
Acoplamiento: Grado de interdependencia de los módulos
§
Cohesión: Grado del alcance de la tarea de un
módulo
v
Reducir acoplamiento
v
Aumentar la cohesión
v
Conseguir módulos con interfaces sencillas
Idea principal: Definir
una parte de un sistema de modo que puede ser comprendido por si mismo, como
una unidad, sin conocimiento de sus detalles específicos. Solo será necesario
saber el modo de interaccionar con dicha unidad.
Dos tipos:
• Abstracción procedimental
Los módulos se ven como cajas negras con una determinada
funcionalidad que a su vez pueden hacer uso de otras cajas negras.
• Abstracción de datos
Los datos son vistos como elementos sobre los que se
pueden realizar un conjunto de operaciones predefinidas. En ningún momento se
tiene conocimiento de su representación o implementación de las operaciones.
Modificabilidad
Una buena descomposición modular facilitará la modificabilidad
del código. Pequeños cambios en los requisitos de un programa modular
normalmente requieren un cambio pequeño sólo en algunos de sus módulos.
Vendrá condicionado por los siguientes aspectos:
– Acoplamiento
débil. Los módulos deben ser independientes entre sí.
– Cohesión
fuerte. Las tareas de cada módulo deben estar bien definidas.
3.2 PATRÓN DE DISEÑO
Los patrones de diseño son la base para la búsqueda de soluciones a
problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de
interacción o interfaces.
Un patrón de diseño resulta
ser una solución a un problema de diseño. Para que una solución sea considerada
un patrón debe poseer ciertas características. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas similares en ocasiones
anteriores. Otra es que debe ser reutilizable, lo que significa que es
aplicable a diferentes problemas de diseño en distintas circunstancias.
Objetivos de los patrones
Los patrones de diseño
pretenden:
Ø
Proporcionar catálogos de
elementos reusables en el diseño de sistemas software.
Ø
Evitar la reiteración en la
búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
Ø
Formalizar un vocabulario
común entre diseñadores.
Ø
Estandarizar el modo en que se
realiza el diseño.
Ø
Facilitar el aprendizaje de
las nuevas generaciones de diseñadores condensando conocimiento ya existente.
Asimismo, no pretenden:
- Imponer ciertas alternativas de diseño frente
a otras.
- Eliminar la creatividad inherente al proceso
de diseño.
No es obligatorio utilizar los
patrones, solo es aconsejable en el caso de tener el mismo problema o similar
que soluciona el patrón, siempre teniendo en cuenta que en un caso particular
puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser
un error".
Categorías
de patrones
Según la escala o nivel de
abstracción:
Patrones de arquitectura: Aquellos que expresan un esquema organizativo
estructural fundamental para sistemas de software.
Patrones de diseño: Aquellos que expresan esquemas para definir
estructuras de diseño (o sus relaciones) con las que construir sistemas de
software.
Dialectos: Patrones de bajo nivel específicos para un
lenguaje de programación o entorno concreto.
Además, también es importante
reseñar el concepto de "antipatrón de
diseño", que con forma semejante a la de un patrón, intenta
prevenir contra errores comunes de diseño en el software. La idea de los
antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy
frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez
en el mismo callejón sin salida por haber cometido los mismos errores.
Además de los patrones ya
vistos actualmente existen otros patrones como el siguiente:
- Interacción: Son patrones que nos permiten el diseño de interfaces web.
Estructuras
o plantillas de patrones
Para describir un patrón se
usan plantillas más o menos estandarizadas, de forma que se expresen
uniformemente y puedan constituir efectivamente un medio de comunicación
uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto
plantillas ligeramente distintas, si bien la mayoría definen los mismos
conceptos básicos.
La plantilla más común es la
utilizada precisamente por el GoF y consta de los siguientes apartados:
Nombre del patrón: nombre estándar del patrón por el cual será
reconocido en la comunidad (normalmente se expresan en inglés).
Clasificación del patrón: creacional, estructural o de comportamiento.
Intención: ¿Qué problema pretende resolver el patrón?
También conocido como: Otros nombres de uso común para el patrón.
Motivación: Escenario de ejemplo para la aplicación del
patrón.
Aplicabilidad: Usos comunes y criterios de aplicabilidad del
patrón.
Estructura: Diagramas de clases oportunos para describir las
clases que intervienen en el patrón.
Participantes: Enumeración y descripción de las entidades
abstractas (y sus roles) que participan en el patrón.
Colaboraciones: Explicación de las interrelaciones que se dan
entre los participantes.
Consecuencias: Consecuencias positivas y negativas en el diseño
derivadas de la aplicación del patrón.
Implementación: Técnicas o comentarios oportunos de cara a la
implementación del patrón.
Código de ejemplo: Código fuente ejemplo de implementación del
patrón.
Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
Patrones relacionados: Referencias cruzadas con otros patrones.
3.3 ARQUITECTURAS DE DOMINIO ESPECÍFICO (DSSA).
Pasos para su construcción:
1. Definición del dominio.
2. Definición de requisitos y conceptos del dominio
específico.
3. Definición de restricciones de implementación del
dominio.
4. Desarrollo de modelos y arquitecturas del dominio.
5.
Generación de productos reutilizables.
Arquitecturas de Software Reutilizables
El objetivo principal es poder reutilizar partes de una
arquitectura, modelos arquitectónicos, arquitecturas de referencia o
componentes de la misma de manera que no sea necesario volver a diseñar el
modelo completo. Utilizan componentes reutilizables y se obtienen,
generalmente, mediante procesos de Ingeniería del Dominio. De esta forma es
posible obtener un ahorro de costes y tiempo en la creación de nuevos sistemas
de software.
Un sistema
multiproceso o multitarea es aquel que permite ejecutar varios procesos de
forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo
pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma
simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en
varias, en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional.
La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional.
Un conjunto de tareas puede ser completado más
rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. Esa es
la teoría, pero otra historia es la práctica, como hacer funcionar el
multiproceso, lo que requiere unos profundos conocimientos tanto del hardware
como del software.
Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.
Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.
3.5 ARQUITECTURAS CLIENTE SERVIDOR.
Se denomina
cliente al proceso que inicia el diálogo o solicita los recursos y servidor al
proceso que responde a las solicitudes.
En este modelo las aplicaciones se dividen de forma que el servidor contiene
la parte que debe ser compartida por varios usuarios, y en el cliente permanece
sólo lo particular de cada usuario.Los clientes realizan generalmente funciones
como:
• Manejo de la interfaz de usuario.
• Captura y validación de los datos de entrada.
• Generación de consultas e informes sobre las bases de datos.
• Por su parte los servidores realizan, entre otras, las siguientes
funciones:
• Gestión de periféricos compartidos.
• Control de accesos concurrentes a bases de datos compartidas.
• Enlaces de comunicaciones con otras redes de área local o extensa.
Entre las principales características de la arquitectura cliente/servidor
se pueden destacar las siguientes:
• El servidor presenta a todos sus clientes una interfaz única y bien definida.
• El cliente no necesita conocer la lógica del servidor, sólo su interfaz
externa.
• El cliente no depende de la ubicación física del servidor, ni del tipo de
equipo físico en el que se encuentra, ni de su sistema operativo.
• Los cambios en el servidor implican pocos o ningún cambio en el cliente
3.6
DISEÑO DE SOFTWARE DISTRIBUIDO
Sistemas cuyos componentes hardware y software, que están en ordenadores conectados en red, se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un objetivo.
Se establece la comunicación mediante
un protocolo prefijado por un esquema cliente-servidor.
Características:
• Concurrencia.- Esta característica
de los sistemas distribuidos permite que los recursosdisponibles en la red
puedan ser utilizados simultáneamente por los usuarios y/o agentes que
interactúan en la red.
• Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realización de una tarea, no tienen una temporización general, esta más bien distribuida a los componentes.
• Fallos independientes de los
componentes.- Cada componente del sistemapuede fallar independientemente, con
lo cual los demás pueden continuar ejecutando sus acciones. Esto permite el
logro de las tareas con mayor efectividad, pues el sistema en su conjunto
continua trabajando.
Procesamiento central (Host).- Uno de
los primeros modelos de ordenadores interconectados, llamados centralizados,
donde todo el procesamiento de la organización se llevaba a cabo en una sola
computadora, normalmente un Mainframe, y los usuarios empleaban sencillos
ordenadores personales.
Los problemas de este modelo son:
• Cuando la carga de procesamiento
aumentaba se tenía que cambiar el hardware del Mainframe, lo cual es más
costoso que añadir más computadores personales clientes o servidores que
aumenten las capacidades.
• El otro problema que surgió son las modernas interfases gráficas de usuario, las cuales podían conllevar a un gran aumento de tráfico en los medios de comunicación y por consiguiente podían colapsar.
El software de tiempo real esta muy
acoplado con el mundo externo, esto es, el software de tiempo real debe
responder al ámbito del problema en un tiempo dictado por el ámbito del
problema. Debido a que el software de tiempo real debe operar bajo
restricciones de rendimiento muy rigurosas, el diseño del software esta
conducido frecuentemente, tanto por la arquitectura del hardware como por la
del software, por las características del sistema operativo, por los requisitos
de la aplicación y tanto por los extras del lenguaje de programación como
prospectos de diseño.
La computadora digital se ha
convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las
computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el
gasto de gasolina de nuestras ultimas generaciones de coches y programar a
nuestros aparatos.
Todas estas interacciones con las
computadoras sean útiles o intrusivas son ejemplos de computación de tiempo
real. La computadora esta controlando algo que interactua con la realidad sobre
una base de tiempo de hecho, el tiempo es la esencia de la interacción.
Los sistemas de tiempo real generan
alguna acción en respuesta a sucesos externos. Para realizar esta función,
ejecutan una adquisición y control de datos a alta velocidad bajo varias
ligaduras de tiempo y fiabilidad.
Debido a que estas ligaduras son muy
rigurosas, los sistemas de tiempo real están frecuentemente dedicados a una
única aplicación.
muy buen aporte sobre la unidad 3 de ing de software te mereces un 10 jejej bb
ResponderEliminarhoola,pues esta mas claro que nada,muy buena informacion,muy bien detallada,excelente trabajo
ResponderEliminarGRAXIAS COMPAÑERO ==========APORTASTE EXELENTE INFORMACION
ResponderEliminarbuena informacion con esto nos damos cuenta que las arquitecturas de sofware son de suma importancia
ResponderEliminarHola a todos, en mi opinion creo que en la parte teórica estamos bien, lo que hace falta es ver mas a fondo los temas, por que tan solo mencionar el tema de "sistemas operativos" entran otros subtemas como procesos, hilos, llamadas al sistema y en eso entra la programación...ok.buena información pero hay que seguir checando los temas, va que va...saludos...
ResponderEliminar