Desarrollo de Aplicaciones basado en Componentes y Frameworks
Antonio VallecilloAntonio VallecilloGISUM: Grupo de Ingeniería del Software de la Universidad de MálagaGISUM: Grupo de Ingeniería del Software de la Universidad de Málaga
Departamento de Lenguajes y Ciencias de la ComputaciónDepartamento de Lenguajes y Ciencias de la Computación
Universidad de Málaga. EspañaUniversidad de Málaga. España
[email protected]@lcc.uma.es
Raúl MongeRaúl MongeDepartamento de InformáticaDepartamento de Informática
Universidad Técnica Federico Santa María. ChileUniversidad Técnica Federico Santa María. Chile
[email protected]@inf.utfsm.l
2
Contenido Global del Curso:
Arquitecturas de SoftwareArquitecturas de Software Marcos de Trabajo (Frameworks)Marcos de Trabajo (Frameworks) Programación orientada a ComponentesProgramación orientada a Componentes
Antonio VallecilloAntonio VallecilloGISUM: Grupo de Ingeniería del Software GISUM: Grupo de Ingeniería del Software
de la Universidad de Málagade la Universidad de Málaga
Departamento de Lenguajes y Ciencias de la ComputaciónDepartamento de Lenguajes y Ciencias de la Computación
Universidad de Málaga. EspañaUniversidad de Málaga. España
[email protected]@lcc.uma.es
1ª Parte:Arquitecturas del Software
4
Contenido
Estilos ArquitectónicosEstilos Arquitectónicos Lenguajes de Descripción de ArquitecturasLenguajes de Descripción de Arquitecturas Programación Orientada a ComponentesProgramación Orientada a Componentes
5
Introducción
Sistemas Abiertos Sistemas Abiertos Características y ProblemáticaCaracterísticas y Problemática
Estilos ArquitectónicosEstilos Arquitectónicos Lenguajes de Descripción de arquitecturasLenguajes de Descripción de arquitecturas Ingeniería del Software basada en Ingeniería del Software basada en
Componentes (CBSE)Componentes (CBSE) Arquitectura Software y COTSArquitectura Software y COTS
6
Sistemas Abiertos
ConcurrentesConcurrentes ReactivosReactivos Independientemente extensiblesIndependientemente extensibles HeterogéneosHeterogéneos EvolutivosEvolutivos DistribuidosDistribuidos
7
Problemas específicos
Gestión de la evolución (del sistema y de Gestión de la evolución (del sistema y de sus componentes)sus componentes)
Compatibilidad de componentesCompatibilidad de componentes Falta de visión global del sistemaFalta de visión global del sistema Dificultad para garantizar la seguridadDificultad para garantizar la seguridad Retrasos y errores en las comunicacionesRetrasos y errores en las comunicaciones Fallos y errores en los propios componentesFallos y errores en los propios componentes
8
Arquitectura del Software
Estructura de los componentes de un programa o Estructura de los componentes de un programa o sistema, sus interrelaciones, y los principios y reglas sistema, sus interrelaciones, y los principios y reglas que gobiernan su diseño y evolución en el tiempo.que gobiernan su diseño y evolución en el tiempo.
(Garlan y Perry, 1995)(Garlan y Perry, 1995)
Estructura o estructuras de un sistema, lo que Estructura o estructuras de un sistema, lo que incluye sus componentes software, las propiedades incluye sus componentes software, las propiedades observables de dichos componentes y las relaciones observables de dichos componentes y las relaciones entre ellos.entre ellos.
(Bass, Clements y Kazman, 1998)(Bass, Clements y Kazman, 1998)AS
9
Disciplina Nivel del diseño del software donde se definen la Nivel del diseño del software donde se definen la
estructura y propiedades globales del sistema.estructura y propiedades globales del sistema.(Garlan y Perry, 1995)(Garlan y Perry, 1995)
La La Arquitectura del SoftwareArquitectura del Software se centra en se centra en aquellos aspectos del diseño y desarrollo que no aquellos aspectos del diseño y desarrollo que no pueden tratarse de forma adecuada dentro de los pueden tratarse de forma adecuada dentro de los módulos que forman el sistemamódulos que forman el sistema..
(Shaw y Garlan, 1996)(Shaw y Garlan, 1996)
10
Caracterización
Arquitectura Arquitectura vs. vs. Algoritmos + DatosAlgoritmos + Datos organización del sistemaorganización del sistema
Interacción de componentes Interacción de componentes vs.vs. Definición/uso Definición/uso componentes y conectorescomponentes y conectores
Estilo Arquitectónico Estilo Arquitectónico vs.vs. Instancia Instancia restricciones en la forma de una familia de restricciones en la forma de una familia de
instanciasinstancias Arquitectura Arquitectura vs.vs. Métodos de Diseño Métodos de Diseño
espacio de diseños arquitectónicosespacio de diseños arquitectónicos
11
Descripción de una AS
Representación de alto nivel de la estructura Representación de alto nivel de la estructura de un sistema o aplicación, que describe:de un sistema o aplicación, que describe: partes que la integran,partes que la integran, interacciones entre ellas,interacciones entre ellas, patrones que supervisan su composición, patrones que supervisan su composición,
yy restricciones para aplicar dichos patrones.restricciones para aplicar dichos patrones.
12
EmisorEmisor
ReceptorReceptorBufferBuffer
Arquitectura Productor/Consumidor
13
Objetivos de la AS
Comprender y manejar la estructura de las Comprender y manejar la estructura de las aplicaciones complejasaplicaciones complejas
Reutilizar dicha estructura (o parte de ella)Reutilizar dicha estructura (o parte de ella) Planificar la evolución de la aplicaciónPlanificar la evolución de la aplicación Analizar la corrección de la aplicación y su Analizar la corrección de la aplicación y su
grado de cumplimiento frente a los grado de cumplimiento frente a los requisitos inicialesrequisitos iniciales
Permitir el estudio de propiedades Permitir el estudio de propiedades específicasespecíficas
14
Ventajas de las A.S.
Resaltan aquellos aspectos estucturalmente Resaltan aquellos aspectos estucturalmente importantes, tanto funcionales como no importantes, tanto funcionales como no funcionalesfuncionales
Eliminan muchos riesgos y errores de Eliminan muchos riesgos y errores de diseño, desarrollo e implantacióndiseño, desarrollo e implantación
Permiten un desarrollo paralelo, Permiten un desarrollo paralelo, aumentando la productividadaumentando la productividad
15
El “territorio” de las AS
Adaptado de P. Kruchten, B. Selic, W. Kozaczynski. “Describing Software Architecture with UML”, 2001
16
Modelo, Vista y Punto de Vista
Modelo (Modelo (modelmodel)) Una descripción completa de un sistema a un Una descripción completa de un sistema a un
determinado nivel de abstraccióndeterminado nivel de abstracción
Vista (Vista (viewview)) Una proyección de un modelo desde una perspectivaUna proyección de un modelo desde una perspectiva Omite las entidades y elementos que no son relevantesOmite las entidades y elementos que no son relevantes
Punto de vista (Punto de vista (viewpointviewpoint)) La definición (o descripción) de una vistaLa definición (o descripción) de una vista Prescribe su contenido, significado y representaciónPrescribe su contenido, significado y representación
17
Niveles de Abstracción Estilos arquitectónicosEstilos arquitectónicos
familias de sistemas que siguen el mismo patrón estructuralfamilias de sistemas que siguen el mismo patrón estructural
Modelos y arquitecturas de referenciaModelos y arquitecturas de referencia particularizan un estilo y definen los conceptos asociadosparticularizan un estilo y definen los conceptos asociados
Marcos de TrabajoMarcos de Trabajo arquitectura reutilizable en aplicaciones de un mismo dominioarquitectura reutilizable en aplicaciones de un mismo dominio
Familias y líneas de productosFamilias y líneas de productos arquitectura de una aplicación con diferentes configuracionesarquitectura de una aplicación con diferentes configuraciones
InstanciasInstancias arquitectura de una aplicación concretaarquitectura de una aplicación concreta
18
Estilos Arquitectónicos ComponentesComponentes
unidades computacionales y de datosunidades computacionales y de datos ConectoresConectores
mecanismos de interacción entre componentesmecanismos de interacción entre componentes Patrones y restricciones de interconexiónPatrones y restricciones de interconexión
invariantes del estiloinvariantes del estilo Mecanismos de controlMecanismos de control
coordinación entre componentescoordinación entre componentes PropiedadesPropiedades
ventajas e inconvenientesventajas e inconvenientes
19
Clasificación de estilos
Sistemas de flujo de datosSistemas de flujo de datos Sistemas basados en llamada y retornoSistemas basados en llamada y retorno Sistemas de componentes independientesSistemas de componentes independientes Sistemas centrados en los datosSistemas centrados en los datos Máquinas virtualesMáquinas virtuales Sistemas heterogéneosSistemas heterogéneos
20
Estilos y subestilos (I) Sistemas de flujo de datosSistemas de flujo de datos
Sucesión de transformaciones de los datos de entradaSucesión de transformaciones de los datos de entrada Subestilos: pipe & filter y procesamiento por lotesSubestilos: pipe & filter y procesamiento por lotes
Sistemas basados en llamada y retornoSistemas basados en llamada y retornoReflejan la estructura del lenguaje de programaciónReflejan la estructura del lenguaje de programación Subestilos: programa principal-subrutina, OO, capasSubestilos: programa principal-subrutina, OO, capas
Sistemas de componentes independientesSistemas de componentes independientesComponentes distribuidos que se comunican por paso de mensajesComponentes distribuidos que se comunican por paso de mensajes Subestilos: sistemas cliente/servidor y de eventosSubestilos: sistemas cliente/servidor y de eventos
21
Estilos y subestilos (II) Sistemas centrados en los datosSistemas centrados en los datos
Acceso compartido a un banco de datos centralAcceso compartido a un banco de datos central Subestilos: repositorio y pizarras (blackboards)Subestilos: repositorio y pizarras (blackboards)
Máquinas virtualesMáquinas virtualesSimulan una funcionalidad no nativa del entornoSimulan una funcionalidad no nativa del entorno Subestilos: intérpretes y sistemas basados en reglasSubestilos: intérpretes y sistemas basados en reglas
Sistemas heterogéneosSistemas heterogéneosLocalmente, jerárquicamente o simultáneamente heterogéneosLocalmente, jerárquicamente o simultáneamente heterogéneos
22
Descripción de Arquitecturas Diagramas informales de cajas y líneasDiagramas informales de cajas y líneas
• Imprecisos, ambiguos y no analizablesImprecisos, ambiguos y no analizables Lenguajes de programación modularLenguajes de programación modular
• Mezclan aspectos de programación y estructuralesMezclan aspectos de programación y estructurales• El análisis se basa en emparejamiento de nombresEl análisis se basa en emparejamiento de nombres
Lenguajes de interconexión de módulos (MILs o IDLs)Lenguajes de interconexión de módulos (MILs o IDLs)• Implican un determinado mecanismo de interacciónImplican un determinado mecanismo de interacción
UML como notación arquitectónicaUML como notación arquitectónica Lenguajes de Descripción de Arquitectura (LDAs)Lenguajes de Descripción de Arquitectura (LDAs)
23
Lenguajes de Descripción de Arquitecturas (LDAs)
Un LDA es un lenguaje o notación para Un LDA es un lenguaje o notación para describir una arquitectura software:describir una arquitectura software: Descripción de componentes, conectores y Descripción de componentes, conectores y
enlaces entre ellos.enlaces entre ellos. Herramientas para la verificación de la Herramientas para la verificación de la
arquitectura y el prototipado rápido.arquitectura y el prototipado rápido. Existen LDAs de propósito general y otros de Existen LDAs de propósito general y otros de
dominio específico (DSLs)dominio específico (DSLs)
24
SenderSender
ReceiverReceiverBufferBuffer
Arquitectura Productor/Consumidor
Enlaces puertos/roles ¿ analizables ?
Puertos: describen el comportamiento de las componentes
wri
ter
stor
age
readerretrieval
Roles: describen el comportamiento
de los conectores
25
Requisitos de un ADL
ComposiciónComposición Debe describir el sistema como una composición de partesDebe describir el sistema como una composición de partes
ConfiguraciónConfiguración Debe describir la arquitectura independientemente de los componentesDebe describir la arquitectura independientemente de los componentes
AbstracciónAbstracción Debe describir los roles abstractos que juegan los componentesDebe describir los roles abstractos que juegan los componentes
ReutilizaciónReutilización Debe permitir reutilizar componentes, conectores, y arquitecturasDebe permitir reutilizar componentes, conectores, y arquitecturas
HeterogeneidadHeterogeneidad Debe permitir combinar descripciones heterogéneasDebe permitir combinar descripciones heterogéneas
AnálisisAnálisis Debe permitir diversas formas de análisis de la arquitectura Debe permitir diversas formas de análisis de la arquitectura
26
Ejemplos de LDAs EjemplosEjemplos::
UNICON (Shaw et al. 1995)UNICON (Shaw et al. 1995) Rapide (Luckham et al. 1995)Rapide (Luckham et al. 1995) Darwin (Magee y Kramer, 1996; 1999)Darwin (Magee y Kramer, 1996; 1999) Wright (Allen y Garlan, 1997; 1998)Wright (Allen y Garlan, 1997; 1998) Executable Connectors (Ducasse y Richner, 1997)Executable Connectors (Ducasse y Richner, 1997)
ProblemaProblema: No cubren todo el ciclo de vida de las : No cubren todo el ciclo de vida de las aplicaciones software (sólo diseño preliminar), no aplicaciones software (sólo diseño preliminar), no llegan a la implementaciónllegan a la implementación
27
Ejemplos de LDAs : UNICON
Una Una pipepipe de Unix de Unix
connectorconnector Unix-pipe Unix-pipe protocolprotocol isis typetype pipe pipe rolerole source source isis Source Source MaxConns(1)MaxConns(1) end end sourcesource rolerole sink sink isis Sink Sink MaxConns(1)MaxConns(1) endend sink sink end protocolend protocol
......
implementation isimplementation is
builtinbuiltin
end implementationend implementation
endend Unix-Pipe Unix-Pipe
28
Ejemplos de LDAs : Wright Una Una pipepipe de Unix de Unixconnectorconnector Pipe = Pipe =
rolerole WRITER = write WRITER = write WRITER WRITER close close rolerole READER = READER = letlet ExitOnly = close ExitOnly = close
inin letlet DoRead = (read DoRead = (read READER READER □ readEoF □ readEoF ExitOnly ExitOnly
inin DoRead DoRead ExitOnly ExitOnly
glueglue = = letlet ReadOnly = READER.read ReadOnly = READER.read readOnly readOnly
□ □ READER.readEoF READER.readEoF READER.close READER.close □ □ READER.close READER.close
inin letlet WriteOnly = WRITER.write WriteOnly = WRITER.write WriteOnly WriteOnly □ □ WRITER.closeWRITER.close
inin WRITER.write WRITER.write glueglue □ READER.read □ READER.read glueglue
□ □ WRITE.close WRITE.close ReadOnly ReadOnly □ READER.close □ READER.close WriteOnly WriteOnly
29
Ejemplos de LDAs : RAPIDEtype type Application Application is interfaceis interface extern actionextern action Receive(p:params); // evento de entrada Receive(p:params); // evento de entrada public actionpublic action Results(p:params); // evento de salida Results(p:params); // evento de salidabehaviourbehaviour (?M (?M in Stringin String) Receive(?M) => Results(?M); // transición de eventos) Receive(?M) => Results(?M); // transición de eventosend Application;end Application;
architecture architecture DistrApp(Num: Integer) DistrApp(Num: Integer) returnreturn InterfaceDistrApp InterfaceDistrApp isis P : P : arrayarray(Integer) (Integer) ofof Application; Application; Q: Q: arrayarray(Integer) (Integer) ofof Resource; //Dual of Application Resource; //Dual of Applicationconnectconnect forfor i:Integer i:Integer inin 1..Num 1..Num generategenerate (?M (?M in Stringin String) P(i). Receive(?M) to Q(i).Results(?M);) P(i). Receive(?M) to Q(i).Results(?M); P(i).Results(?M) to Q(i). Receive(?M);P(i).Results(?M) to Q(i). Receive(?M); end generate;end generate;end end DistrAppDistrApp;;
30
Ejemplos de LDAs : Darwin
entrada
cabeza : Filtro
ant
salida
salida
: Pipeline
entrada
salida
cauce : Pipeline
sig
31
LDAs del grupo GISUM LDC + LDS (Fuentes y Troya, 1998)LDC + LDS (Fuentes y Troya, 1998)
Modelo de componentes pasivos y conectores Modelo de componentes pasivos y conectores reactivosreactivos
Formalismo de especificación de comportamiento de Formalismo de especificación de comportamiento de conectores (TDFs, conectores (TDFs, -cálculo, etc.)-cálculo, etc.)
LEDA (Canal, Pimentel y Troya, 2000)LEDA (Canal, Pimentel y Troya, 2000) Basado en el álgebra de procesos Basado en el álgebra de procesos -cálculo-cálculo Permite especificar arquitecturas dinámicasPermite especificar arquitecturas dinámicas
32
LDC: Componentes
Propagación de eventosPropagación de eventos InterfazInterfaz
Componente: Tipo
Método()----->
Atributos
Tipo
Atributos
Mensajes + eventos
Lenguajes de especificación de servicios
33
LDC: Componentes
def component DoM(fich:”String”)propagateslistMovies(list-movies=”List”)
endinterface is
type Filefich:”String”getlistMovies(category=”String”)
throws listMovies(list-movies=”List”)end
enddef DoM
Lenguajes de especificación de servicios
34
LDC: Conectores ParametrizaciónParametrización
Componentes participantesComponentes participantes
Relación de uso
Gestión de eventos
Conectorcomponente,
set(componente)
Protocolo Tipo ASTM Protocolo en TDF
Lenguajes de especificación de servicios
35
LDC: Conectores
def connector MSelector(newphase:component)handleslistMovies(list-movies=”List”),service(movie=”String”)service(category-movie=”Command”)
endmessagesDoM.getlistMovies(category=”String”)Participant.initService(panel=”DoMpanel”)Participant.displayService(data=”List”)Participant.service(command=”Command”)
endprotocol istype Servicestd(SDL) {...}
endenddef MSelector
Lenguajes de especificación de servicios
36
LDS: Conexiones
ConexionesConexiones En base a eventosEn base a eventos Instanciación de la relación de usoInstanciación de la relación de uso
Lenguajes de especificación de servicios
Renombrar métodos y
eventos
Adaptar componentes Adaptar componentes a conectoresa conectores
37
LDS: Conexiones
(scaccess1 : SCAccess(nombre))scaccess1[acdb] to participant with {access(params), join}
acdb with {subscribed,non-subscribed};
subscribed,non-subscribed
Participant
getAccessParams() -->joinResponse()join() ------------------->
SCAccessACDB: File
<--------- checkAccess()
join
access(params)
Lenguajes de especificación de servicios
participant acdbscaccess1
38
LCF
Organización de servicios genéricosOrganización de servicios genéricos Servicio de organización comúnServicio de organización común
readLocation() --------> close()
ConfiguratedDataBase: File
readParameter() ------>
ConfiguratedService: File
addFile()
addParties()
addLocation()
addParameter()
close()
Organización
VoD genérico VoD versión1
Lenguajes de especificación de servicios
39
LCF
Asignación de nombres lógicos a físicos
set msap <url>set movie remoteset participant local
Configuración de parámetros globales
put text “Fich.clientes” parname acdb::acdbfich value=””
Clases de componentes y conectores
put text “Tipo acceso” implementation scaccess value=””
set parties unicast
Tipo de servicio
Lenguajes de especificación de servicios
40
Un ejemplo en LEDA (I)component Buffer{
interfacestorage : Storage;retrieval :
Retrieval;}
role Storage(put) { spec is
put?(x).Storage(put)}
role Retrieval(get) { spec is
get?(item,empty). . (x) item!(x). Retrieval(get)
+ . empty!(). Retrieval(get);
}
41
Un ejemplo en LEDA (II)component Sender{
interfacewriter : Writer;
}
role Writer(write) { spec is
(data) write!(data). Writer(write);}
role Reader(read){ spec is
(return,empty) read!(return,empty). ( return?(item).Reader(read) + empty?().Reader(read) );
}
component Receiver{
interfacereader : Reader;
}
42
Un ejemplo en LEDA (III)component ProducerConsumer{ interface
...composition
p: Sender;c: Receiver;b: Buffer;
attachmentsp.writer(write) <> b.storage(write);b.retrieval(read) <> c.reader(read);
}
43
LDS
Parámetros globalesParámetros globales
Componentessimplesconjuntolista de tipos
componentschair : Manager(name)audience : set(Participant) ===>
item(audience)devices : {TextualChat,FileMovie}
end
Configuración con LCF
Lenguajes de especificación de servicios
44
Comparación de LDAs
EntidadesEntidades DinamismoDinamismo Verificación Verificación PropiedadesPropiedades
DesarrolloDesarrolloReutilizacReutilizac..
EjecuciónEjecución
UniConUniCon Comp/ConComp/Con NoNo NoNo NoNo Gen.Cod.Gen.Cod.
WrightWright Comp/ConComp/Con NoNo Compat.Compat. NoNo NoNo
DarwinDarwin CompComp SíSí Seg./VivezaSeg./Viveza NoNo Gen.Cod.Gen.Cod.
RapideRapide CompComp LimitadoLimitado Análisis Análisis RestriccionesRestricciones
HerenciaHerencia Simul./Simul./
Gen.Cod.Gen.Cod.
LDSLDS Comp/ConComp/Con SíSí PosiblePosible ExtensiónExtensión Gen.Cod.Gen.Cod.
LEDALEDA CompComp SíSí Compat./Ext.Compat./Ext. Ext./Gener.Ext./Gener. Simul./ Simul./ Gen.Cod.Gen.Cod.
45
Arquitectura Software vs. COTS Arquitectura del SoftwareArquitectura del Software
Orientados a la reutilización independiente de Orientados a la reutilización independiente de patrones arquitectónicos y de componentespatrones arquitectónicos y de componentes
Modelos formalesModelos formales Tecnología desarrollada en el entorno académicoTecnología desarrollada en el entorno académico
COTSCOTS Componentes con interfaces estándares (IDLs)Componentes con interfaces estándares (IDLs) No aparece la noción de conector o “enchufe”No aparece la noción de conector o “enchufe” Mercado global de componentes centrado en la Mercado global de componentes centrado en la
reutilización de componentesreutilización de componentes Tecnología madura: OpenDoc/CORBA, OLE/COMTecnología madura: OpenDoc/CORBA, OLE/COM
46
Ingeniería del Software basada en Componentes Componentes unidos a una arquitecturaComponentes unidos a una arquitectura Partes de la interfaz de un componente para soportar Partes de la interfaz de un componente para soportar
la noción de arquitectura:la noción de arquitectura: Tiempo de ComposiciónTiempo de Composición
Elementos para generar una aplicación a partir de Elementos para generar una aplicación a partir de COTSCOTS
Tiempo de DiseñoTiempo de Diseño Interfaces funcionales y dependencias de componentesInterfaces funcionales y dependencias de componentes
Tiempo de EjecuciónTiempo de Ejecución Servicios de composición dinámica en Servicios de composición dinámica en runtimeruntime
47
AS: problemas y líneas abiertas
1.1. Definición de ASDefinición de AS
2.2. Expresión de parámetros de calidadExpresión de parámetros de calidad
3.3. MedidasMedidas
4.4. HerramientasHerramientas
5.5. Relación con el dominio de aplicaciónRelación con el dominio de aplicación
6.6. ‘‘Vistas’ arquitectónicasVistas’ arquitectónicas
48
P1. Definición de AS
Una AS es Una AS es algo másalgo más que una descripción que una descripción de la estructura de una aplicaciónde la estructura de una aplicación ¿Qué es ese algo más?¿Qué es ese algo más? ¿Cómo se expresa?¿Cómo se expresa?
Otras definiciones alternativas de AS: Otras definiciones alternativas de AS: “ “A Software Architecture is a collection of categories of A Software Architecture is a collection of categories of
elements that share the same likelihood of change. Each elements that share the same likelihood of change. Each category contains software elements that exhibit shared category contains software elements that exhibit shared stability characteristics”stability characteristics”
49
P2. Parámetros de Calidad
Actualmente no se tienen en cuenta.Actualmente no se tienen en cuenta. ““...ilities”: ...ilities”: portabilityportability, , traceabilitytraceability,...,... ““...nesses”: ...nesses”: correcnesscorrecness, , robustnessrobustness, ..., ...
Propios del tiempo de ejecución (dinámicos):Propios del tiempo de ejecución (dinámicos): PerformancePerformance, , securitysecurity, , availabilityavailability, , functionalityfunctionality, ,
usability, usability, etc.etc.
Intrínsecos a la AS (estáticos):Intrínsecos a la AS (estáticos): ModifiabilityModifiability, , portabilityportability, , reusabilityreusability, , integrabilityintegrability, ,
testability, testability, etc.etc.
50
P3. Medidas
Necesarias para poder hablar de Ingeniería del Necesarias para poder hablar de Ingeniería del SoftwareSoftware
Deberían estimar, de forma cuantitativa:Deberían estimar, de forma cuantitativa: TamañoTamaño EstructuraEstructura Calidad del diseñoCalidad del diseño ......
Funcionales (estructuradas)/Orientadas a ObjetoFuncionales (estructuradas)/Orientadas a Objeto
51
P4. Herramientas
DiseñoDiseño DocumentaciónDocumentación PruebasPruebas Análisis de propiedades (formales)Análisis de propiedades (formales) Generación de código/prototiposGeneración de código/prototipos
52
P5. Dominio de Aplicación
Análisis de los dominios de la Análisis de los dominios de la aplicación y de la solución para aplicación y de la solución para derivar AS:derivar AS: Mejor y más estable estructuraMejor y más estable estructura Mejor capacidad de evoluciónMejor capacidad de evolución AS solución más natural e integrada en AS solución más natural e integrada en
el entorno de la aplicación el entorno de la aplicación
53
P6. “Vistas” Arquitectónicas
Varias “vistas” arquitectónicasVarias “vistas” arquitectónicasAlgunas técnicas, otras específicas del Algunas técnicas, otras específicas del
dominio, otras tecnológicasdominio, otras tecnológicasRM-ODP o TINA ya las definenRM-ODP o TINA ya las definenProblemas: consistencia e integraciónProblemas: consistencia e integración
54
Bibliografía P. Clements (1996), P. Clements (1996), Coming Attractions in Software ArchitectureComing Attractions in Software Architecture, Technical , Technical
Report, Software Engineering Institute, Carnegie Mellon University (USA).Report, Software Engineering Institute, Carnegie Mellon University (USA).
P. Donohoe (Ed.) (1999), P. Donohoe (Ed.) (1999), Software ArchitectureSoftware Architecture, Kluwer Academic , Kluwer Academic Publishers.Publishers.
D. Garlan y D. E. Perry (1995), Introduction to the Special Issue on Software D. Garlan y D. E. Perry (1995), Introduction to the Special Issue on Software Architecture, Architecture, IEEE Transactions on Software EngineeringIEEE Transactions on Software Engineering, 21(4):269–274., 21(4):269–274.
D. Garlan, R. Allen y J. Ockerbloom (1995), Architectural Mismatch: Why D. Garlan, R. Allen y J. Ockerbloom (1995), Architectural Mismatch: Why Reuse is So Hard, Reuse is So Hard, IEEE SoftwareIEEE Software, Nov. 1995, pp. 17–26., Nov. 1995, pp. 17–26.
I. Jacobson, G. Booch y J. Rumbaugh (1999), I. Jacobson, G. Booch y J. Rumbaugh (1999), The Unified Software The Unified Software Development ProcessDevelopment Process, Addison-Wesley, Addison-Wesley
55
Bibliografía D. Krieger y R. M. Adler (1998), The Emergence of Distributed D. Krieger y R. M. Adler (1998), The Emergence of Distributed
Component Platforms, Component Platforms, IEEE ComputerIEEE Computer, March 1998, pp. 43–53., March 1998, pp. 43–53.
D. Luckham et al. (1995), Specification and Analysis of System D. Luckham et al. (1995), Specification and Analysis of System Architecture Using Rapide, Architecture Using Rapide, IEEE Transactions on Software IEEE Transactions on Software EngineeringEngineering, vol. 21, no. 4, April 1995, pp. 336–355., vol. 21, no. 4, April 1995, pp. 336–355.
J. Magee y J. Kramer (1996), Dynamic Structure in Software J. Magee y J. Kramer (1996), Dynamic Structure in Software Architectures, Architectures, Software Engineering NotesSoftware Engineering Notes, vol. 21, no. 6, Nov. 1996, , vol. 21, no. 6, Nov. 1996, pp. 3–14.pp. 3–14.
N. Medvidovic y D. Rosenblum (1997), A Framework for Classifying N. Medvidovic y D. Rosenblum (1997), A Framework for Classifying and Comparing Architecture Description Languages, and Comparing Architecture Description Languages, Proc. Proc. ESEC/FSEESEC/FSE, LNCS, Springer, pp. 60–76., LNCS, Springer, pp. 60–76.
56
Bibliografía W. Pree (1996), W. Pree (1996), Framework PatternsFramework Patterns, SIGS Publications., SIGS Publications.
M. Shaw et al. (1995), Abstractions for Software Architecture and M. Shaw et al. (1995), Abstractions for Software Architecture and Tools to Support Them, Tools to Support Them, IEEE Transactions on Software EngineeringIEEE Transactions on Software Engineering, , vol. 21, no. 4, April 1995, pp. 314–334.vol. 21, no. 4, April 1995, pp. 314–334.
M. Shaw y D. Garlan (1996), M. Shaw y D. Garlan (1996), Software Architecture: Perspectives on Software Architecture: Perspectives on an Emerging Disciplinean Emerging Discipline, Prentice Hall., Prentice Hall.
S. Sparks et al. (1996), Managing Object-Oriented Framework Reuse, S. Sparks et al. (1996), Managing Object-Oriented Framework Reuse, IEEE ComputerIEEE Computer, Sept. 1996, pp. 52–61., Sept. 1996, pp. 52–61.
C. Szyperski (1998), C. Szyperski (1998), Component Software: Beyond Object-Oriented Component Software: Beyond Object-Oriented ProgrammingProgramming, Addison-Wesley., Addison-Wesley.
A.W. Brown and K.C. Wallnau, The Current State of CBSE, IEEE A.W. Brown and K.C. Wallnau, The Current State of CBSE, IEEE Software, Sept/Oct. 1998Software, Sept/Oct. 1998