Ingesoft 2

27-03-2019

1.Qué es diseño?
Específicamente hablamos de DISEÑO DE INGENIERÍA.
La definición rigurosa de este diseño la tiene la teoría general de sistemas.
La tgs define 5 aspectos de un sistema:
-Variables y su nivel de resolución
-Actividad en el tiempo
-Comportamiento
-Estructuras y acoplamientos
-Estados y transiciones

1.Problema de análisis

Se da:
Un sistema cuya estructura es accesible al investigador.

Se pide:
Describir los 5 aspectos del sistema.

Si se entrega el mismo problema de análisis a varios investigadores, ¿Cómo serán sus

resultados?

Aunque los resultados no sean iguales, se espera que sean equivalentes.

2.El.problema de la síntesis (Diseño)

Se da:
- 4 aspectos de un sistema
Variables y nivel de resolución
Actividad en el tiempo
Comportamiento
Estados y transiciones
En su conjunto, estos 4 aspectos se pueden llamar los requerimientos.
- Un conjunto de tipos de elementos con los cuales se puede construir el sistema. En
su conjunto, los podemos llamar los recursos.

Se pide:
La estructura del sistema solución, la cual debe cumplir los 4 aspectos dados y estar
construida solamente con los tipos de elementos dados.

Si se entrega el mismo problema de síntesis a diferentes investigadores, ¿Cómo serán sus

resultados?

Pueden dar diferentes resultados.

Entra en juego la imaginación y creatividad humana.

¿Con qué criterio seleccionamos el mejor resultado?

Los criterios son los requerimientos no funcionales o también llamados atributos de calidad.
El resultado debe cumplir de la mejor manera estos requerimientos.

3.Problema de la caja negra

Se da:
Un sistema del cual no se tiene acceso a su estructura.

Se pide:
Describir los 5 aspectos del sistema.

El problema de la caja negra se resuelve por experimentación.

Un experimento consiste en manipular las variables de ambiente y observar qué pasa con
las variables del sistema.
Luego se hacen conjeturas, suposiciones e hipótesis.
En ingeniería del software este problema es usado para diseñar pruebas del software.

Conceptos Fundamentales Del Diseño

Metas de la ingeniería de software:
● Bajo costo de desarrollo
● Bajo costo de mantenimiento
● Reutilización del software

Modularidad
Libro : El discurso del método
Autor :. Renato descartes
“Divide y vencerás”

Al aplicar este método no debemos olvidar registrar todas las interconexiones entre las
diferentes partes del problema.
Aplicado a la ingeniería del software ,este concepto nos lleva a dividir el sistema de software
solución en partes. Como las partes son complejas , se aplica varias veces la división ,
obviamente teniendo un mapa de los acoplamientos entre partes.

Concretamente:
A) El sistema se divide en subsistemas.
B) El subsistema se divide en comportamientos.
C) El componente se divide en clases
Taxonomía del software
 D) Si un componente es muy complejo se puede dividir en más componentes.
La clase es el “ladrillo” con el cual se construye todo el sistema
Abstracción
Según la Wikipedia “capacidad de observar una propiedad aislandola de las demás”.
“Capacidad de ver la totalidad sin tener en cuenta detalles superfluos”
Para la ingeniería de software
“Abstracción es la capacidad de ver el sistema con diferentes niveles de detalle”.

Podemos hablar entonces de niveles de abstracción:

Alto nivel de abstracción
Ver el sistema como un todo
Bajo nivel de abstracción
Ver los detalles finos como las clases y métodos

Aplicando este concepto al diseño , obtenemos varios niveles de diseño:

1. Diseño arquitectónico
Consiste en modelar el sistema como un todo (modelo ambiental) y dividir el sistema
en subsistemas.
2. Diseño de componentes
Consiste en estudiar cada subsistema por separado y dividirlo en componentes.
3. Diseño detallado
Consiste en tomar casa componente por separado y dividirlo en más componentes o
en clases

El sistema operativo podría considerarse un subsistema.

La Base de datos se puede considerar otro subsistema.
El navegador web se puede considerar como un componente de la aplicación.
El servidor web se podría considerar un subsistema.
El sistema operativo, la base de datos , navegador y el servidor web son elementos que no
tenemos que desarrollar sino que los reutilizamos; sin embargo estos elementos forman
parte de la aplicación .
Es importante anotar que la versión importa para los elementos mencionados.

Las Interfaces Hombre Máquina se pueden considerar parte del diseño de componentes o
del diseño detallado. Depende de si la ventana se define como una clase o como un
componente.

Acoplamiento
Es una medida de que tanto depende un elemento de los demás , qué tan independientes
son los elementos de un sistema y como los elementos del sistema están interconectados .
Puede haber acoplamiento a todos los niveles (sistema , subsistema , componente, clase) .

Acoplamientos entre clases:

● Notación:

A depende de B
B domina a A

¿En qué forma se pueden acoplar dos clases?

1. B es la superclase de A
A es una subclase de B

En esta relación de generalización A hereda todas las características de B.

Cualquier cambio que se haga a B es heredado por A.

2. A tiene un atributo de tipo B

Los cambios en B modifican el atributo de A

3. A tiene un método que retorna un objeto de
Tipo B.
4. A tiene un método que tiene una variable local
de tipo B.
5. A tiene un método que tiene una variable local de tipo B
6. B es un virus que ha infectado a A
Si una clase tiene demasiadas dependencias , constantemente beata clase se va a ver
afectada por cambios que se ocurren en otras partes del sistema. Cada acoplamiento es
más trabajo para el ingeniero de mantenimiento .por este lado podrían ser responsables del
alto costo de mantenimiento
Un sistema con pocos acoplamientos es más barato de mantener que un sistema con
mucho más acoplamientos.

01-04-2019

Problemas de tener mucho acoplamiento.}

❏ El sistema es difícil de mantener
❏ Es difícil de entender
❏ Es difícil de reutilizar
❏ La clase que depende de muchas otras es delicada, se ve afectada constantemente
por los cambios.

El acoplamiento es un fenómeno que tiene que existir.

Un sistema orientado a objetos es aquel donde todos los objetos colaboran para lograr los
objetivos del sistema.
El acoplamiento representa esta colaboración.

Meta para el diseño:

Tener el acoplamiento tan bajo como sea posible pero sin eliminarlo para aprovechar sus
beneficios

4. Cohesión

Es una medida de que tan relacionados están las partes internas del sistema
Para una CLASE la cohesión permite preguntar qué tan relacionadas están los métodos de
esa clase?
Los métodos realizan tareas diferenciales?
O todos colaboran para realizar una sola tarea?

Cohesión Funcional
Se da cuando todos los métodos de una clase colaboran para una sola tarea.Si los metodos
de una clase se dispersan entre varias tareas,diremos que esta clase tiene BAJA
COHESIÓN

Problemas de una clase con baja cohesión:

- Es difícil de entender por qué realiza varias tareas
- Es difícil de reutilizar ,por que se necesita encontrar otro proyecto donde se requiera
la misma combinación de tareas de la clase.
Es costosa de mantener:
- Por lo difícil de entender
- Las diferentes tareas se acoplan por medio de la clase. Un cambio para arreglar
una de las tareas podía tener efectos adversos en otra tarea.
La meta del diseño:
Tener clases con cohesión funcional,es decir, cohesión tan alta como sea posible.

5.Ocultamiento de información:

Tema relacionado con la seguridad de los datos.

Para que TERCERAS PERSONAS tengan acceso a los datos no les permitiremos acceso
directo, debemos construir una API (Interfaz de programa de Aplicación)
Un conjunto de funciones que los terceros pueden acceder.Estas funciones deben cumplir
las reglas del negocio.

Aplicando estas ideas a una clase,todos los atributos de la clase seran declarados como
PRIVADOS.Se podra tener acceso a los atributos por medio de los métodos que
constituyen la API de la clase.Esta se denomina ENCAPSULAMIENTO.

Aplicando la idea de ocultamiento de la información a todo el sistema,existen patrones de

diseño que ocultan la información y hacen cumplir las reglas del negocio como el patrón de
diseño MODELO-VISTA-CONTROLADOR o MVC:

-La interfaz de usuario para capturar y mostrar los datos, se denomina la VISTA
- El procesamiento de los datos, entre los cuales está la validación de los datos,se
denomina el CONTROLADOR.
- El almacenamiento de los datos se denomina MODELO que se refiere al modelo de datos.

El patrón MVC sugiere que estos tres procesos o subsistemas se realicen en máquinas
distintas, para garantizar la seguridad de los datos y evitar accesos no autorizados.

Aunque no usemos el MVC, nuestro diseño debe garantizar el ocultamiento de la

información.
A causa del MVC, los objetos del sistema se clasifican en tres estereotipos:
6. Separación de temas:

Los elementos taxonómicos del sistema de software (claves, componentes,subsistemas)

deben mantener separados los temas del problema.
Este concepto tiene gran aplicación en los diferentes diseños que veremos.

DISEÑO ARQUITECTÓNICO

Estudia la estructura gruesa del sistema, es decir como el sistema que se divide en
SUBSISTEMAS

Foto

Pero en realidad al iniciar el proyecto, lo primero que se revisa es la arquitectura :

EJEMPLO:
El problema:
Controlar un sistema robótico encargado de empacar productos.

Funcionamiento :
1. El producto a empacar esta en la cinta de entrada.Se enciende esta cinta para
acercar el producto al brazo robótico
2. La cámara toma vistas del producto. Se debe determinar el tipo de empaque
necesario para el producto
3. El brazo robótico toma el empaque adecuado y lo coloca en la estación de empaque
4. El brazo robótico transporta el producto y lo deposita dentro del empaque
5. La estación de empaque termina el empacado del producto
6. El brazo robótico toma el producto empacado y lo deposita en la cinta de salida
7. Se enciende el motor de la cinta de salida para que se lleve el producto empacado

Se solicita:
Un software empotrado que controle todas las partes eléctricas y mecánicas del sistemas,
interprete las imágenes de la cámara y pueda realizar el proceso de empaque como se
describe

03/04/2019
El diseño arquitectónico se puede visualizar con dos niveles de abstracción:

Arquitectura en pequeño (ING del software):

Modela las partes de una aplicación y cómo se relacionan.

Arquitectura en grande (ING de sistemas):

Modela grandes sistemas empresariales de los cuales la aplicación del software es una
parte más.
Contiene la arquitectura en pequeño.
La arquitectura en grande es la principal influencia para los requerimientos no funcionales.

Ventajas de documentar la arquitectura

Bass en 2003 publica las siguientes ventajas de documentar la arquitectura:
1.Comunicación con los participantes (stakeholders)

Facilita la conversación entre ingenieros y participantes, la hace más profunda y relevante.

Los subsistemas pasan a formar parte del vocabulario de esta conversación.

2.Análisis del sistema

Al tener las partes del sistema y sus acoplamientos se hace posible analizar el cumplimiento
de algunos requerimientos no funcionales: rendimiento, confiabilidad, mantenibilidad.

3 reutilización a gran escala

Es posible que al obtener los subsistemas, podemos ver la oportunidad de reutilizar su
sistemas completos.
Como un subsistema es una pieza de software bastante grande y compleja el ahorro en
trabajo es sustancial
Suele reutilizarse:
-La base de datos
-El servidor web
-El contenido de componentes
-El navegador web
Hoffmeister (2000) dice que la documentación de la arquitectura sirve para:
-Navegación de requerimientos
Para esto la arquitectura debe conocerse antes que se hagan los requerimientos
Un medio para establecer discusiones con desarrolladores
Una herramienta para manejar la complejidad.

El lenguaje usado para documentar la arquitectura tiene influencia en:

● La cantidad de personas que van a poder entender el documento.
● La precisión o ambigüedad del documento.

Decisiones del diseño arquitectónico

Se podría hablar de diseño arquitectónico en función de la frecuencia de actividades que se

deben realizar. La historia ha demostrado que este es un enfoque sujeto a cambios
frecuentes.
Se ha encontrado que una mejor forma de hablar de este tema es con las decisiones que
debe tomar el arquitecto de software.
1. Existe alguna arquitectura de aplicación genérica que se pueda usar como una
plantilla para el sistema que se está diseñando?

Las aplicaciones de un mismo sector económico comparten los mismos componentes del
área de problemas. Por eso esas aplicaciones se parecen entre sí y es válido partir de una
arquitectura de un software similar para desarrollar nuestra arquitectura.
Es factible que existan arquitecturas genéricas para los principales sectores económicos.

Ej:
● Sistemas de información
● Sistema de procesamiento de transacciones
● Sistema de procesamiento del lenguaje.
2.¿Cómo se distribuirá el sistema a través de varios núcleos o procesadores?
algunas aplicaciones son de naturaleza monoprocesadores, cómo los sistemas embebidos
(firmware quemado dentro de un microprocesador).
Sin embargo la tendencia es hacia sistemas distribuidos.
La forma de distribución del software entre un conjunto de procesadores interconectados es
crucial para:
● El rendimiento o desempeño del sistema.
● La seguridad del sistema.
● La confiabilidad.

3.Qué patrones o estilos arquitectónicos pueden usarse?

Existen patrones arquitectónicos de diseño (organización)
● Repositorio
● Capas
● Cliente / servidor
● Tuberías y filtros
4.Cuál sería el enfoque fundamental usado para estructurar el sistema?
Patrones arquitectónicos de diseño.
El enfoque se basa en las ventajas y desventajas los patrones arquitectónicos y en los
requerimientos del sistema.

5.Cómo los componentes estructurales del sistema se dividen en subcomponentes?

¿Cómo dividimos los subsistemas en componentes?
No necesariamente usamos el patrón de diseño para dividir el sistema en subsistemas y el
subsistema en componentes.
De todas maneras usamos el patrón de diseño.

05/04/2019

6.¿Qué estrategia se usará para controlar la operación de los componentes en el sistema?

Los procesadores se organizan de dos maneras:
Multiprocesadores:
Varios procesadores conectados a una motherboard
Multicomputadoras:
Varias computadoras unidas por una red
Las estrategias de control son de dos tipos:
Centralizados: un componente central se encarga de activar/desactivar a los demás
Distribuidas:los componentes controlan a sí mismos dependiendo de un flujo de eventos
externos.

7.¿cuál organización arquitectónica es mejor para entregar los requerimientos no

funcionales del sistema?
● Rendimiento
Es una multicomputadora los mensajes de red suelen ser cuello de botella del
sistema porque las redes son lentas . En este caso la estrategia es disminuir los
mensajes de red.
Esto nos lleva a tener pocos nodos de red por lo cual cada nodo o subsistema debe
ser grande. A esto se le denomina , una estrategia de grano grueso.
 En caso de un multiprocesador , la estrategia es el multiprocesamiento paralelo,es
decir el trabajo se reparte equitativamente entre todos los procesadores.

● Seguridad(security)
Capacidad de evitar accesos no autorizados.
Para esto podemos usar una estrategia de capas.

Las capas envuelven a lo más crítico del sistema: los datos para atravesar de una
capa a otra hay algún control de seguridad.

● Protección (safety)
Estrategia de reacción ante los riesgos .casi siempre riesgos naturales o
tecnológicos.

Son estrategias para afrontar fallas:

● Falta de energía
● Fallas de sistema operativo
● Fallas de hardware

Pueden ser estrategias como:

● Manejo de transacciones
● Cookies o similares
● Estado normal desconectado/cerrado
● Estrategias de recuperación de fallas
○ Backups
○ Rewind de las transacciones

● Estrategia de diseño
 Crear nodos especializados en las actividades propias de la protección

● Disponibilidad
(Tiempo disponible)/(Tiempo que se necesite el sistema)

Meta : 100%
La disponibilidad puede disminuir del 100% por :
● Mantenimiento
● Fallas
La estrategia para obtener mayor disponibilidad es: la redundancia
● Diseños espejos
● Servidores espejos
● Redes redundantes
● Suministro eléctrico redundante

Probabilidad de falla mensual de un servidor: ⅙

Queremos que el sistema tenga una probabilidad de falla anual de : ⅕
Probabilidad de falla mensual :1/(5*12) =1/60 =Pt

Propuesta : Tener N servidores espejos independientes.

● Mantenibilidad
Hay estrategias de mantenibilidad que no tienen que ver con el diseño
● Documentación
● Nombres adecuados en el software
● Autodocumentación

¿Que puede hacer el diseño?

Podemos dividir el sistema en partes pequeñas , de tal manera que al apagar el servicio de
una pequeña parte no se afecte todo el sistema . Estrategia de grano fino.
Hay sistemas de desarrollo que permiten reemplazar una parte en caliente .
Ej: Un contenedor de componentes
 ● Separar productores de consumidores
● Evitar las estructuras de datos compartidas(memoria compartida)
Podría haber conflicto entre requerimientos no funcionales .una opción es negociar los
requerimientos con participantes .
Podemos dividir el sistema y aplicar las estrategias en conflicto en partes separadas .

08/04/2019

8. ¿Cómo se evaluará el diseño?

La verdadera evaluación se dará al contenido, el sistema verifica el si tiene o no las
características que se borraron.
Antes de construir el sistema:
- Comparar el diseño con ARQUITECTURA DE REFERENCIA.
- Los MODELOS DE CALIDAD tienen el proceso de evaluación del diseño.(Eje.
CMMI)
- EJ:
- Atributos observables:
- Disponibilidad
-Confidencialidad
-Funcionalidad
-desempeño
-Confiabilidad
-Seguridad externa
-Seguridad interna
-Atributos no observables:
-Configurabilidad
-Portabilidad
-Integrabilidad
-Modificabilidad
-Mantenibilidad
-Portabilidad
-reusabilidad
-Escalabilidad
-Capacidad de prueba

9.¿Cómo se documentará la Arquitectura?

a.Vistas

Se usa el modelo de KRUTCHEN de los (4+1 VISTAS)

- Vista lógica

Contiene las abstracciones claves del sistema(Objetos, clases,componentes, subsistemas)

Se debe relacionar los requerimientos del sistema con las abstracciones(Subsistemas,
componentes)
La relación entre requerimientos y abstracciones se puede hacer con una MATRIZ DE
CRUCE:

- Vista de procesos
Modela los procesos de sistema repetitivos que se genera el sistema
Podemos observar la cantidad de procesos y conjeturar acerca del rendimiento, también se
puede observar si hay procesos de respaldo y conjeturar sobre la disponibilidad del sistema

- Vista de desarrollo
Modela como se ha distribuido el software a desarrollar entre los diferentes desarrolladores
ya sea individuales o por grupos.Sirve a los administradores para monitorear el avance del
trabajo
Se puede tener con una matriz de cruce:

- Vista Física

Muestra los nodos de hardware en la red y como los elementos físicos(Archivos) se

distribuyen entre estos nodos. Se puede hacer con una matriz de cruce o con un “Diagrama
de deployment (Distribución)

- La vista adicional
Puede ser los escenarios o casos de uso
Todas las vistas anteriores podrían ser organizadas también por escenario
Algunos autores usan una VISTA CONCEPTUAL en la cual relaciona los requerimientos
con los conceptos del problema
2. Notación a usar
La notación determina en gran medida qué personas podrán leer la documentación de la
arquitectura
- Notación completamente informal
El ejemplo de la estación de empaques usa notación informal (diagramas de
cajas).También se usa el lenguaje natural, que es muy ambiguo. tiene la ventaja de
ser entendida por todas las personas. Tiene las desventaja de su ambigüedad, falta
de precisión, y falta de claridad

- Notación semi formal

En esta categoría se ubican notaciones gráficas como el UML. Estos diagramas deben
cumplir ciertas reglas. Los elementos del diagrama muchas veces son descritos en lenguaje
natural
La cantidad de personas en capacidad de interpretar un diagrama UML es menor que en el
caso de informal, se requiere capacitación

- Notación Formal
Existe los lenguajes de descripción arquitectónicos(ADL)Estos lenguajes permiten expresar
matemáticamente los requerimientos
Lenguajes: Z, OCL, VDML. El ocl es el lenguaje que acompaña al UML.
* INDICA ESTADO ANTERIOR
Se desea describir el proceso de agregar un nuevo cliente C a los clientes del
sistema

Cliente=Cliente*U C
Estos lenguajes formales permiten una ESPECIFICACIÓN FORMAL del diseño.
En estas especificaciones se puede DEMOSTRAR aplicando la lógica, el cumplimiento de
cada requerimiento, esta verificación se convierte en una DEMOSTRACIÓN DE
PROBLEMAS. Aquí encontramos ayuda de software para demostración de teoremas(Eje.
Prolog). En sistemas Críticos que pueden originar pérdidas enormes o pérdidas de vidas
humanas se suele usar la formalidad.La desventaja es que la cantidad de personas capaces
de interpretar una definición formal de la arquitectura es muy pequeña
Documente si tiene algo importante que , de lo contrario puede hacerlo

PATRONES DE DISEÑO ARQUITECTÓNICO

Patrones de diseño
Es la documentación de la mejor forma de resolver un problema. En el libro de sommerville
se documentan los siguientes elementos de los patrones arquitectónicos:
- La descripción
- El ejemplo
- Cuando se usa
- Ventajas y desventajas

Ejemplo de patrón de diseño

Nombre del patrón de diseño: MVC(Modelo, Vista, Controlador)
Descripción:
SEPARA presentación e interacción de los datos del sistemas. El sistema se estructura en
tres componentes lógicos que interactúan entre sí.El componente modelo maneja los datos
del sistema y las operaciones asociadas a esos datos. El componente Vista define y
gestiona como se presentan los datos al usuario. El componente Controlador dirige la
interacción del usuario (por ejemplo teclas oprimidas, clics de mouse,etc) y pasa estas
interacciones a Vista y Modelo

Ejemplo:
La arquitectura de una aplicación web:

Cuando se usa?
Se usa cuando existen múltiples formas de ver e interactuar con los datos También se
utiliza los requerimientos futuras para la interacción y presentación
Ventajas:
Permite que los datos cambien de manera independiente de su presentación y visceversa.
Soporta la presentación de los mismos datos en diferentes formas y cambios en una
representación, se muestra en todas ellas.
Desventajas:
Puede implicar código adicional y complejidad de código cuando el modelo de datos y las
interacciones son simples

10/04/2019
El MVC contiene todo el mecanismo para manejar múltiples vistas de los mismos datos.
También puede manejar solicitudes de cambio (eventos de usuario) provenientes de las
vistas y gestionados por el controlador .

Nombre: Arquitectura de capas

Descripción:
Organiza el sistema en capas con funcionalidad relacionada en cada capa .Una capa de
servicios a la capa de encima ,de modo que la capa de nivel inferior representa los servicios
del núcleo (kernel) del Sistema operativo o de soporte.
(Cada capa debe tener cohesión, se minimiza la comunicación entre capas para obtener
mayor desempeño)

-----0 ofrecer servicio

-----( requerir un servicio
-----(0-- el servicio requerido engrana con el servicio requerido
Ejemplo
Modelo de capas del sistema LIBSYS que permite a varias bibliotecas distribuidas
geográficamente , compartir documentos pero respetando los derechos de autor.

Cuando se usa:
Se usa cuando se construyen nuevos servicios encima de sistemas existentes; cuando el
desarrollo se dispersa en varios equipos de trabajo y cada uno es responsable de una capa
de funcionalidad ; cuando exista un requerimiento de seguridad multinivel.

Multics: 1964

Desarrollo de un S.O multiusuario y multitarea

Recordar el sistema de capas de Davivienda

Ventajas:
Permite la situación de capas completas en tanto se conserve la interface .Para aumentar la
confiabilidad del sistema en cada capa pueden incluirse facilidades redundantes (por
ejemplo autenticación)
Se puede implementar controles de seguridad entre capa y capa creando un sistema de
seguridad multinivel.
Desventajas:
En la práctica es difícil ofrecer una separación limpia entre capas y es posible que la capa
superior deba interactuar con la capa inferior directamente en vez de hacerlo por las capas
intermedias.(es una violación del modelo).
El rendimiento suele ser un problema debido a que una solicitud de servicio se debe
procesar en múltiples capas ( taladrando capas ).
Mientras más capas tiene un sistema más ineficiente es .

Sustitución de capas
La sustitución de capas ha hecho posible el software portable a varios entornos operativos.

Ej:El Java

12-04-2019

Nombre: Repositorio
Descripción:
Todos los datos en un sistema se gestionan en un Repositorio central, accesible a todos los
componentes del sistema. Los componentes no interactúan directamente, sólo a través del
repositorio.
Ejemplo:
Un IDE (Integrated Development Environment). El IDE tiene varias herramientas
(Componentes) pero los datos quedan almacenados en un repositorio central.

Cuando se usa:
Cuando se tiene un sistema que necesita almacenar grandes cantidades de datos durante
mucho tiempo. También se usa en sistemas administrados por datos en los cuales la
inclusión de datos en el sistema puede activar una o más herramientas o componentes.

Ventajas:

Los componentes tienen mucha independencia. Un componente no necesita conocer la

existencia de otros componentes. Los cambios que un componente hace sobre los datos,
son percibidos por los demás componentes. La totalidad de los datos se puede gestionar de
manera consistente (Ej: se hace o se puede hacer backup a todos los datos al mismo
tiempo), pues todos los datos están en el mismo lugar.
Desventajas:

El repositorio es un punto de fallo único. Las fallas del repositorio afectan a todo el sistema.
Es posible que haya ineficiencia al organizar toda la comunicación a través del repositorio.
Quizás sea difícil distribuir el repositorio entre varias computadoras. (problema de
accesibilidad). La reutilización es difícil porque el elemento de software que se quiere
reutilizar debe manejar la estructura de datos del repositorio. Es muy difícil que haya dos
repositorios iguales.

La estructura de datos del repositorio podría estar optimizada para algunos elementos de
software y hacerle difícil la vida a otros elementos.

Nii (1986) propone una estructura llamada “blackboard” en la cual hay un flujo de datos y
cada dato puede activar un elemento de software:

Cada componente decide si se activa o no ante un determinado número.

Nombre: Cliente-Servidor

Descripción:

En una arquitectura cliente-servidor, la funcionalidad del sistema se organiza en formas de

servicios y cada servicio lo entrega un servidor independiente.
Los clientes son usuarios de dichos servicios y para utilizarlas ingresan a los servidores.

Los servidores y los clientes son procesos que se pueden ubicar en cualquier máquina de
una multicomputadora- el tercer elemento no mencionado es la red que una clientes y
servidores.

Ejemplo:
Un filmoteca y videoteca accesible desde la web:

Cuando se usa:
Cuando se necesita acceder a los datos de una base de datos compartida desde distintas
ubicaciones. Como los servidores se pueden replicar también se usa cuando la carga de
trabajo es variable.
Ventajas:
La principal ventaja es que los servidores puedan distribuirse a lo largo de una red y pueden
replicarse.
El sistema es escalable.
Puede compartir recursos y utilidades generales: impresoras, plotter, compiladores, etc.
Desventajas:
Cada servicio es un punto de falla (excepto si se replica) y es susceptible a ataques de
denegación del servicio (DOS) y a fallas del servidor.

El desempeño será impredecible porque el sistema está formado por muchos elementos de
software, hardware y red.

Si el sistema cruza las fronteras empresariales, pueden haber problemas por la

administración de las máquinas que pertenecen a distintos diseños.

Para hacer crecer el sistema es muy sencillo, solo se agregan más servidores.

_________________________________________________________
22/04/2019

Nombre: Tuberías de filtro

Descripción:
El procesamiento de datos en un sistema se organiza de forma que cada elemento de
procesamiento (Filtro) sea discreto y realice algún tipo de transformación de datos. Los
datos fluyen (como en una TUBERÍA) de componentes a otro para su procesamiento.

Entrada------------>transformación(Filtro)------->salida

La tubería conduce los datos de un filtro a otro:

datos-----------> tuberia------------->datos
No transforma los datos sino que los transporta

Ejemplo:
Un sistema de procesamiento de facturas organizado como tuberías y filtros:

Cuando se usa?
Se suele utilizar en aplicaciones de procesamiento de datos (tanto basados en toles como
en transacciones), donde las entradas se procesan en etapas separadas para generar
salidas relacionadas.

Ventajas:
Fácil de entender y soporta reutilización de transformaciones. El estilo de flujo de
trabajo(workflow) coincide con la forma de trabajar en muchas empresas. La evolución del
sw es directa, consiste en agregar más transformaciones. Se puede implementar como un
sistema secuencial o como una concurrente

Desventajas:
El formato para la transferencia de datos debe acordarse entre las transformaciones que se
comunican.
Cada transformación debe:
- Analizar y sintetizar sus salidas en el formato acordado
Esto aumenta la carga del sistema y puede significar que sea imposible reutilizar
transformaciones funcionales que usen estructuras de los datos incompatibles

Ejemplo:
tuberías y filtros en linux:
cat archivo: Lee el archivo y lo entrega a la salida

grep(“cadena”): Solo deja pasar los datos que contiene la cadena. Los datos son renglones
de texto

sort: Ordena en orden alfabético por el primer byte

sort- k columna(columna separada por tabulador)
Las tuberías deben hacer que la salida de un programa sea la entrada de otro
En linux la tubería es el símbolo “|” y se llama “pipe”

Ejemplo: A|B
La salida de A es la entrada de B
Suponga que existe el archivo
Ventas:
Pereira Nevera Gonzalez
Armenia Televisor cortez
Manizales Televisor henao
Pereira Televisor cortez
Armenia Estufa gonzalez
Manizales Estufa cortez

Ej-1: Informe de ventas por vendedor

cat ventas|sort -k 3
Ej-2: Informe de ventas de televisor ordenadas por ciudad
cat ventas| grep “televisor”|sort
Hace procesamientos por lotes. En linux, se puede procesar programas concurrentes con el
símbolo &
cat ventas| sort - k 3| por vendedor & cat ventas|grep”televisor| sort>televisores
Es difícil usar tuberías y filtros para sistemas interactivos

Arquitecturas fundamentales
Capas, repositorio, cliente-servidor, tuberías y filtros

Control de las Arquitecturas

Controlar un programa consiste en poderlo activar y desactivar.Hay controles de tipo
centralizado y distribuido.

Control centralizado:
Hay un componente/subsistema encargado de activar o desactivar a los demás
Control distribuido:
Cada componente reacciona ante eventos externo

1.Control centralizado:
a. Control por Administrador: Sistema de control para multicomputadoras, en el cual
existe un proceso central denominado administrador/coordinador que se encarga de
activar o desactivar los demás elementos
Ejemplo: Un avión (motores, alerones, tren de aterrizaje, cola)
El software de la cabina controla al computador de cada elemento.
Edificios con sistema de seguridad, una consola central.
b. Control por “llamada-retorno”: Sistema de control para multiprocesador. Opera dentro
de una computadora. El sw comparte la memoria RAM. Tiene la pila o STACK dedicada al
control de los programas.
Para comenzar una aplicación ejecuta la función MAIN
Así la función main obtiene el control. Luego main puede delegar el control a otro elemento.
Al terminar este elemento ejecuta la orden return y así le regresa el control a quien se lo
había prestado
Este esquema de control tiene forma de árbol y la raíz del árbol es el main.

La PILA que es compartida por todos los programas contiene la dirección de retorno de
cada programa:
Pila: Login 100
menuprincipal 150
transacciones 300
ventas 500
2.Control distribuido
a. Control por flujo de eventos
Es un sistema de control para multicomputadoras. Existe un flujo de eventos
externos que podrían ir por la red o por otros medios.

Los eventos deben llegar a todos los componentes. Un componente, al recibir un

evento, debe tomar la decisión de activarse o no activarse con este evento
Se podría hablar de AUTOCONTROL por que cada componente se controla a sí
mismo .
En este sistema cada evento es transmitido a todo los nodos de la red, esto se llama
broadcasting, esto es un problema porque puede saturar la red. La comunicación
ideal es el unicasting o uno-a-uno. Para lograrlo se necesita un nodo especial que
suele llamar manejador de eventos. Este nodo recibe todos los eventos y los envía
solo a los componentes que se activan con el evento en una forma uno-a-uno. Se
necesita una tabla

Componente Evento

A 3

B 2

B 1

C 4
 quiz 4 arquitecturas viernes 26
capas
repositorio
cliente-servidor
tuberías y filtros

24-04-2019
B. Control por interrupciones

Es un sistema de control distribuido para multiprocesadores.

Se aplica a sistemas de tiempo real.

¿Que es un sistema de tiempo real?

Es un sistema electrónico que controla un proceso físico.
El proceso físico ocurrirá aunque no funcione el sistema electrónico. Si el proceso físico es
lento, el sistema de control tiene mucho tiempo para actuar y se denomina sistema de
tiempo real BLANDO.

Ejemplo: Proceso de cubrir galletas wafer con chocolate.

Si el proceso físico es muy rápido, el sistema de control tendrá que actuar en tiempos muy
cortos y esto se llama sistema de tiempo real DURO.

Ejemplo: Bolsa de aire inteligente en los vehículos.

Partes de un sistema de tiempo real:

● Sensores: Capturan el estado actual del proceso físico
 ● Actuadores: Pueden modificar el estado del proceso físico

Sistema de control:
Tiene como entradas:
● El estado del proceso físico
● El estado deseado y calcula la acción de los actuadores
Para estos sistemas de control se requiere un procesador dedicado.
Supondremos que el procesador es un microcontrolador

Es un cambio en un puerto de entrada

Cuando se genera el evento , el chip genera una señal para el programa llamada una
interrupción.
El programa es un ciclo infinito :

While (TRUE)
{
Instrucciones de
Trabajo
Rutinario
}
Este programa principal puede ser interrumpido para procesar un evento y luego continuará
en el lugar donde iba. Se hace por medio de la pila:

● Pila
Prog.principal , dirección de retorno

Mecanismo de las interrupciones

● Vector de interrupción:
Vector que tiene una posición booleana para cada puerto de entrada.
El valor normal es 1.
Cuando ocurre un cambio en el puerto ,el valor se pone en 0 .Por medio de este
vector el programa puede detectar que hay un evento.

● Tabla de interrupción:
Esta tabla contiene una posición para cada puerto de entrada y su valor es la
dirección de memoria de programa a la cual se debe saltar en caso de un evento en
ese puerto.

● Manejador del evento:

Es una subrutina que operará sobre los actuadores o puertos de salida y termina con
la instrucción RETI (Retorno de interrupción).

La orden RETI hace que el control pasé a la dirección de retorno que está en la pila y
entonces el sistema continúa con el programa principal.

El tiempo de espera que ocurre entre el momento de ocurrir un evento y la respuesta al

mismo es del orden de nanosegundos.
Es el tiempo de respuesta más rápido que existe.
La desventaja está en la depuración o búsqueda de errores que es muy difícil.

Arquitecturas de aplicación

Todas las empresas son muy parecidos es que se deben administrar los mismos recursos:
● Dinero ---->Área contable y financiera
● Personal. ---->Área de recursos humanos
● Clientes ---->Área de mercadeo y ventas
● Servicios ---->Área de servicio al cliente
● Fabrica ---->Área de producción
● Información ----> Área de informática

Pero las empresas del mismo sector económico se parecen mucho más.
Han surgido arquitecturas genéricas para ciertos sectores económicos.

¿Cómo usar estas arquitecturas ‽

1. Cómo punto de partida para el proceso de diseño
2. Cómo una lista de verificación para el diseño
3. Cómo una forma de repartir el trabajo entre el equipo de desarrollo
 4. Como una forma de valorar componentes reutilizables
5. Cómo un vocabulario para que todos los interesados puedan conversar acerca del
sistema.

Vamos a ver:
● Sistemas de procesamiento de transacciones
● Sistemas de información
● Sistemas de procesamiento del lenguaje

Sistema de procesamiento de transacciones

Se conocen como TP(Transaction processing). Procesan solicitudes que van a afectar una
base de datos.

Transacción:
Un conjunto atómico de operaciones de bases de datos. Se realizan todas las operaciones
o no se realiza ninguna, pero la transacción no se puede ejecutar parcialmente.

Ejemplo:
Una reserva aérea de varios vuelos para llegar a un destino como Münich , si faltara uno de
los vuelos , no se podría llegar.
La transacción son todos los vuelos.
Casi siempre los TP son interactivos es decir interactúan con un usuario. El usuario origina
alguna solicitud que debe ser procesada. El sistema debe responder al usuario en el menor
tiempo posible. Son sistemas de tipo solicitud-respuesta .
Estos sistemas de pueden modelar con tuberías y filtros.
Ejemplo: Un cajero electrónico
Órdenes para manejo de transacciones:

BEGIN TRANSACTION

COMMIT Cometer la transacción

ROLBACK deshacer la transacción

26-04-2019

Sistemas de información
Mientras en un TP la operación relevante es la modificación de la base de datos en un
sistema de información, la operación relevante es la consulta. En muchas ocasiones los
clientes solo consultan y hacen búsquedas de la información como en el caso del catálogo
de productos de una empresa, la información de vuelos de un aeropuerto, información de
vehículos o multas de tránsito.

Es muy normal que los sistemas de información se presenten conjuntamente con sistemas
de procesamiento de transacciones. Ej: consulta de catálogo + compra electrónica. Los SI
se modelan con una estructura de capas:

Ejemplo:
Sistema MHC-PMS que mantiene información sobre pacientes de enfermedad mental,
utilizando la web.
Actualmente todos los SI son orientados a la web. Cada capa tiene una o más máquinas.

El modelo de capas permite colocar varias máquinas en una capa para incrementar el
rendimiento del sistema.

Sistemas de procesamiento del lenguaje

Traducen o convierten información de un lenguaje a otro.

Los lenguajes pueden ser humanos en cuyo caso se trata de un traductor o artificiales en
cuyo caso se trata de un interpretador o compilador.

Si pasamos de un lenguaje humano a uno artificial, estamos hablando de inteligencia

artificial. Estamos interpretando y analizando el lenguaje natural.

Pasar de un lenguaje artificial a un lenguaje humano es sintetizar el lenguaje natural.

Ej:
Traducir órdenes en lenguaje natural a órdenes SQL.
Traducir de xml a SQL.
Podemos modelar estos sistemas mediante tuberías y filtros.

Se ha modelado un compilador.
Es un enfoque de procesamiento por lotes.

Las herramientas de desarrollo actuales son interactivas. Estas se modelan como

repositorio.
 ● El analizador léxico tomamos tokens o símbolos y los almacena en una forma
interna (la tabla de símbolos).
● La tabla de símbolos contiene todos los nombres usados en el texto.
● El analizador sintáctico revisa las estructuras que acompañan a los tokens del
lenguaje. Utiliza la definición sintáctica del lenguaje. Verifican si se usan
correctamente (bien formadas).
Genera el árbol de sintaxis, una estructura inventada por Chomsky.
● El analizador semántico toma el árbol sintáctico y va reemplazando en él los
símbolos y crea enlaces a estos símbolos. Los símbolos no encontrados se
buscarán externamente en el enlace con librerías (link).
● El generador de código recorre el árbol de sintaxis y reemplaza los símbolos por su
dirección de memoria, o su instrucción de salida.

Podrían requerirse otros componentes como diccionarios, optimizador de código,

conjugador de verbos, etc.
Se puede modelar con un repositorio real:
Tiene ventajas como:
● Si un componente realiza un cambio, los demás se dan cuenta.
● El programa se podría analizar a medida que se escribe.
● Al analizar el programa a medida que se escribe, se puede mostrar de una manera
estética identificando órdenes de lenguaje, variables, operadores, funciones,
comentarios, etc, con colores y tipografía especial.

29/04/2019

Reutilización de Software
Motivación: A la industria de software se le está exigiendo:
- Menores costos de desarrollo
- Menores costos de mantenimiento
- Menores plazos de desarrollo

La solución a estas exigencias está en la Reutilización del Software

Historia
La reutilización es propuesta por Mcilroy en 1968. Pasó desapercibido durante muchos años
hasta que en el año 2000 las empresas se dan cuenta que la reutilización soluciona mucho
de sus problemas.Aparece entonces la reutilizacion com una estrategia empresarial para
las compañías que desarrollan el software

Este tiene dos ventajas:

- El repositorio de software reutilizable ya no es individual si no de todas las empresas
y todos los desarrolladores se pueden beneficiar.
- El proceso de desarrollo de la empresa incluirá actividades de reutilización que no
son estandar

Disponibilidad
Además de los repositorio empresariales de software el movimiento de fuente abierta y el
movimiento de software libre han creado mucho software que se puede reutilizar

Sitios importantes:
- sourceforge
- code.google.com
- wordpress

Tamaño del software a reutilizar

La aplicación:
En lugar de desarrollar software se decide adquirir una aplicación
Esto es posible si se tiene la suerte de encontrar en el mercado una aplicación que cumpla
con los requerimientos

Componente
El componente es el tamaño ideal para la reutilización. Se han hecho esfuerzos para crear
un mercado de componentes. Ej: Wordpress
Hay empresas que suministran componentes a sus clientes
Ejem: Oracle, wowza, pasarelas de pago electrónico

Objetos y funciones:
La primera forma de reutilización fue las librerías de funciones
También existen librerías de objetos o clases que se llaman frameworks.Se reutlizan
elementos pequeños de software

Beneficios de la reutilización:

- Confiabilidad creciente: El software reutilizable ya ha sido probado y usado en la

práctica y se conoce su calidad. Esto incrementa la confiabilidad del proyecto.
- Reducción del riesgo del proceso: El principal riesgo de un proceso de desarrollo es
el incumplimiento del plazo y los sobrecostos. El plazo y el costo tiene mucha
incertidumbre. En un software reutilizable hay incertidumbre, esto reduce el riesgo
del proyecto.
- Uso efectivo de especialistas: En un software reutilizable se puede capturar el
conocimiento de un especialista y no tener que controlar repetidamente esta labor.
- Cumplimietno de estandares: Un componente de software puede garantizar el
cumplimiento de algún estándar, por ejemplo estándar de imagen corporativo,
estándar de comunicación, etc
- Desarrollo acelerado: Al incluir software reutilizable en un proyecto, el plazo se
reduce.
Reutilización de conceptos
 Se puede reutilizar una idea, un concepto, un procedimiento, etc.
Ejem: Steve Jobs vs Bill Gates y el caso de la ventana

Problemas relacionado con la reutilización de software

- Costos creciente de mantenimiento: Si se utiliza un software ejecutable del
cual No se tiene el fuente, los requerimientos combinarán pero no tenemos el
programa fuente para cambiar el ejecutable. Tendremos que crear código
adaptados el cual tiene un costo. Por eso a medida que los requerimientos
cambian, el costo del mantenimiento crece
- Falta de apoyo de las herramientas: Las herramientas que desarrollan como
Eclipse, netbeans, etc, permiten reutilizar código fuente, pero muchas no
apoyan la reutilización de código ejecutable especialmente para el código
empotrado(Microcontroladores), las herramientas no apoyan la reutilización
- Síndrome de “No se inventó aquí”: Muchos desarrolladores de software son
renuentes a reutilizar software de otros. Aducen las siguientes razones:
Creen que lo pueden hacer mejor, falta de confianza en realidad van la labor
de programación como desafiante y placentera y ni quieren renunciar a ella.

Creación,mantenimiento y uso de una librería de componentes

Crear una librería, mantenerla y lograr que los desarrolladores la usen tiene unos costos
asociados. La búsqueda, la prueba, la catalogación y divulgación del software suelen ser
actividades que tiene un costo. Además hay que modificar los procesos del ciclo de vida
para incluir en ellos la reutilización de software.

Descubrimiento, comprensión y adaptación de componentes reutilizables

- Se debe buscar componentes en toda la internet
- Se debe entender cada componente
- Se debe probar el componente
- Muchas veces hay que adaptarlo a nuevas necesidades
- Una vez incluido en el repositorio los desarrolladores de software deben hacer una
búsqueda antes de desarrollar algún software. Todas estas actividades gastan horas
de ingeniero y con costos para el proyecto
Los japoneses tienen la teoría de la fábrica de software y desde 1984 incluyeron el
concepto de reutilización(Matsumoto)
En EE.UU la Hewlett-packard ha trabajado la reutilización a nivel empresarial. Esto se
documenta en el libro de jacobson en 1997

04-05-2019
Técnicas de reutilización

Patrones arquitectónicos
Se usan arquitecturas estándar de software que apoyan tipos comunes de aplicaciones.
No se reutiliza código sino la arquitectura.

Patrones de diseño
Los patrones arquitectónicos pertenecen a la categoría más general de patrones de diseño,
en la cual aparecen abstracciones, objetos y clases que se utilizan en la resolución de
problemas. Algunas categorías de patrones de diseño son:
 ● Arquitectónicos
● De comunicación
● Interfaces de usuarios
● Asignación de responsabilidades (GRASP)

Desarrollo basado en componentes

(CBSE Component Based Software Engineering)
Son elementos de software que ofrecen y consumen servicios. Tienen interfaces y son
código ejecutable. Las aplicaciones pueden integrar o incluir estos componentes y usar sus
servicios.

Frameworks de Aplicaciones
Son colecciones de clases y objetos que se utilizan en las aplicaciones mediante la
herencia.

Encadenamiento de Sistemas Heredados

Los sistemas Heredados son software antiguo, posiblemente de tecnologías obsoletas, pero
con el cual deben interoperar las nuevas aplicaciones.
Hay varias formas de integrar el software heredado a las aplicaciones modernas,
generalmente creando algún tipo de interface.

Sistemas orientados a Servicios

Las aplicaciones utilizan servicios externos que son accesibles mediante la red.
Estos servicios cumplen un estándar para servicio tal como el WS (Web Service).

Líneas de productos de software

Son familias de aplicaciones que utilizan la misma arquitectura y reutilizan gran parte del
código. La familia comienza con un producto genérico que se va adaptando en la
necesidades de diferentes clientes.

Reutilización de sistemas COTS

Commercial Off The Shelf.
Son aplicaciones especializadas que se venden en tiendas de software. Estas aplicaciones
se usan “como vienen”. Los desarrolladores no la adaptan a necesidades particulares de
clientes, más bien esperan que los clientes se adapten a la aplicación.

Sistemas ERP
Enterprise Resource Planning.
Son sistemas enormes que pretenden cubrir todas las necesidades de una empresa. Son
muy versátiles, tienen un lenguaje de reglas del negocio, con el cual se pueden crear las
reglas de cualquier empresa.
Ej: SAP

Aplicaciones verticales configurables

Se especializan en un solo proceso de negocio pero son configurables, es decir, se pueden
adaptar a las necesidades de la empresa, dentro de ciertos límites.

Librerías de funciones
Fueron la primera estrategia de reutilización.
Son funciones que se pueden llamar desde la aplicación y se enlazan durante la
compilación en un proceso llamado link.

Todos los lenguajes de programación suelen tener librerías de funciones.

Ingeniería dirigida por modelo MDA

Model Driven Architecture.
Los desarrolladores crean los modelos de requerimientos y de diseño sin casarse con
ninguna tecnología de implementación.
Luego los generadores de código pueden crear automáticamente la aplicación para un
entorno operativo elegido por el desarrollador.

Generador de programas
Se crean para diferentes dominios de problemas y tienen incrustado mucho conocimiento
del dominio.
El desarrollador aporta a la estructura del programa y en generador de encarga de crear
una aplicación.

Generación de software orientado a aspectos

Se definen los aspectos de un algoritmo y luego estrategias para cada aspecto. Estas
estrategias se insertan en los algoritmos en el lugar apropiado.

¿Cuál es la técnica más adecuada para una situación?

Existen factores a tener en cuenta:

1. Calendario de desarrollo de sw
Si el plazo para resolver el problema es muy corto, hay que adquirir aplicaciones
COTS.
Aunque habrá problemas con el ajuste a los requerimientos, el problema principal se
resuelve en un plazo mínimo.

2. Vida útil del software

Si la solución debe durar muchos años, nos debemos enfocar en la mantenibilidad
de la solución.
Para poder mantener el software en el largo plazo es necesario tener el programa
fuente. Esto descarta los métodos donde no se tiene el fuente:
● COTS
● Componentes ejecutables sin fuente
● Servicios en los cuales se sospeche que el proveedor no se mantendrá
activo en el mercado durante toda la vida útil del software.

3. Antecedentes, habilidades y experiencia del equipo de desarrollo

Si tiene un plazo restringido, no use una técnica que el grupo desconozca o con la
cual no tienen experiencia, esto le retrasará el proyecto.

4. Criticidad del software y sus requerimientos no funcionales

 Para software crítico hay que usar métodos formales en los cuales la especificación
del software es matemática y existen pruebas del software que son demostraciones
matemáticas.
Para esto es necesario tener el código fuente y el documento de requerimientos.
No usar la estrategia del generador de código porque el código generado es
ineficiente.

5. El dominio de la aplicación
Para muchos dominios de problema existe gran cantidad de productos genéricos. En
estos dominios se debe considerar los COTS.
Ej: área contable y financiera, área médica.

Frameworks de Aplicación
Los entusiastas del desarrollo orientado a objetos prometían la reutilización de las clases.

En la realidad, la clase que se pretendía reutilizar tenía muchas dependencias:

Era necesario llevarse también todas las clases que dominan a la clase A.
El problema es que B, C, D también tiene dependencias.
En conclusión, para reutilizar clase hay que llevarse al otro proyecto una gran familia de
clases interdependientes.
Por este camino llegamos a la idea del framework.
En el 2004, Schmidt define el framework como:
“... Un conjunto integrado de artefactos de software (tales como objetos, clases y
componentes) que colaboran en la facilitación de una arquitectura de reutilización para una
familia de aplicaciones”.

Un framework debe ser muy genérico, sus características deben poder ser usadas por
muchísimas aplicaciones.
Si el framework fuese específico para un tipo de problema, pocas aplicaciones lo usarían.

Para utilizar un framework, el desarrollador crea sus propias clases pero las hace heredar
de clases del framework.
El mecanismo para usar un framework es la herencia. Los frameworks sólo existen para
lenguajes orientados a objetos.

Los frameworks dependen del lenguaje de programación, es decir, son específicos para un
lenguaje.

La arquitectura del framework la definen las clases y las interacciones.

Schmid en 1997 define tres tipos de framework:

1. Framework de infraestructura del sistema

Sirven de apoyo a las aplicaciones. Prestan servicios genéricos como comunicaciones,
interfaz de usuario, compiladores, etc.

2. Framework de integración middleware:

Son un conjunto de estándares y clases que permiten a los objetos remotos y a los
componentes comunicarse a través de una red e integrarse para formar aplicación

Ejemplo:
Microsoft.net
EJB enterprise Java beans
J2EE
Corba

3. Framework de aplicación empresarial:

Estos frameworks utilizan los tipos anteriores e incluyen conocimiento de un dominio de

aplicación para crear elementos específicos

4. WAF

Web application frameworks. Son frameworks para crear aplicaciones web

Hay frameworks para generar código HTML como Faces

Otros Ejemplos:
ASP.NE
JAVA EE
WEB OBJECTS
WEBZPY
OPEN ACS
LARAVEL
SAILS JS
DJANGO

Los frameworks WAF soportan las siguientes características

1. Seguridad
Pueden proporcionar clases para definir usuarios y hacer el control de acceso

2. Páginas web dinámicas:

Permiten crear formularios y procesar eventos de usuario. También permiten la conexión
directa con una base de datos

3. Soporte de la base de datos

El framework ofrece clases para servir de interfaz con una base de datos

4. Gestión de la sesión
Clases para manejar l información de la sesión y el almacenamiento de información en
cookies

5. Interacción con usuarios

Clases que manejan los eventos de usuario

El control en los frameworks

La aplicación tiene el control, lo delega a la función de biblioteca y luego el control retorna la

aplicación
La aplicación tiene el control, llama al objeto remoto y se bloquea. El objeto remoto se
activa, procesa la llamada, envía la respuesta.

Al recibir la respuesta, la aplicación se bloquea.

Control inverso

Cada framework tiene un ciclo de evento el cual se encarga de atrapar los eventos que le
interesan al framework (eventos de usuarios, eventos de red, eventos de base de datos) El
framework llama a la clase de la aplicación que hereda del framework
El usuario genera un evento (click en un botón) el cual cual es atrapado por el framework.
El framework llama a la clase aceptar de la aplicación, la cual hereda de la clase button del
framework.
La clase button tiene un método click() el cual es heredado por la clase aceptar

El desarrollo ha redefinido el método click con el código de aplicación.

El framework llama al método click de la clase aceptar.

Aquí el control funciona al revés. Esto se denomina inversión del control.

Los métodos como el click que pueda ser invocados por el framework, se denominan
callbacks.

Para aprender a usar un framework se requiere gran energía y tiempo (más de un mes)

Evaluar varios frameworks para elegir el más apropiado, es una labor que consume también
mucho tiempo y energía.
Línea de producto de software

Una línea de productos es una familia de aplicaciones la cual comparte gran parte del
código por cada aplicación ha sido adaptada a un cierto tipo de cliente

La parte que es común a todos los clientes es el código que se va a reutilizar.

La línea de productos se diseña para maximizar el código común. La meta es que sea cerca
al 801 del código
Con el código común podemos crear una aplicación base y a partir de este momento, crear
una nueva aplicación consiste en hacer una copia de la aplicación base y adaptarla al nuevo
usuario.

Las líneas de producto surgen de aplicaciones existentes en las cuales se van repitiendo
ciertos patrones de software.

En algún momento se hace el análisis de qué es lo común a todas esas aplicaciones se

crea la aplicación base y surgen la linea de productos.

El mecanismo para usar la linea de productos es copiar y pegar.

Las líneas de productos incluyen conocimiento específico de un dominio de problemas.

Muchas veces la arquitectura que comparte una línea de productos es un hardware

Ejemplo: aplicaciones relacionadas con una impresora
Aplicaciones para plataforma play station.

Forma de especializar una aplicación base

1. Especialización de plataforma
Se crean versiones de la aplicación para distintas plataformas:

Linux
Windows
iOS
Android

2. Especialización de entorno

La aplicación se especializa para distintos ambientes

Ejemplo: aplicación de despacho de vehículos
V1: taxis con radio telefono
V2: taxis con smartphone

3. Especialización funcional

Versiones para clientes con diferentes requerimientos funcionales:

Ejemplo: inventarios
V1: supermercados
V2: droguerías
V3: cuentadantes
V4: maquinaria

4. Especialización de proceso
Diferentes empresas realizan el mismo proceso de formas distintas

Ejemplo: proceso de pedidos

V1: pedidos centralizados. El cliente tiene que llamar a un único número telefónico

V2: la empresa tiene agentes viajeros que recorren el territorio visitando a los clientes y
haciendo pedidos.