Unidad 3 Construccion

8/7/2019 Unidad 3 Construccion

1/42

Unidad 3 Construccion

Desarrollo de proyectos


2/42

3.1 Despliegue de Componentes y Arquitectnico 3.2 Tcnicas 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 Alimentacin 3.2.3 Arquitectura de Referencia para Sistemas Mviles con

Conexin A Internet 3.2.4 Arquitectura de Referencia para Sistemas de Informacin

3.2.5 Arquitectura de Referencia para Ambientes Virtuales deAprendizaje 3.2.6 Arquitecturas de Referencia para Lneas de Productos


3/42

3.1 Despliegue de componentes y

arquitectnico. Qu es UML? UML = Unified Modeling Language

Un lenguaje de propsito general para elmodelado orientado a objetos. Impulsado por elObject Management Group (OMG,www.omg.org)

UML combina notaciones provenientes desde:

Modelado Orientado a Objetos Modelado deDatos Modelado de Componentes Modelado deFlujos de Trabajo (Workflows).


4/42

Modelo

Un modelo captura una vista de un sistemadel mundo real. Es una abstraccin de dichosistema, considerando un cierto propsito.As, el modelo describe completamenteaquellos aspectos del sistema que sonrelevantes al propsito del modelo, y a un

apropiado nivel de detalle.


5/42

Modelo

Un proceso de desarrollo de software debeofrecer un conjunto de modelos que permitanexpresar el producto desde cada una de las

perspectivas de inters El cdigo fuente del sistema es el modelo ms

detallado del sistema (y adems es ejecutable).Sin embargo, se requieren otros modelos.

Cada modelo es completo desde su punto devista del sistema, sin embargo, existen relacionesde trazabilidad entre los diferentes modelos.


6/42

Diagrama

Una representacin grfica de una coleccinde elementos de modelado, a menudodibujada como un grafo con vrticesconectados por arcos


7/42

Componente

Un componente es una parte fsica yreemplazable de un sistema.


8/42

Diagrama de despliegue

Es un tipo de diagrama UML que se utilizapara modelar el hardware utilizado en lasimplementaciones de sistemas y las relaciones

entre sus componentes. Los elementos usados por este tipo de

diagrama son nodos (representados como unprisma), componentes (representados comouna caja rectangular con dos protuberanciasdel lado izquierdo) y asociaciones.


9/42

Ejemplo diagrama de despliegue

Nodo


10/42

Otro ejemplo diagrama de despliegue

Un diagrama de despliegue muestra el desplieguefsico del sistema en un ambiente de produccin (ode prueba). Muestra dnde se ubican loscomponentes, en qu servidores, mquinas o

hardware. Puede representar los enlaces de redes, elancho de banda de la LAN, etc.


11/42

3.2 Tcnicas de desarrollo de las

arquitecturas de referencia en

diferentes dominios.


12/42

3.2.1 Los modelos de componentes

El modelo de componentes ilustra loscomponentes de software que se usarn paraconstruir el sistema. Se pueden construir a partir

del modelo de clases y escribir desde cero para elnuevo sistema o se pueden importar de otrosproyectos y de productos de terceros. Loscomponentes son agregaciones de alto nivel de

las piezas de software ms pequeas y proveenun enfoque de construccin de bloques de cajanegra para la elaboracin de software.


13/42

Notacin de Componentes

Un componente puede ser algo como uncontrol Actives; tanto un componente de lainterfaz de usuario como un servidor de reglasde negocio. Los componentes se representangrficamente como muestra la figurasiguiente:


14/42

Diagrama de componentes

El diagrama de componentes muestra larelacin entre componentes de software, susdependencias, su comunicacin su ubicacin yotras condiciones

Los componentes tambin pueden exponer lasinterfaces. Estas son los puntos visibles deentrada o los servicios que un componenteest ofreciendo y dejando disponibles a otroscomponentes de software y clases.Tpicamente, un componente est compuestopor numerosas clases y paquetes de clasesinternos. Tambin se puede crear a partir deuna coleccin de componentes ms pequeos.


15/42

Requisitos y restricciones Requisitos: Los componentes pueden tener requisitos

adjuntos para indicar sus obligaciones contractuales; estoes, qu servicios proveen en el modelo los requisitosayudan 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 funcin; laspost-condiciones indican lo que debe ser verdaderodespus de que un componente haya realizado algntrabajo y los invariantes especifican lo que debepermanecer verdadero durante la vida del componente


16/42

Escenarios y Trazabilidad

Escenarios: Los escenarios son descripciones textuales yprocedimentales de las acciones de un objeto a lo largo del tiempoy describen la forma en la que un componente trabaja. Se puedencrear mltiples escenarios para describir tanto el camino bsico(una ejecucin perfecta) como las excepciones, errores y otras

condiciones. Trazabilidad: Puede indicar la trazabilidad por medio de vnculos de

realizacin. Un componente puede implementar otro elemento delmodelo (por ejemplo un caso de uso) o un componente puede serimplementado por otro elemento (por ejemplo un paquete declases). Al emplear las relaciones de realizacin desde y hacia los

componentes, se pueden seguir las dependencias entre loselementos del modelo y la trazabilidad desde los requisitos incialeshasta la implementacin final.


17/42

Ejemplo

El ejemplo siguiente muestra cmo se puedenrelacionar los componentes para proveer unavista conceptual/lgica de la construccin deun sistema. Este ejemplo representa loselementos del servidor y la seguridad de unatienda de libros en lnea. Se incluyen

elementos tales como el servidor WEB, elfirewall, las pginas ASP, etc.


18/42


19/42

Diagrama componentes del servidor


20/42

Componentes de seguridad

El diagrama de componentes de la seguridadmuestra cmo trabaja en conjunto el softwarede seguridad, tal como la AutoridadCertificadora (Certificate Authority), elnavegador (Browser), el servidor WEB y otroselementos del modelo para asegurar la

provisin de la seguridad en el sistemapropuesto


21/42

Diagrama componentes de seguridad


22/42

3.2.2 Arquitectura de referencia para sistemas

de tiempo real fuente de alimentacin 1/4

La adopcin de Modelos Orientados a Servicios constituyeun cambio de paradigma fundamental, que permitiraumentar el dinamismo y competitividad de la sociedadactual transformndola 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 provisin de servicios electrnicosproporcionados desde la red en modo utilities (siempredisponibles, en cualquier lugar). Los procesos, tantoprocesos de negocio realizados por empresas comoprocesos llevados a cabo por individuos o colectivos en suvida diaria, se definan a partir de servicios de una manerams gil y flexible, totalmente adaptada al contexto.


23/42



Este cambio de paradigma conducir a unamejora significativa en la vida diaria de negocios,ciudadanos y colectivos. Permitir a las empresas alcanzar los niveles ms altos

de innovacin y excelencia en operaciones Mejor time to market Tambin permitir a individuos y colectivos alcanzar

los niveles ms altos de productividad, satisfaccin y

bienestar. PYMES) o incluso individuos que no tendrnque limitarse a ser simples consumidores, sino quepodrn jugar el papel de proveedores de servicios,contenidos


24/42

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, aprendiendojuntos y acelerando la incorporacin como la mejorade la productividad

La interaccin debe adaptarse y ser relevante alcontexto de manera que comprenda elementos talescomo el contexto del usuario (conocimiento, perfil,preferencias, idiomas, informacin sobre las redessociales, etc.)




25/42



En el mbito de Internet, adems de estos principios,es necesaria la creacin de un ecosistema de negociosostenible para todos los implicados en la cadena devalor de los servicios.

Definir tecnologas que den soporte al concepto demarketplace, donde diversos modelos de negociofiables, innovadores y flexibles puedan ponerse enprctica, involucrando a los clientes/usuarios finales, alos proveedores que publican recursos, a los

distribuidores que finalmente hacen que estos recursossean accesibles, a los posibles anunciantes que deseanacceder a los clientes/usuarios finales.


26/42


27/42


mviles con conexin a Internet. 1/3

La rpida evolucin de la sociedad de informacinglobalizada, est siendo fomentada por un incrementode la demanda, para unificar servicios integrados debanda ancha. Los clientes estn siendo mayoresdemandantes en trminos de habilitacin de serviciosy rendimiento de la red.

El desafo es proveer un amplio conjunto de opcionesen trminos de servicio, terminales y accesos de red, lo

que es posible de hacer frente con diferentesrequerimientos y proporcionando flexibilidad,modularidad y capacidad de crecimiento.


28/42



Como se muestra en la Figura 1, un nuevo sistema llamadoradio banda ancha (broadband radio) proveer de una grancapacidad alcanzada por:

Sistema de distribucin multipunto local (LMDS: local multipointdistribution systems)

Sistema de multimedia satelital de banda ancha (BSM: broadbandsatellite multimedia)

Sistema de banda ancha mvil (MBS: mobile broadband systems)


29/42

A los usuarios se les deber permitir moverse entrediferentes segmentos. Ha comenzado a ser una necesidadla gestin de servicios comn, recurso de redes y clientela,que cubra los segmentos mviles y fijos. Esto necesita una

fuerte concentracin en la integracin de redes para elcontinuo desarrollo de procesos.

Es comnmente aceptado que el suministro de servicioscomo la TV interactiva, Internet, educacin a distancia yservicios avanzados de oficina en casa, son necesarios para

el desarrollo y crecimiento. El desarrollo de un sistema deacceso de radio de banda ancha milimtrico de bajo costopara usuarios fijos y nmades, ayudar a asegurar a quemuchos usuarios accedan a este servicio.




30/42

3.2.4 Arquitectura de referencia para

sistemas de informacin 1/2 La decisin de abordar un estudio en profundidad para definir la

Arquitectura de los Sistemas de Informacin, parte de la necesidad deconseguir unos objetivos de carcter general, que pueden resumirse en lossiguientes puntos: Alineamiento de la ptica de negocio con la estructura de los Sistemas de

Informacin. Disponer de un modelo integral que abarque todas las aplicaciones y sistemas

informticos. 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 Informticos

Posibilitar la incorporacin de las tecnologas emergentes de forma eficaz. Favorecer la mejora de la calidad profesional y de la gestin interna. Reducir los costes y el plazo de disponibilidad de las aplicaciones.


31/42


sistemas de informacin 2/2 Al trmino del Estudio se dispondr de los siguientes resultados:

Identificacin de los Requerimientos Estratgicos de negocio, desde la ptica de los Sistemas deInformacin.

Modelos estructurados y documentados sobre las Arquitecturas: Funcional

Datos

Sistemas

reas complementarias seleccionadas

Identificacin de los diferentes Sistemas de Informacin utilizados,

Reglas de diseo para implantar nuevas tendencias tecnolgicas.

Reglas de diseo para la estructuracin 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 diseados para enfocar la implantacin de la

Arquitectura. Un soporte informtico conteniendo los modelos, cara al enlace con el desarrollo de los proyectos.

Un diseo previo, no detallado, de cada Sistema,

Modelo organizativo para la funcin de Administracin de la Arquitectura

Un Plan Director, especificando la estrategia recomendada para la evolucin de los Sistemas.


32/42


ambientes virtuales de aprendizaje. 1/2

Un Ambiente Virtual de Aprendizaje es el conjunto deentornos de interaccin, sincrnica y asincrnica,donde, con base en un programa curricular, se lleva acabo el proceso enseanza aprendizaje, a travs de un

sistema de administracin de aprendizaje. La propuesta metodolgica para operar los modelos

educativos innovadores es la de Ambientes Virtualesde Aprendizaje (AVA), ya que crear un ambiente deeste tipo no es trasladar la docencia de un aula fsica a

una virtual, ni cambiar el gis y el pizarrn por un medioelectrnico, o concentrar el contenido de unaasignatura, en un texto que se lee en el monitor de lacomputadora.


33/42


ambientes virtuales de aprendizaje. 2/2

Se requiere que quienes participan en el diseode estos ambientes deben conocer todos losrecursos tecnolgicos disponibles(infraestructura, medios, recursos deinformacin, etc.), as como las ventajas ylimitaciones de stos para poder relacionarloscon los objetivos, los contenidos, las estrategias yactividades de aprendizaje y la evaluacin.

Los entornos en los cuales opera un AVA son: Conocimiento Colaboracin Asesora Experimentacin Gestin


34/42

Elementos de un ambiente virtual deaprendizaje

Usuarios. Se refiere al QUIN va a aprender, a desarrollarcompetencias, a generar habilidades, es decir principalmenteestudiantes y facilitadores.

Currcula. Es el QU se va a aprender. Son los contenidos, elsustento, los programas de estudio curriculares y cursos de

formacin. Especialistas. Aqu est el CMO se va a aprender. Son los

encargados de disear, desarrollar y materializar todos loscontenidos educativos que se utilizarn en el AVA. Se integra por ungrupo multidisciplinario que consta de: Pedagogo. Administrador Diseador grafico. Programador. Especialista en tecnologa educativa. Corrector de estilo.


35/42

Fases de creacin de un ambientevirtual de aprendizaje.

Fase I. Planeacin.

Fase II. Diseo, desarrollo de los entornos y la

produccin de los contenidos digitales. Fase III. Operacin.


36/42


lneas de productos.

Definiciones de Lneas de Productos de Software

Consiste de una familia de sistemas de software quetienen una funcionalidad comn y alguna

funcionalidad variable . La funcionalidad comn descansa en el uso recurrente de

un conjunto comn de activos reutilizables (requisitos,diseos, componentes, servicios web, etc.).

Los activos son reutilizados por todos los miembros de lafamilia.


37/42

Modelo Bsico de una Lnea de

Productos de Software (LPS)


38/42

Modelo Bsico de una Lnea de

Productos de Software (LPS) La entrada: Activos de Software. Una coleccin de partes de

software (requisitos, diseos, componentes, casos de prueba, etc.)que se configuran y componen de una manera prescrita paraproducir los productos de la lnea.

El control: Modelos de Decisin y Decisiones de Productos. Los

Modelos de Decisiones describen los aspectos variables yopcionales de los productos de la lnea. Cada producto de la lnea esdefinido por un conjunto de decisiones (decisiones del producto).

El proceso de produccin. Establece los mecanismos o pasos paracomponer 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 variacin de esosactivos. La salida: Productos de software. Conjunto de todos los productos

que pueden o son producidos por la lnea de Productos.


39/42

Lneas de productos de software

La entrega de productos de software busca unamanera: Ms rpida. Econmica. Con una mejor calidad.

Las lneas de produccin producen mejoras en: Tiempo de entrega del producto (time to market). Costos de ingeniera. Tamao del portafolio de productos. Reduccin de las tasas de defectos. Calidad de los productos.


40/42

El objetivo principal de una LPS es:

Reducir el tiempo, esfuerzo, costo y complejidadde crear y mantener los productos de la lneamediante:

La capitalizacin de los aspectos comunes de lalnea de Productos, a travs de la consolidacin yreutilizacin de los activos de entrada a la lnea.

El manejo de los aspectos variables de los

productos de la lnea a travs de los puntos devariacin de los activos y los modelos dedecisin .


41/42

Un ejemplo: El patrn "Que

Construir"

El Contexto: Una empresa ha decidido crear una lneade productos de software y conoce bien el dominio deaplicacin de los productos.

E

l Problema: Determinar qu productos debern serincluidos en la lnea de productos.

La Solucin: Para determinar que productos producir,se requiere informacin relacionada con: El dominio de aplicacin, la tecnologa y el mercado.

La justificacin del negocio.

El proceso para describir el conjunto de productos quesern incluidos en la lnea de productos.


42/42

Un ejemplo: El patrn "Que

Construir" Anlisis del Mercado: Ayuda a entender el mercado que tendr los

productos de la lnea: qu productos tienen mayor demanda, cules la competencia, cul es el tamao del mercado y cuales lasoportunidades.

Entendimiento de dominios relevantes: Proporciona un modelo del

dominio, los requisitos del dominio y los aspectos comunes yvariables a todos los sistemas (aplicaciones) que forman el dominio. Proyeccin tecnolgica: Permite predecir que productos que

productos pueden llegar a ser factibles en el futuro cercano. Construccin de un caso de negocios: Proporciona una justificacin

de la seleccin de productos y del enfoque se usar para

construirlos. Definicin del alcance (scoping): Describe cuales productos sern

incluidos en la lnea de y cules no.

Unidad 3 Construccion

Documents

Transcript of Unidad 3 Construccion