4.3 Diseño de sistema

Durante el diseño de objetos, se ha desarrollado un diseño
detallado con base en la arquitectura especificada. En
general, el diseño de sistemas incluye aspectos como los
siguientes:
•Selección del lenguaje de programación a utilizarse
•Incorporación de bibliotecas (para interfaces gráficas,
estructuras de datos, etc.)
•Incorporación de una base de datos
•Incorporación de archivos en sus diferentes formatos
•Consideraciones de procesamiento,  como concurrencia,
paralelismo, distribución y tiempo real
Estos aspectos pueden variar entre un sistema y otro.
Además, pueden afectar de manera importante la
arquitectura final del sistema.
Existen diferentes enfoques para la incorporación del
ambiente de implementación a la arquitectura del sistema:
•Agregar clases abstractas o interfaces que luego se 
especializarán según el ambiente de implementación
•Instanciar objetos especializados para la administración del
ambiente de implementación
•Configurar múltiples versiones del sistema
correspondientes a diferentes plataformas.
4.3 Diseño de sistema - Lenguajes de programación
Es importante señalar que un diseño orientado a objetos no
necesariamente se tiene que implementar mediante un
lenguaje orientado a objetos. Sin embargo, es más natural
hacerlo de esta manera. Esto es debido a que los lenguajes
orientados a objetos tienen un apoyo directo a los conceptos
del análisis orientado a objetos (encapsulamiento,
generalización, polimorfismo).
Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su conveniencia, mantenimiento y protección contra errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y extensión de los programas sea más fácil y segura.
Cabe mencionar que no todos los lenguajes de programación orientados a objetos implementan de la misma forma los conceptos de la metodología orientada a objetos.  Aspectos como manejo de encapsulamiento, referencias, herencia múltiple varían de manera importante entre los lenguajes de programación.
4.3 Diseño de sistema – Interfaces gráficas
Las interfaces gráficas tienen como objetivo principal administrar la interacción entre el usuario mediante elementos gráficos, como son botones, menús y textos. Las aplicaciones interactivas donde el control del ratón y teclado desempeñan un papel importante se conocen como sistemas controlados o dirigidos por eventos. Estos eventos comprenden: mover el ratón, oprimir uno de sus botones, oprimir una tecla, etc.
Desarrollar un sistema dirigido por eventos significa que la aplicación desde un inicio debe considerar un diseño adecuado. Por ejemplo, en Java se escoge alguna de las bibliotecas gráficas (AWT o Swing) para utilizar el manejo apropiado de interfaces mediante sus clases (JFrame, Jpanel, JButton). Más allá de estas bibliotecas o clases también se afecta la lógica del diseño, ya que se debe contemplar el momento de procesar eventos.
Por ejemplo, si se desarrolla un sistema con varias pantallas se puede manejar cada evento mediante una clase para cada pantalla. Otra solución es usar un JFrame para todas las pantallas y declarar una clase que maneje los eventos del JFrame. En el segundo caso, en lugar de que cada pantalla reciba un evento del usuario, se hace que los eventos sean recibidos por parte de la clase y las pantallas se vuelven más pasivas y fáciles de manipular.

4.3 Diseño de sistema – Bases de datos
Las bases de datos son fundamentales en los sistemas de
información. Una decisión estratégica importante en tal
contexto es si debe utilizar bases de datos relacionales u
orientadas a objetos.
En general se consideran tres
modelos de bases de datos principales:
•Modelo relacional: se define una colección de tablas
donde cada una tiene un número específico de columnas y
un número arbitrario de filas. Cada objeto se representa
como una fila en una tabla y donde cada columna
corresponde a un atributo distinto en el objeto.
•Modelo relacional extendido: el modelo relacional se
extiende mediante procedimientos, objetos, versiones y otras
nuevas capacidades. No hay un solo modelo relacional
extendido, más bien hay una variedad de ellos, aunque
todos comparten las tablas y consultas básicas del modelo
relacional.
•Modelo orientado a objetos: se define un modelo
orientado a objetos donde varía el tipo de encapsulamiento
de datos y los procedimientos en el objeto. El término
orientado a objetos varía según cada autor
Las bases de datos son depósitos de datos guardados en
uno o más archivos. Existen sistemas de manejo de bases
de datos (DBMS) y orientados a objetos (OOBDMS).
Las bases de datos dan apoyo en los siguientes aspectos:
•Múltiples usuarios
•Múltiples aplicaciones
•Seguridad
•Integridad
Distribución de datos
La tarea del diseño se simplifica, creando una tabla
correspondiente a cada clase entidad del dominio del
problema y manteniendo las asociaciones entre clases.
Obviamente el diseño de tablas puede optimizarse para un
acceso más eficiente.
4.3 Diseño de sistema – Archivos
Aunque es más efectivo trabajar con bases de datos, es
posible utilizar archivos, sobre todo cuando la especificación
del sistema así lo requiera. En el caso de usar una base de
datos, regularmente una clase se comunica con el DBMS
para hacer solicitudes a cualquier tabla. Sin embargo, en el
caso de los archivos, tal manejador no existe por lo que el
proceso se hace manualmente.

Unidad 4

4.1 Estrategias de diseño:

     A través de la historia de la ingeniería de software ha evolucionado un conjunto de conceptos fundamentales de diseño de software. Cada uno ofrece al ingeniero de software un fundamento sobre el cual pueden aplicarse métodos de diseño más elaborados. Los conceptos fundamentales del diseño de software ofrecen el marco de trabajo necesario para hacer las cosas del “modo correcto”.
4.1 Estrategias de diseño – Abstracción
Para un problema determinado se pueden considerar
muchos grados de abstracción. En un alto grado de
abstracción una solución se establece en términos
generales con el lenguaje de entorno del problema. En los
grados de menor abstracción se proporciona una solución
más detallada de la solución. Una abstracción procedimental
se refiere a una secuencia de instrucciones que tiene una
función específica y limitada.
Una abstracción de datos es una colección nombrada de
datos que describe un objeto de datos.  Por ejemplo, se
puede decir que la abstracción procedimental abrir
emplearía la información contenida en los atributos de la
abstracción de datos puerta.
4.1 Estrategias de diseño – Arquitectura
La arquitectura del software alude a la estructura general del
software y las formas en las que la estructura proporciona
una integridad conceptual para un sistema. La arquitectura
es la estructura u organización de los componentes del
programa (módulos), la manera en que estos componentes
interactúan, y la estructura de datos que utilizan los
componentes.
4.1 Estrategias de diseño – Patrones
Un patrón de diseño describe una estructura de diseño que
resuelve un problema recurrente de diseño particular dentro
de un contexto específico y en medio de fuerzas que
pueden tener un impacto en la manera en que se aplica y
utiliza el patrón.
4.1 Estrategias de diseño – Modularidad
Los patrones de arquitectura y diseño de software
materializan la modularidad; es decir, el software se divide
en componentes con nombres independientes y que es
posible abordar en forma individual. Estos componentes
llamados módulos se integran para satisfacer los requisitos
del problema. La modularidad se basa en la estrategia divide
y vencerás (es más fácil resolver un problema complejo
cuando éste se divide en piezas más manejables).
4.1 Estrategias de diseño – Ocultación de información
El principio de ocultación de información sugiere que los
módulos se caracterizan por las decisiones de diseño que
cada uno oculta a los otros. Los módulos deben
especificarse y diseñarse de manera que la información
(procedimientos y datos) que está dentro del módulo sea
inaccesible para otros módulos que no necesiten esta
información.
4.1 Estrategias de diseño – Independencia funcional
Es la suma de directa de la modularidad y de los conceptos
de abstracción y ocultación de información. La
independencia funcional se consigue al desarrollar módulos
con una función determinante y una aversión a la interacción
excesiva con otros módulos. Los módulos independientes
son más fáciles de mantener, probar, modificar y se reduce
la propagación de errores.
4.1 Estrategias de diseño – Refinamiento
El refinamiento es una estrategia de diseño descendente. El
desarrollo de un programa se realiza al refinar de manera
sucesiva los niveles de detalle procedimentales.  El
refinamiento hace que el diseñador trabaje sobre el
enunciado original y que proporcione más y más detalles
conforme se realiza cada refinamiento sucesivo. La
abstracción y el refinamiento son conceptos
complementarios.
4.1 Estrategias de diseño
La meta del diseño es crear un
modelo de software que
implemente todos los requisitos
del cliente de manera correcta y
complazca a aquéllos que lo
usen. El proceso de diseño
avanza de una visión general del
software a una visión más
estrecha que define el detalle
requerido para implementar un
sistema.
El proceso de diseño comienza con
un enfoque en la arquitectura. Se
definen los subsistemas, se
establecen mecanismos de
comunicación entre los subsistemas;
se identifican los componentes y se
realiza una descripción detallada de
cada componente. Además, se
diseñan las interfaces internas,
externas y del usuario.
4.2 Diseño de objetos
Un sistema orientado a objetos está
compuesto de objetos que
interactúan, los cuales mantienen
ellos mismos su estado local y
proveen operaciones sobre su
estado. La representación del estado
es privada y no se puede acceder a
ella directamente desde fuera del
objeto. El proceso de diseño de
objetos comprende el diseño de
clases de objetos y las relaciones
entre estas clases. El diseño
orientado a objetos comprende el
desarrollo de un modelo orientado a
objetos de un sistema de software
para implementar los requerimientos
identificados. Los objetos en un
diseño orientado a objetos están
relacionados con el problema a
resolver.
Un proceso general para el diseño
orientado a objetos puede contener las
siguientes etapas:
•Comprender y definir el contexto y los
modos de utilización del sistema
•Diseñar la arquitectura del sistema
•Identificar los objetos principales del
sistema
•Desarrollar los modelos de diseño
•Especificar las interfaces de los objetos
Todas estas actividades se pueden ver
como actividades entrelazadas que
influyen entre sí. Los objetos se
identifican y las interfaces se
especifican completa o parcialmente en
el momento de definir la arquitectura del
sistema.

TEMAS DE 4 PARCIAL:
Unidad 4
Modelo de diseño

4.1 Estrategias de diseño(Abstracción,
Arquitectura, Patrones, Modularidad,
Ocultación de información,
Independencia funcional y
Refinamiento)
4.2 Diseño de objetos
4.3 Diseño de sistema
(Lenguajes de programación, Interfaces
gráficas,
Bases de datos y Archivos)
4.4 Multiplexacion por division en
codigo o CDM (Code division
multiplexing)
Unidad 6:
Dispositivos de
comunicación
6.1 Características funcionales
6.2 Interfaces