Unidad 3 Construccion

Desarrollo de proyectos
• 3.1 Despliegue de Componentes y Arquitectónico
• 3.2 Técnicas de Desarrollo de las Arquitecturas de Referencia
en Diferentes Dominios
– 3.2.1 Los Modelos de Componentes
– 3.2.2Arquitectura de Referencia para Sistemas de Tiempo Real
Fuente de Alimentación
– 3.2.3 Arquitectura de Referencia para Sistemas Móviles con
Conexión A Internet
– 3.2.4 Arquitectura de Referencia para Sistemas de Información
– 3.2.5 Arquitectura de Referencia para Ambientes Virtuales de
Aprendizaje
– 3.2.6 Arquitecturas de Referencia para Líneas de Productos
 3.1 Despliegue de componentes y
arquitectónico.
• ¿Qué es UML? UML = Unified Modeling Language
• Un lenguaje de propósito general para el
modelado orientado a objetos. Impulsado por el
Object Management Group (OMG, www.omg.org)
• UML combina notaciones provenientes desde:
Modelado Orientado a Objetos Modelado de
Datos Modelado de Componentes Modelado de
Flujos de Trabajo (Workflows).
 Modelo
• Un modelo captura una vista de un sistema
del mundo real. Es una abstracción de dicho
sistema, considerando un cierto propósito.
Así, el modelo describe completamente
aquellos aspectos del sistema que son
relevantes al propósito del modelo, y a un
apropiado nivel de detalle.
 Modelo
• Un proceso de desarrollo de software debe ofrecer
un conjunto de modelos que permitan expresar el
producto desde cada una de las perspectivas de
interés
• El código fuente del sistema es el modelo más
detallado del sistema (y además es ejecutable). Sin
embargo, se requieren otros modelos.
• Cada modelo es completo desde su punto de vista
del sistema, sin embargo, existen relaciones de
trazabilidad entre los diferentes modelos.
 Diagrama
• Una representación gráfica de una colección
de elementos de modelado, a menudo
dibujada como un grafo con vértices
conectados por arcos
 Componente
• Un componente es una parte física y
reemplazable de un sistema.
 Diagrama de despliegue
• Es un tipo de diagrama UML que se utiliza
para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones
entre sus componentes.
• Los elementos usados por este tipo de
diagrama son nodos (representados como un
prisma), componentes (representados como
una caja rectangular con dos protuberancias
del lado izquierdo) y asociaciones.
 Ejemplo diagrama de despliegue

Nodo
 Otro ejemplo diagrama de despliegue
• Un diagrama de despliegue muestra el despliegue
físico del sistema en un ambiente de producción (o
de prueba). Muestra dónde se ubican los
componentes, en qué servidores, máquinas o
hardware. Puede representar los enlaces de redes, el
ancho de banda de la LAN, etc.
3.2 Técnicas de desarrollo de las arquitecturas
de referencia en diferentes dominios.
 3.2.1 Los modelos de componentes
• El modelo de componentes ilustra los componentes
de software que se usarán para construir el sistema.
Se pueden construir a partir del modelo de clases y
escribir desde cero para el nuevo sistema o se
pueden importar de otros proyectos y de productos
de terceros. Los componentes son agregaciones de
alto nivel de las piezas de software más pequeñas y
proveen un enfoque de construcción de bloques de
“caja negra” para la elaboración de software.
 Notación de Componentes
• Un componente puede ser algo como un
control Actives; tanto un componente de la
interfaz de usuario como un servidor de reglas
de negocio. Los componentes se representan
gráficamente como muestra la figura
siguiente:
 Diagrama de componentes
• El diagrama de componentes muestra la relación
entre componentes de software, sus dependencias,
su comunicación su ubicación y otras condiciones
• Los componentes también pueden exponer las
interfaces. Estas son los puntos visibles de entrada
o los servicios que un componente está ofreciendo
y dejando disponibles a otros componentes de
software y clases. Típicamente, un componente
está compuesto por numerosas clases y paquetes
de clases internos. También se puede crear a partir
de una colección de componentes más pequeños.
 Requisitos y restricciones
• Requisitos: Los componentes pueden tener requisitos
adjuntos para indicar sus obligaciones contractuales; esto
es, qué servicios proveen en el modelo los requisitos
ayudan a documentar el comportamiento Funcional de los
elementos de software.
• Restricciones: Los componentes pueden restricciones
asignadas que indican el entorno en el que operan. Las pre-
condiciones especifican lo que debe ser verdadero antes de
que un componente pueda realizar alguna función; las post-
condiciones indican lo que debe ser verdadero después de
que un componente haya realizado algún trabajo y los
invariantes especifican lo que debe permanecer verdadero
durante la vida del componente
 Escenarios y Trazabilidad
• Escenarios: Los escenarios son descripciones textuales y
procedimentales de las acciones de un objeto a lo largo del tiempo y
describen la forma en la que un componente trabaja. Se pueden crear
múltiples escenarios para describir tanto el camino básico (una
ejecución perfecta) como las excepciones, errores y otras condiciones.
• Trazabilidad: Puede indicar la trazabilidad por medio de vínculos de
realización. Un componente puede implementar otro elemento del
modelo (por ejemplo un caso de uso) o un componente puede ser
implementado por otro elemento (por ejemplo un paquete de clases).
Al emplear las relaciones de realización desde y hacia los
componentes, se pueden seguir las dependencias entre los elementos
del modelo y la trazabilidad desde los requisitos iníciales hasta la
implementación final.
 Ejemplo
• El ejemplo siguiente muestra cómo se pueden
relacionar los componentes para proveer una
vista conceptual/lógica de la construcción de
un sistema. Este ejemplo representa los
elementos del servidor y la seguridad de una
tienda de libros en línea. Se incluyen
elementos tales como el servidor WEB, el
firewall, las páginas ASP, etc.
 Componentes del servidor
• Este diagrama ilustra la organización de los
componentes del lado del servidor principal
que se requerirá construir para una tienda de
libros en línea. Estos componentes son una
mezcla de los ítems construidos a medida y
adquiridos que se ensamblarán para proveer
la funcionalidad requerida
Diagrama componentes del servidor
 Componentes de seguridad
• El diagrama de componentes de la seguridad
muestra cómo trabaja en conjunto el software
de seguridad, tal como la Autoridad
Certificadora (Certificate Authority), el
navegador (Browser), el servidor WEB y otros
elementos del modelo para asegurar la
provisión de la seguridad en el sistema
propuesto
Diagrama componentes de seguridad
  
3.2.2 Arquitectura de referencia para sistemas
de tiempo real fuente de alimentación 1/4
• La adopción de Modelos Orientados a Servicios constituye un
cambio de paradigma fundamental, que permitirá aumentar el
dinamismo y competitividad de la sociedad actual
transformándola en una “sociedad basada en el conocimiento”.
Este cambio de paradigma supone que:
• Los modelos de negocio evolucionen desde la venta de productos
hacia la provisión de servicios electrónicos proporcionados desde
la red en modo utilities (siempre disponibles, en cualquier lugar).
Los procesos, tanto procesos de negocio realizados por empresas
como procesos llevados a cabo por individuos o colectivos en su
vida diaria, se definan a partir de servicios de una manera más
ágil y flexible, totalmente adaptada al contexto.
 3.2.2 Arquitectura de referencia para sistemas
de tiempo real fuente de alimentación 2/4
• Este cambio de paradigma conducirá a una mejora
significativa en la vida diaria de negocios, ciudadanos
y colectivos.
– Permitirá a las empresas alcanzar los niveles más altos de
innovación y excelencia en operaciones
– Mejor “time to market”
– También permitirá a individuos y colectivos alcanzar los
niveles más altos de productividad, satisfacción y bienestar.
PYMES) o incluso individuos que no tendrán que limitarse a
ser simples consumidores, sino que podrán jugar el papel
de proveedores de servicios, contenidos
3.2.2 Arquitectura de referencia para sistemas
de tiempo real fuente de alimentación 3/4
• La capacidad de crear y compartir conocimiento,
que se materialice en la capacidad de:
– Construir nuevos recursos y publicarlos en la red
– Intercambiar experiencias con otros, aprendiendo juntos
y acelerando la incorporación como la mejora de la
productividad
– La interacción debe adaptarse y ser relevante al contexto
de manera que comprenda elementos tales como el
contexto del usuario (conocimiento, perfil, preferencias,
idiomas, información sobre las redes sociales, etc.)
 3.2.2 Arquitectura de referencia para sistemas
de tiempo real fuente de alimentación 4/4
• En el ámbito de Internet, además de estos principios, es
necesaria la creación de un ecosistema de negocio sostenible
para todos los implicados en la cadena de valor de los servicios.
• Definir tecnologías que den soporte al concepto de
marketplace, donde diversos modelos de negocio fiables,
innovadores y flexibles puedan ponerse en práctica,
involucrando a los clientes/usuarios finales, a los proveedores
que publican recursos, a los distribuidores que finalmente
hacen que estos recursos sean accesibles, a los posibles
anunciantes que desean acceder a los clientes/usuarios finales.
3.2.3 Arquitectura de referencia para sistemas
móviles con conexión a Internet. 1/3
• La rápida evolución de la sociedad de información
globalizada, está siendo fomentada por un incremento de
la demanda, para unificar servicios integrados de banda
ancha. Los clientes están siendo mayores demandantes en
términos de habilitación de servicios y rendimiento de la
red.
• El desafío es proveer un amplio conjunto de opciones en
términos de servicio, terminales y accesos de red, lo que
es posible de hacer frente con diferentes requerimientos
y proporcionando flexibilidad, modularidad y capacidad
de crecimiento.
3.2.3 Arquitectura de referencia para sistemas
móviles con conexión a Internet. 2/3
• Como se muestra en la Figura 1, un nuevo sistema llamado
radio banda ancha (broadband radio) proveerá de una gran
capacidad alcanzada por:
– Sistema de distribución multipunto local (LMDS: local multipoint
distribution systems)
– Sistema de multimedia satelital de banda ancha (BSM: broadband
satellite multimedia)
– Sistema de banda ancha móvil (MBS: mobile broadband systems)
3.2.3 Arquitectura de referencia para sistemas
móviles con conexión a Internet. 3/3
• A los usuarios se les deberá permitir moverse entre diferentes
segmentos. Ha comenzado a ser una necesidad la gestión de
servicios común, recurso de redes y clientela, que cubra los
segmentos móviles y fijos. Esto necesita una fuerte concentración
en la integración de redes para el continuo desarrollo de procesos.

Es comúnmente aceptado que el suministro de servicios como la

TV interactiva, Internet, educación a distancia y servicios avanzados
de oficina en casa, son necesarios para el desarrollo y crecimiento.
El desarrollo de un sistema de acceso de radio de banda ancha
milimétrico de bajo costo para usuarios fijos y nómades, ayudará a
asegurar a que muchos usuarios accedan a este servicio.
 3.2.4 Arquitectura de referencia para
sistemas de información 1/2
• La decisión de abordar un estudio en profundidad para definir la Arquitectura
de los Sistemas de Información, parte de la necesidad de conseguir unos
objetivos de carácter general, que pueden resumirse en los siguientes puntos:
– Alineamiento de la óptica de negocio con la estructura de los Sistemas de
Información.
– Disponer de un modelo integral que abarque todas las aplicaciones y sistemas
informáticos.
– Determinar la estrategia general de los futuros desarrollos.
– Adecuar los sistemas actuales,
– Definir un horizonte hacia el que evolucionar a corto, medio y largo plazo.
– Potenciar la eficacia de los Sistemas Informáticos
– Posibilitar la incorporación de las tecnologías emergentes de forma eficaz.
– Favorecer la mejora de la calidad profesional y de la gestión interna.
– Reducir los costes y el plazo de disponibilidad de las aplicaciones.
 3.2.4 Arquitectura de referencia para
sistemas de información 2/2
• Al término del Estudio se dispondrá de los siguientes resultados:
– Identificación de los Requerimientos Estratégicos de negocio, desde la óptica de los Sistemas de
Información.
– Modelos estructurados y documentados sobre las Arquitecturas:
– Funcional
– Datos
– Sistemas
– Áreas complementarias seleccionadas
– Identificación de los diferentes Sistemas de Información utilizados,
– Reglas de diseño para implantar nuevas tendencias tecnológicas.
– Reglas de diseño para la estructuración de las aplicaciones.
– Las fronteras de cada uno de los Subsistemas en que se divide el Sistema (interfaces).
– Un equipo formado y conocedor de los modelos diseñados para enfocar la implantación de la
Arquitectura.
– Un soporte informático conteniendo los modelos, cara al enlace con el desarrollo de los proyectos.
– Un diseño previo, no detallado, de cada Sistema,
– Modelo organizativo para la función de Administración de la Arquitectura
– Un Plan Director, especificando la estrategia recomendada para la evolución de los Sistemas.
 3.2.5 Arquitectura de referencia para
ambientes virtuales de aprendizaje. 1/2
• Un Ambiente Virtual de Aprendizaje es el conjunto de entornos
de interacción, sincrónica y asincrónica, donde, con base en un
programa curricular, se lleva a cabo el proceso enseñanza
aprendizaje, a través de un sistema de administración de
aprendizaje.
• La propuesta metodológica para operar los modelos educativos
innovadores es la de Ambientes Virtuales de Aprendizaje (AVA),
ya que crear un ambiente de este tipo no es trasladar la
docencia de un aula física a una virtual, ni cambiar el gis y el
pizarrón por un medio electrónico, o concentrar el contenido
de una asignatura, en un texto que se lee en el monitor de la
computadora.
 3.2.5 Arquitectura de referencia para
ambientes virtuales de aprendizaje. 2/2
• Se requiere que quienes participan en el diseño de
estos ambientes deben conocer todos los recursos
tecnológicos disponibles (infraestructura, medios,
recursos de información, etc.), así como las ventajas
y limitaciones de éstos para poder relacionarlos con
los objetivos, los contenidos, las estrategias y
actividades de aprendizaje y la evaluación.
• Los entornos en los cuales opera un AVA son:
– Conocimiento Colaboración Asesoría
– Experimentación Gestión
 Elementos de un ambiente virtual de
aprendizaje
•Usuarios. Se refiere al QUIÉN va a aprender, a desarrollar competencias, a
generar habilidades, es decir principalmente estudiantes y facilitadores.
•Currícula. Es el QUÉ se va a aprender. Son los contenidos, el sustento, los
programas de estudio curriculares y cursos de formación.
•Especialistas. Aquí está el CÓMO se va a aprender. Son los encargados de diseñar,
desarrollar y materializar todos los contenidos educativos que se utilizarán en el
AVA. Se integra por un grupo multidisciplinario que consta de:
–Pedagogo.
–Administrador
–Diseñador grafico.
–Programador.
–Especialista en tecnología educativa.
–Corrector de estilo.
Fases de creación de un ambiente virtual de
aprendizaje.
• Fase I. Planeación.
• Fase II. Diseño, desarrollo de los entornos y la
producción de los contenidos digitales.
• Fase III. Operación.
3.2.6 Arquitectura de referencia para líneas
de productos.
• Definiciones de Líneas de Productos de Software
• Consiste de una familia de sistemas de software que
tienen una funcionalidad común y alguna
funcionalidad variable .
– La funcionalidad común descansa en el uso recurrente de
un conjunto común de activos reutilizables (requisitos,
diseños, componentes, servicios web, etc.).
– Los activos son reutilizados por todos los miembros de la
familia.
Modelo Básico de una Línea de Productos
de Software (LPS)
 Modelo Básico de una Línea de Productos
de Software (LPS)
• La entrada: Activos de Software. Una colección de partes de software
(requisitos, diseños, componentes, casos de prueba, etc.) que se configuran
y componen de una manera prescrita para producir los productos de la
línea.
• El control: Modelos de Decisión y Decisiones de Productos. Los Modelos
de Decisiones describen los aspectos variables y opcionales de los productos
de la línea. Cada producto de la línea es definido por un conjunto de
decisiones (decisiones del producto).
• El proceso de producción. Establece los mecanismos o pasos para componer
y configurar productos a partir de los activos de entrada. Las decisiones del
producto se usan para determinar que activos de entrada utilizar y como
configurar los puntos de variación de esos activos.  
• La salida: Productos de software. Conjunto de todos los productos que
pueden o son producidos por la línea de Productos.
 Líneas de productos de software
• La entrega de productos de software busca una manera:
– Más rápida.
– Económica.
– Con una mejor calidad.
• Las líneas de producción producen mejoras en:
– Tiempo de entrega del producto (time to market).
– Costos de ingeniería.
– Tamaño del portafolio de productos.
– Reducción de las tasas de defectos.
– Calidad de los productos.
 El objetivo principal de una LPS es:

• Reducir el tiempo, esfuerzo, costo y complejidad de

crear y mantener los productos de la línea
mediante:
• La capitalización de los aspectos comunes de la
línea de Productos, a través de la consolidación y
reutilización de los activos de entrada a la línea.
• El manejo de los aspectos variables de los
productos de la línea a través de los puntos de
variación de los activos y los modelos de decisión” .
Un ejemplo: El patrón "Que Construir"
• El Contexto: Una empresa ha decidido crear una línea de
productos de software y conoce bien el dominio de
aplicación de los productos.
• El Problema: Determinar qué productos deberán ser
incluidos en la línea de productos.
• La Solución: Para determinar que productos producir, se
requiere información relacionada con:
– El dominio de aplicación, la tecnología y el mercado.
– La justificación del negocio.
– El proceso para describir el conjunto de productos que serán
incluidos en la línea de productos.
Un ejemplo: El patrón "Que Construir"
•  Análisis del Mercado: Ayuda a entender el mercado que tendrá los
productos de la línea: qué productos tienen mayor demanda, cuál es la
competencia, cuál es el tamaño del mercado y cuales las
oportunidades.
• Entendimiento de dominios relevantes: Proporciona un modelo del
dominio, los requisitos del dominio y los aspectos comunes y variables
a todos los sistemas (aplicaciones) que forman el dominio.
• Proyección tecnológica: Permite predecir que productos que
productos pueden llegar a ser factibles en el futuro cercano.
• Construcción de un caso de negocios: Proporciona una justificación de
la selección de productos y del enfoque se usará para construirlos.
• Definición del alcance (scoping): Describe cuales productos serán
incluidos en la línea de y cuáles no.