Desarrollo de Aplicaciones basado en Componentes y Frameworks Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento

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


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


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


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


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)


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


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


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


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

Documents

Desarrollo de Aplicaciones basado en Componentes y Frameworks Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento