software component models past present and future
play

Software Component Models: Past, Present and Future Kung-Kiu Lau, - PowerPoint PPT Presentation

Aug 18, 2022 •108 likes •1.98k views

Software Component Models: Past, Present and Future Kung-Kiu Lau, Zheng Wang, Simone Di Cola, Cuong Tran, Vasilis Christou School of Computer Science The University of Manchester United Kingdom kung-kiu@cs.man.ac.uk Tutorial, CompArch 2014,

  1. Current Component Models Support for Idealised Component and System Life Cycles Design Deploy Category Component Models Deposit-N Retrieve Compose Deposit-C Compose Design without Acme-like ADLs Repository UML2.0, PECOS Design with EJB, OSGi, Fractal Deposit-only Repository COM, .NET, CCM Deployment with JavaBeans, Repository Web Services Design with Koala, SOFA, Kobra Repository SCA, Palladio, ProCom Design & Deployment X-MAN with Repository Deposit-N=Deposit components constructed from scratch Deposit-C=Deposit composite components constructed from existing components Lau et al (University of Manchester) Software Component Models CompArch 2014 15 / 177

  2. Taxonomy of Component Models Builder RTE Builder Repository RTE InsA InsA A A A B InsB B B InsB Category 1: Design without Repository Category 2: Design with Deposit−only Repository (Acme−like ADLs, UML2.0, PECOS) (EJB, OSGi, Fractal, COM, .NET, CCM) Builder Repository Assembler RTE Builder Repository RTE InsA A A A A A B B B InsB AB InsAB B Category 3: Deployment with Repository Category 4: Design with Repository (JavaBeans, Web Services) (Koala, SOFA, KobrA, SCA, Palladio, ProCom) Builder Repository Assembler RTE A A InsA A AB InsAB AB B Category 5: Design and Deploy with Repository (X-MAN) Lau et al (University of Manchester) Software Component Models CompArch 2014 16 / 177

  3. Part II Taxonomy of component models: Overview (5 categories) Taxonomy of component models: Categories 1 and 2 Lau et al (University of Manchester) Software Component Models CompArch 2014 17 / 177

  4. Taxonomy of Component Models Overview Design Deploy Category Component Models Deposit-N Retrieve Compose Deposit-C Compose Design without Acme-like ADLs Repository UML2.0, PECOS Design with EJB, OSGi, Fractal Deposit-only Repository COM, .NET, CCM Deployment with JavaBeans, Repository Web Services Design with Koala, SOFA, Kobra Repository SCA, Palladio, ProCom Design & Deployment X-MAN with Repository Deposit-N=Deposit components constructed from scratch Deposit-C=Deposit composite components constructed from existing components Lau et al (University of Manchester) Software Component Models CompArch 2014 18 / 177

  5. Taxonomy of Component Models: Category 1 Builder RTE InsA A B InsB Category 1: Design without Repository (Acme−like ADLs, UML2.0, PECOS) Lau et al (University of Manchester) Software Component Models CompArch 2014 19 / 177

  6. Taxonomy of Component Models: Category 1 Acme-like ADLs Acme Acme [33] is a prototype Architecture Description Language (ADL). It typifies first-generation ADLs, e.g. Darwin [1], UniCon [3], Wright [4], ArchJava [7, 8]. Acme-like ADLs: Components In Acme-like ADLs , a component is an architectural unit that represents a primary computational element and data store of a system. Interfaces are defined by a set of ports Each port identifies a point of interaction between the component and its environment (including other components) A component may have multiple interfaces by using different types of ports Lau et al (University of Manchester) Software Component Models CompArch 2014 20 / 177

  7. Acme-like ADLs: Composition In Acme-like ADLs, components are composed by connectors Connectors connect components via their ports D B E A F C G Lau et al (University of Manchester) Software Component Models CompArch 2014 21 / 177

  8. Acme-like ADLs Support for Idealised Component and System Life Cycles In ACME-like ADLs, the components and the system are designed together in an ADL tool. The builder is the ADL tool if any There is no repository There is no assembler Builder RTE A A' c c' B1 c B c B2 B1' c' B' c' B2' A = component A A' = implementation of A B = component B B' = implementation of B B1= component B1 B1'= implementation of B1 B2= component B2 B2'= implementation of B2 c = connector c' = implementation of c Lau et al (University of Manchester) Software Component Models CompArch 2014 22 / 177

  9. Acme-like ADLs Component and System Life Cycles Component life cycle coincides with system life cycle During component/system design phase, components are ◮ identified and defined ◮ composed by connectors into a system design The design for both components and the system has to be implemented (somehow) in a chosen programming language. At run-time, the implemented system is executed in the run-time environment of that programming language. B1 B1’ A B A’ B’ B2 B2’ Acme/ArchJava Java Lau et al (University of Manchester) Software Component Models CompArch 2014 23 / 177

  10. Acme: Example Consider a simple bank system consisting of an ATM component, a BankConsortium component, and 2 Bank components Bank1 and Bank2. Component BankConsortium = { Component ATM = { Port receive; Port send; Port send; } } Component Bank1 = { Port receive; Property bankid : String = "Bank1"; } Component Bank2 = { Port receive; Property bankid : String = "Bank2"; } Lau et al (University of Manchester) Software Component Models CompArch 2014 24 / 177

  11. Acme: Example (cont’d) In design phase, the architecture for the whole system is designed B1 ATM BC B2 using the above components and the following connectors: Connector ATMtoBankCon = { Role request; Role produce; }; Connector BankContoB1 = { Role request; Role produce; }; Connector BankContoB2 = { Role request; Role produce; }; Lau et al (University of Manchester) Software Component Models CompArch 2014 25 / 177

  12. Acme: Example (cont’d) System BankSys = { Component ATM = { Component BankConsortium = { Port send; Port receive; }; Port send; }; Component Bank1 = { Component Bank2 = { Port receive; Port receive; Property bankid : String = "Bank1"; Property bankid : String = "Bank2"; }; }; Connector ATMtoBankCon = { Role request; Role produce; }; Connector BankContoB1 = { Connector BankContoB2 = { Role request; Role request; Role produce; Role produce; }; }; Attachments { ATM.send to ATMtoBankCon.request; ATMtoBankCon.produce to BankConsortium.receive; BankConsortium.send to BankContoB1.request; BankContoB1.produce to Bank1.receive; BankConsortium.send to BankContoB2.request; BankContoB2.produce to Bank2.receive; } } Lau et al (University of Manchester) Software Component Models CompArch 2014 26 / 177

  13. Taxonomy of Component Models: Category 1 UML2.0 UML2.0 Component Model: Components In UML2.0 [53], a component is a modular unit of a system with well-defined interfaces that is replaceable within its environment. provided service required service A component defines its behaviour by required and provided interfaces (ports); Services of components are encapsulated through their required and provided interfaces. Lau et al (University of Manchester) Software Component Models CompArch 2014 27 / 177

  14. UML 2.0: Composition UML2.0 components are composed by UML connectors: delegation connectors assembly connectors Composites are assembled by assembly connectors Systems are assembled by delegation and assembly connectors Delegation connector Assembly connector Lau et al (University of Manchester) Software Component Models CompArch 2014 28 / 177

  15. UML2.0 Support for Idealised Component and System Life Cycles In UML2.0, the components and the system are designed together in a visual builder tool such as Visual UML. The visual builder tool is the builder There is no repository There is no assembler Builder RTE A = UMLA B = UMLB InsA A InsA= UMLA instance InsB= UMLB instance B InsB = connector Visual Builder Implementation Tool Language RTE Lau et al (University of Manchester) Software Component Models CompArch 2014 29 / 177

  16. UML2.0 Component and System Life Cycles Component life cycle coincides with system life cycle During component/system design phase, components are ◮ identified and defined ◮ composed by connectors into a system design The design for both components and the system has to be implemented (somehow) in a chosen programming language. At run-time, the implemented system is executed in the run-time environment of that programming language. Lau et al (University of Manchester) Software Component Models CompArch 2014 30 / 177

  17. UML 2.0: Example Consider a simple bank system that is implemented by ATM, BankConsortium, Bank1 and Bank2 components. <<component>> <<component>> ATM BankConsortium <<provided interfaces>> <<provided interfaces>> GetCardNo CheckBankID <<required interfaces>> <<required interfaces>> CheckBankID GetCardNo Withdraw Deposit CheckBalance <<component>> <<component>> Bank1 Bank2 <<provided interfaces>> <<provided interfaces>> Withdraw Withdraw Deposit Deposit CheckBalance CheckBalance Lau et al (University of Manchester) Software Component Models CompArch 2014 31 / 177

  18. UML2.0: Example (cont’d) In design phase, the architecture for the whole system is designed. Bank1 ATM BankConsortium Bank2 Lau et al (University of Manchester) Software Component Models CompArch 2014 32 / 177

  19. Taxonomy of Component Models: Category 1 PECOS PECOS: Components In PECOS 1 [35], a component is a unit of design which has a specification and an implementation. Every component has a name, a number of property bundles, a set of ports, and behaviour Ports are interfaces of components PECOS components are specified in the CoCo (Component Composition) language. 1 PErvasive COmponent Systems Lau et al (University of Manchester) Software Component Models CompArch 2014 33 / 177

  20. PECOS: Composition In PECOS, components are composed by connectors Connectors connect components via their ports Device (active component, period = 1000 msecs) Clock Display msecs time EventLoop Digital time_in_msecs (active component) Display (aperiodic) started can_draw Lau et al (University of Manchester) Software Component Models CompArch 2014 34 / 177

  21. PECOS Support for Idealised Component and System Life Cycles In PECOS, the components and the system are designed and constructed together in a programming environment such as Eclipse. Builder RTE A = PECOSA B = PECOSB A InsA InsA= PECOSA instance InsB= PECOSB instance B InsB = connector Programming Implementation Environment Language RTE The programming environment is the builder There is no repository There is no assembler Lau et al (University of Manchester) Software Component Models CompArch 2014 35 / 177

  22. PECOS PECOS: Component and System Life Cycles Component life cycle coincides with system life cycle During component/system design phase, components are ◮ identified and defined ◮ composed by connectors into a system design in the CoCo (Component Composition) language The design has to be implemented in a chosen programming language, usually Java or C++. At run-time, the implemented system is executed in the run-time environment of Java or C++. Lau et al (University of Manchester) Software Component Models CompArch 2014 36 / 177

  23. PECOS: Example Consider a device that is assembled from Clock, Display, EventLoop and DigitalDisplay components. component Clock { component Display { output long msecs; input long time; } } active component EventLoop { component DigitalDisplay { output bool started; input long time_in_msecs; } input bool can_draw; } Lau et al (University of Manchester) Software Component Models CompArch 2014 37 / 177

  24. PECOS: Example (cont’d) In the design phase, the architecture for the device is designed: Device (active component, period = 1000 msecs) Clock Display msecs time EventLoop Digital time_in_msecs (active component) Display (aperiodic) started can_draw active component Device { Clock clock; Display display; DigitalDisplay digitalDisplay; EventLoop eventLoop; connector time(clock.msecs, display.time, digitalDisplay.time_in_msecs); connector eventLoop_started(eventLoop.started, digitalDisplay.can_draw); } Lau et al (University of Manchester) Software Component Models CompArch 2014 38 / 177

  25. Taxonomy of Component Models: Category 2 Builder Repository RTE InsA A A B B InsB Category 2: Design with Deposit−only Repository (EJB, OSGi, Fractal, COM, .NET, CCM) Lau et al (University of Manchester) Software Component Models CompArch 2014 39 / 177

  26. Taxonomy of Component Models: Category 2 Enterprise JavaBeans (EJB) EJB: Components In EJB [30, 51] a component is an enterprise Java bean with a Java interface: Client Machine J2EE Server Client Application EJB Container Container Enterprise Enterprise Client Bean Bean Database Application an enterprise Java bean is a Java class in an EJB container on a J2EE server an EJB container uses the interface to manage and execute the Java class and its instances. Lau et al (University of Manchester) Software Component Models CompArch 2014 40 / 177

  27. EJB: Components (cont’d) For an EJB: its Java class defines the methods of the bean its interface exposes the capabilities of the bean and provides all the methods needed for (remote) client applications to access the bean (over a network) There are 3 kinds of EJBs: Entity beans Entity beans model business data; they are Java objects that cache database information. Session beans Session beans model business processes; they are Java objects that act as agents performing tasks. Message-driven beans Message-driven beans model message-related business processes; they are Java objects that act as message listeners. Lau et al (University of Manchester) Software Component Models CompArch 2014 41 / 177

  28. EJB: Composition Enterprise beans are composed (in the EJB container) by method and event delegation J2EE Server EJB Container ClientAppA SessionBeanA method1 method1 . . . . . . methodM methodN . . . methodN SessionBeanB SessionBean C ClientAppB method1 method1 . . . . . . method1 methodM methodM . . . . . . . . . methodN methodN methodN EntityBean ClientAppC method1 . . . method1 methodM . . . . . . DataBase methodN methodN Lau et al (University of Manchester) Software Component Models CompArch 2014 42 / 177

  29. EJB Support for Idealised Component and System Life Cycles EJBs are constructed and composed in a J2EE-compliant IDE, and deposited and executed in an EJB contanier. A J2EE-compliant IDE (e.g. NetBeans) is the builder for EJB (composition of beans) An EJB container is the repository There is no assembler Builder Repository RTE A = EJBA (JAR file) B = EJBB (JAR file) InsA A A InsA= EJBA instance InsB= EJBB instance B B InsB = method call NetBeans EJB EJB container container Lau et al (University of Manchester) Software Component Models CompArch 2014 43 / 177

  30. EJB Component and System Life Cycles In EJB, components are EJBs, and a system is the composition of EJBs in the EJB container (with a remote interface) Component life cycle coincides with system life cycle In component/system design phase, enterprise beans ◮ are designed, implemented and composed into a complete system ◮ and deposited in the EJB container Client applications make calls to enterprise beans in the system via the system’s remote interface At run-time, client applications are executed, invoking enterprise beans in the system. Lau et al (University of Manchester) Software Component Models CompArch 2014 44 / 177

  31. EJB: Example Consider a bank which wishes to provide basic services (check balance, withdrawal and deposit) on its customer accounts. The table of accounts in the database can be represented as an entity bean Account that consists of a Java class and a helper class. The Account Java class is defined with methods to access and change account details. Each instance of Account represents a row of the table of accounts in the database. AccountFacade is the helper class that behaves like the (EJB2) home interface of the Account bean. Lau et al (University of Manchester) Software Component Models CompArch 2014 45 / 177

  32. EJB: Example (cont’d) @Entity @T able(name = "ACCOUNT") @XmlRootElement @NamedQueries({ @NamedQuery(name = "Account. fi ndAll", query = "SELECT a FROM Account a"), @NamedQuery(name = "Account. fi ndByAccno", query = "SELECT a FROM Account a WHERE a.accno = :accno"), @NamedQuery(name = "Account. fi ndByBalance", query = "SELECT a FROM Account a WHERE a.balance = :balance")}) public class Account implements Serializable { private static fi nal long serialVersionUID = 1L; @Id @Basic(optional = false) @NotNull @Size(min = 1, max = 4) @Column(name = "ACCNO") private String accno; @Basic(optional = false) @NotNull @Column(name = "BALANCE") private int balance; public Account() { } public Account(String accno) { this.accno = accno; } public Account(String accno, int balance) { this.accno = accno; this.balance = balance; } public String getAccno() { return accno; } public void setAccno(String accno) { this.accno = accno; } public int getBalance() { return balance; } public void setBalance(int balance) { this.balance = balance; } ... Lau et al (University of Manchester) Software Component Models CompArch 2014 46 / 177

  33. EJB: Example (cont’d) To construct the system we also need a session bean Bank that consists of a Java class and interface: Bank is the Java class that defines the business methods (services on accounts) BankRemote is the remote interface Lau et al (University of Manchester) Software Component Models CompArch 2014 47 / 177

  34. EJB: Example (cont’d) @Stateless public class Bank implements BankRemote { @EJB private AccountFacade accountFacade; @Override public Integer balance( fi nal String accno) throws Exception { Account acc = accountFacade. fi nd( accno ); if ( acc != null ) return acc.getBalance(); else throw new Exception ( "Account not found." ); } @Override public void deposit( fi nal String accno, fi nal Integer amount) throws Exception { if ( amount <= 0 ) throw new Exception ( "Invalid amount." ); Account acc = accountFacade. fi nd( accno ); if ( acc != null ) acc.setBalance( acc.getBalance() + amount ); else throw new Exception ( "Account not found." ); ... Lau et al (University of Manchester) Software Component Models CompArch 2014 48 / 177

  35. EJB: Example (cont’d) The system is assembled from the Account entity bean and the Bank session bean: J2EE Server EJB Container Bank BankClient BankRemote AccountFacade delegate Account DataBase Lau et al (University of Manchester) Software Component Models CompArch 2014 49 / 177

  36. Taxonomy of Component Models: Category 2 OSGi Component Model OSGi A component framework that brings modularity to JAVA platform http://www.osgi.org/Technology/WhatIsOSGi Lau et al (University of Manchester) Software Component Models CompArch 2014 50 / 177

  37. OSGi: Bundles OSGi consists of bundles: Bundle-ManifestVersion: 2 Bundle-Name: Greeting API Bundle-SymbolicName: org.foo.hello Class files Bundle-Version: 1.0 Bundle-Activator: org.foo.HelloWorld Resources Metadata Export-Package: org.foo.hello;version="1.0“ files file Import-Package: org.foo.hello;version="[1.0,2.0)" Bundle JAR INSTALLED STARTING Life-Cycle RESOLVED ACTIVE STOPPING UNINSTALLED Lau et al (University of Manchester) Software Component Models CompArch 2014 51 / 177

  38. OSGi Component Model Components and Composition OSGi bundles do not compose, but POJOs within them do via direct method invocation. So components in OSGi component model are Java objects; and composition is by direct method call. Publish Find Service Registry Interact Bundle A Bundle B Lau et al (University of Manchester) Software Component Models CompArch 2014 52 / 177

  39. OSGi Component Model Support for Idealised Component and System Life Cycles POJOs in OSGi bundles are constructed in any editor, e.g. Eclipse. They are composed inside a bundle to provide a service (exposed by the bundle) (POJOs inside) Bundles are installed in an OSGi-compliant framework, e.g. Equinox, which is therefore the repository There is no assembler Builder Repository RTE A = POJOA B = POJOB InsA A A InsA= POJOA instance InsB= POJOB instance B B InsB = method call Eclipse Equinox Equinox Lau et al (University of Manchester) Software Component Models CompArch 2014 53 / 177

  40. OSGi Component Model Component and System Life Cycles In OSGi component models, components are POJOs, and a system is the service provided by their composition (with an interface published by the bundle) Component life cycle coincides with system life cycle In component/system design phase, POJOs ◮ are designed, implemented and composed into a system ◮ and deposited in the an OSGi-compliant framework, e.g. Equinox Client applications make calls to POJOs inside bundles via the published service interface At run-time, client applications are executed, invoking POJO instances in the system. Lau et al (University of Manchester) Software Component Models CompArch 2014 54 / 177

  41. OSGi: Example - HelloWorld Producer Lau et al (University of Manchester) Software Component Models CompArch 2014 55 / 177

  42. Taxonomy of Component Models: Category 2 Fractal Fractal: Components In Fractal [19, 20, 32], a component: is a unit of encapsulation and behaviour consists of two parts: ◮ content ⋆ a finite set of sub-components ◮ membrane ⋆ typically composed of several controllers, each in charge of a specific function ⋆ supports interfaces to introspect and reconfigure its internal features ⋆ maintains a causally connected representation of the component’s content Lau et al (University of Manchester) Software Component Models CompArch 2014 56 / 177

  43. Fractal: Components (cont’d) Lau et al (University of Manchester) Software Component Models CompArch 2014 57 / 177

  44. Fractal: Composition Composition via port bindings A binding can be either: ◮ primitive: if the bound interfaces are in the same address space (e.g. B-C in picture); or ◮ composite if the bound interfaces span different address spaces; it is embodied in a binding object which itself takes the form of a component (e.g. A-E in picture) Lau et al (University of Manchester) Software Component Models CompArch 2014 58 / 177

  45. Fractal Support for Idealised Component and System Life Cycles Fractal components are constructed in the Fractal for Eclipse (F4E) programming environment The programming environment is the builder The programming environment is the repository There is no assembler The run-time environment is the JVM Builder Repository RTE A = FractalA (JAR file) B = FractalB (JAR file) A A InsA InsA= FractalA instance InsB= FractalB instance B B InsB = method call F4E F4E JVM Lau et al (University of Manchester) Software Component Models CompArch 2014 59 / 177

  46. Fractal Component and System Life Cycles Component life cycle coincides with system life cycle During component/system design phase, components in a chosen programming language (Java or C/C++) are ◮ identified and defined ◮ composed by port bindings into a system design using Fractal APIs At run-time, the system is executed in the run-time environment of the chosen programming language (Java or C/C++). Lau et al (University of Manchester) Software Component Models CompArch 2014 60 / 177

  47. Fractal: Example http://fractal.ow2.org/doc/ow2-webinars09/Fractal-Java-Lionel.pdf Lau et al (University of Manchester) Software Component Models CompArch 2014 61 / 177

  48. Taxonomy of Component Models: Category 2 COM COM: Components In COM (Component Object Model) [17, 49, 54, 27], a component is a unit of compiled code on Windows Registry. IUnknown Ifun1 Component Ifun2 Services in a component are invoked via pointers to the functions that implement them For each service provided there is an interface (a COM component can implement multiple interfaces) COM interfaces are specified in Microsoft IDL Every component must implement an IUnknown interface Lau et al (University of Manchester) Software Component Models CompArch 2014 62 / 177

  49. COM: Composition COM components are composed by method calls via interface pointers IUnknown IUnknown Component1 Component2 Client Reference Lau et al (University of Manchester) Software Component Models CompArch 2014 63 / 177

  50. COM Support for Idealised Component and System Life Cycles COM components are constructed in a programming environment such as Microsoft Visual Studio The programming environment is the builder The Windows Registry is the repository There is no assembler = Builder Repository RTE A = COMA B COMB InsA= InsA A A COMA instance InsB= = COMB instance B B InsB method call Programming Windows Windows environment Registry OS Lau et al (University of Manchester) Software Component Models CompArch 2014 64 / 177

  51. COM COM Component and System Life Cycles Component life cycle coincides with system life cycle: In component/system design phase, COM components are ◮ designed and implemented ◮ assembled into a complete system ◮ deposited in Windows Registry Client applications make calls to COM components in the system via interface pointers At run-time, client applications are executed, invoking COM components in the system. Lau et al (University of Manchester) Software Component Models CompArch 2014 65 / 177

  52. COM: Example Consider a spell checker system that comprises a checker component and a dictionary component. import "unknwn.idl"; UUID of Checker component [object, uuid(CAB357AE−1204−4783−AC3F−A7E4CA19EF6C)] interface ISpellCheck : IUnknown { ISpellCheck interface specifies HRESULT CheckSpelling([in, string] char *word, the method implemented by [out, retval] BOOL *isCorrect); Checker component } [uuid(0EE7AE7−A357−4a04−B6D6−CE4DFD5CCAAF)] IID of ISpellCheck library SpellcheckerLib { [uuid(49FA65CD−8CF6−4876−8443−37A75A267A7D)] CLSID of CSpellCheck coclass CSpellCheck { CSpellCheck class implements interface ISpellCheck; the ISpellCheck interface } }; Checker component interface −− ISpellCheck A “library” is an interface glued with a coclass, e.g. the “library” of ISpellCheck and CSpellCheck makes the whole component Lau et al (University of Manchester) Software Component Models CompArch 2014 66 / 177

  53. COM: Example (cont’d) import "unknwn.idl"; UUID of Dictionary component [object, uuid(D66AB784−75C8−4f52−8EB2−C5BE9796ABEF)] interface IUseCustomDictionary : IUnknown { IUseCustomDictionary interface specifies the method implemented HRESULT UseCustomDictionary([out, retval] vector <string>* dict); } by Dictionary component [uuid(1C381680−CF29−46b1−8060−1237C36EA6C7)] library CustomdictionaryLib { [uuid(C51815AF−CB06−4028−956C−C5F3E5781780)] CCustomDictionary class implements coclass CCustomDictionary { the IUseCustomDictionary interface interface IUseCustomDictionary; } }; Dictionary component interface −− IUseCustomDictionary Lau et al (University of Manchester) Software Component Models CompArch 2014 67 / 177

  54. COM: Example (cont’d) In design phase, the spell checker system is assembled through method calls via interface pointers. #include <string.h> #include <fstream> CSpellCheckImpl :: CSpellCheckImpl() { } CCustomDictionaryImpl :: CCustomDictionaryImpl() { } CSpellCheckImpl :: ~CSpellCheckImpl() { } CCustomDictionaryImpl :: ~CCustomDictionaryImpl() { } STDMETHODIMP_(ULONG) CSpellCheckImpl :: AddRef(void) { STDMETHODIMP_(ULONG) CCustomDictionaryImpl :: AddRef(void) { } } STDMETHODIMP_(ULONG) CSpellCheckImpl :: Release(void) { STDMETHODIMP_(ULONG) CCustomDictionaryImpl :: Release(void) { } } STDMETHODIMP CSpellCheckImpl :: QueryInterface(...) { STDMETHODIMP CCustomDictionaryImpl :: QueryInterface(...) { } } STDMETHODIMP CSpellCheckImpl :: CheckSpelling(...) { STDMETHODIMP CCustomDictionaryImpl :: UseCustomDictionary(...) { *p = dictionary; CCustomDictionary* pc = 0; pc = new CCustomDictionaryImpl(); return NOERROR; } IUseCustomDictionary* pi = 0; HRESULT hr; hr = pc −> QueryInterface(IID_IUseCustomDictionary, (void**) &pi); if(FAILED(hr)) return ERROR; pi −> UseCustomDictionary(&m_dictionary); } Checker component implementation Dictionary component implementation Lau et al (University of Manchester) Software Component Models CompArch 2014 68 / 177

  55. Taxonomy of Component Models: Category 2 .NET Component Model .NET Component Model: Components In Microsoft .NET [55, 66, 2], a component is an assembly that is a binary unit supported by Common Language Runtime (CLR) Metadata IL Code A .NET component is made up of metadata and code in Intermediate Language (IL) The metadata contains the description of assembly, types and attributes The IL code can be executed in CLR Lau et al (University of Manchester) Software Component Models CompArch 2014 69 / 177

  56. .NET Component Model: Composition .NET components are composed by method calls through references via metadata Metadata Metadata Metadata IL Code IL Code IL Code Assembly1 Assembly2 Assembly3 Lau et al (University of Manchester) Software Component Models CompArch 2014 70 / 177

  57. .NET Component Model Support for Idealised Component and System Life Cycles .NET components are constructed in a programming environment such as Microsoft Visual Studio .NET The programming environment is the builder The Microsoft Enterprise Library (MEL) is the repository There is no assembler Builder Repository RTE A = NETA B = NETB InsA A A InsA= NETA instance InsB= NETB instance B B InsB = method call Programming MEL Windows environment Lau et al (University of Manchester) Software Component Models CompArch 2014 71 / 177

  58. .NET Component and System Life Cycles Component life cycle coincides with system life cycle In component/system design phase, .NET components are ◮ designed and implemented ◮ assembled into a complete system ◮ deposited in a Windows server Client applications make calls to .NET components in the system At run-time, client applications are executed, invoking .NET components in the system. Lau et al (University of Manchester) Software Component Models CompArch 2014 72 / 177

  59. .NET: Example Consider a banking system with an ATM component, which serves two instances Bank1 and Bank2 of a Bank component. Class: Class: Name: ATM; Name: Bank; Visibility: Public; Visibility: Public; Type: Class Type: Class Method: Method: Name: LocateBank; Name: Deposit; Visibility: Public; Visibility: Public; Virtual; Virtual; Metadata Interop; Interop; (attributes) IL; IL; Managed; Managed; Signature: void Deposit(CardNo ACardNo, void LocateBank(CardNo ACardNo, Password CusPass); Parameter: Password CusPass); Name: ACardNo; Invoke: Bank.Deposit(...); Order: 1; Parameter: Attributes: In; Name: ACardNo; Parameter: Order: 1; Name: CusPass; Attributes: In; Order: 2; Parameter: Attributes: In; Name: CusPass; . . Order: 2; . Attributes: In; IL Code IL Code ATM Component Bank Component Lau et al (University of Manchester) Software Component Models CompArch 2014 73 / 177

  60. .NET: Example (cont’d) The banking system is assembled from the ATM component and two instances of Bank component. Class: Class: Name: ATM; Name: Bank; Visibility: Public; Visibility: Public; Type: Class Type: Class Method: Method: Name: LocateBank; Name: Deposit; Visibility: Public; Visibility: Public; Virtual; Virtual; Interop; Interop; IL; IL; Managed; Managed; Signature: void Deposit(CardNo ACardNo, void LocateBank(CardNo ACardNo, Password CusPass); Parameter: Password CusPass); Name: ACardNo; Invoke: Bank.Deposit(...); Order: 1; Parameter: Attributes: In; Name: ACardNo; Parameter: Order: 1; Name: CusPass; Attributes: In; Order: 2; Parameter: Attributes: In; Name: CusPass; . . Order: 2; . Attributes: In; IL Code IL Code ATM Component Bank Component Lau et al (University of Manchester) Software Component Models CompArch 2014 74 / 177

  61. Taxonomy of Component Models: Category 2 CCM CCM: Components In CCM (CORBA Component Model) [14, 13, 6], a component is a CORBA meta-type hosted by a CCM container on a CCM platform such as OpenCCM. Event sink Facet Event source Receptacle A CORBA meta-type is an extension and specialisation of a CORBA Object [52, 16] Component interfaces are made up of ports: Facets (provided services), Receptacles (required services), Event Sources and Event Sinks. Component types are specific, named collections of features that can be described in OMG IDL 3 CCM components have homes that are component factories to manage a component instance life cycle Lau et al (University of Manchester) Software Component Models CompArch 2014 75 / 177

  62. CCM: Composition CCM components are assembled by method and event delegations in such a way that facets match receptacles event sources match event sinks ... ... Lau et al (University of Manchester) Software Component Models CompArch 2014 76 / 177

  63. CCM Support for Idealised Component and System Life Cycles CCM components are constructed in a programming environment such as Open Production Tool Chain and deposited into a CCM container hosted and managed by a CCM platform such as OpenCCM. The programming environment is the builder The CCM container is the repository There is no assembler Builder Repository RTE A = CCMA B = CCMB InsA A A InsA= CCMA instance InsB= CCMB instance B B InsB = method call Programming CCM CCM environment container server Lau et al (University of Manchester) Software Component Models CompArch 2014 77 / 177

  64. CCM Component and System Life Cycles Component life cycle coincides with system life cycle In Component/system design phase, CCM components are ◮ designed and implemented ◮ composed into a complete system ◮ deposited in the CCM server Client applications make calls to CCM components in the system via the system’s interface At run-time, client applications are executed, invoking CCM components in the system. Lau et al (University of Manchester) Software Component Models CompArch 2014 78 / 177

  65. CCM: Example Consider a simple bank system implemented by ATM, BankConsortium, Bank1 and Bank2 components (in OMG IDL 3): enum BankState { IsCustomer, NotCustomer interface Bank { }; string getBankID(string cardno); eventtype AccountInfo { void deposit(string cardno); public string cardno; void withdraw(string cardno); public BankState customerinfo; void checkBalance(string cardno); } }; component ATM { attribute string atmid; receptacle uses Bank getBankID; event sink consumes AccountInfo customer; }; manages instances home ATMhome manages ATM { factory new(in string atmid); }; Lau et al (University of Manchester) Software Component Models CompArch 2014 79 / 177

  66. CCM: Example (cont’d) component Bank { attribute string bankid; facet provides Bank deposit; provides Bank withdraw; provides Bank checkBalance; }; home Bankhome manages Bank { factory new(in string bankid); }; component BankConsortium { attribute string bankconsortiumid; provides Bank getBankID; uses Bank deposit; uses Bank withdraw; provides Bank checkBalance; event source publishes AccountInfo customer; }; BankConhome manages BankConsortium { home factory new(in string bankconsortiumid); }; Lau et al (University of Manchester) Software Component Models CompArch 2014 80 / 177

  67. CCM: Example (cont’d) The bank system is assembled from the ATM, BankConsortium, Bank1 and Bank2 components. Bank1 ATM BankConsortium Bank2 The composition of CCM components is specified in a Component Assembly Descriptor (an XML file) Lau et al (University of Manchester) Software Component Models CompArch 2014 81 / 177

  68. CCM: Example (cont’d) <?xml version = "1.0"?> <!DOCTYPE component assembly BANKSYSTEM "componentassembly.dtd"> <component assembly id = "banksys"> <description> bank assembly descriptor</description> <componentfiles> <componnetfile id = "ATM component"> <filearchive name = "ATM.csd"> </componentfile> <componnetfile id = "BankConsortium component"> <filearchive name = "BankConsortium.csd"> </componentfile> <componnetfile id = "Bank component"> <filearchive name = "Bank.csd"> </componentfile> </componentfiles> <partitioning> <homereplacement id = "ATMHome"> <componentfileref idref = "ATM Component"/> <componentinstantiation id = "atm"> <registerwithnaming name = "ATMHome"/> </homereplacement> <homereplacement id = "BankConsortiumHome"> <componentfileref idref = "BankConsortium Component"/> <componentinstantiation id = "bankconsortium"> <registerwithnaming name = "BankConsortiumHome"/> </homereplacement> <homereplacement id = "BankHome"> <componentfileref idref = "Bank Component"/> <componentinstantiation id = "bank1"> <componentinstantiation id = "bank2"> <registerwithnaming name = "BankHome"/> </homereplacement> </partitioning> <connections> . . . </connections> </component assembly> Lau et al (University of Manchester) Software Component Models CompArch 2014 82 / 177

  69. CCM: Example (cont’d) <connections> <connectinterface> <usesport> <usesidentifier>getBankID</usesidentifier> <componentinstantiationref idref = "atm"/> <usesidentifier>deposit</usesidentifier> <usesidentifier>withdraw</usesidentifier> <usesidentifier>checkBalance</usesidentifier> <componentinstantiationref idref = "bankcon"/> </usesport> <providesport> <providesidentifier>getBankID</providesidentifier> <componentinstantiationref idref = "bankcon"/> <providesidentifier>deposit</providesidentifier> <providesidentifier>withdraw</providesidentifier> <providesidentifier>checkBalance</providesidentifier> <componentinstantiationref idref = "bank"/> </providesport> </connectinterface> <connectevent> <publishesport> <publishesidentifier>customer</publishesidentifier> <componentinstantiationref idref = "bankcon"/> </publishesport> <consumesport> <consumesidentifier>customer</consumesidentifier> <componentinstantiationref idref = "atm"/> </consumesport> </connectevent> </connections> Lau et al (University of Manchester) Software Component Models CompArch 2014 83 / 177

  70. Part III Taxonomy of component models: Categories 3,4 and 5 Lau et al (University of Manchester) Software Component Models CompArch 2014 84 / 177

  71. Taxonomy of Component Models: Category 3 Builder Repository Assembler RTE InsA A A A B B B InsB Category 3: Deployment with Repository (JavaBeans, Web Services) Lau et al (University of Manchester) Software Component Models CompArch 2014 85 / 177

  72. Taxonomy of Component Models: Category 3 JavaBeans JavaBeans: Components In JavaBeans [61, 39], a component is a bean, which is just any Java class that has: methods events properties A bean is intended to be constructed and manipulated in a visual bean builder tool like NetBeans. Lau et al (University of Manchester) Software Component Models CompArch 2014 86 / 177

  73. JavaBeans: Composition In deployment phase, bean instances are composed via event delegation TargetBean SourceBean Target Generate Method Event Notify EventAdaptor Trigger Event NotifiedEvent Target Method Call Target Method a bean ‘composes’ with another bean by sending a message through delegation of events the bean builder tool automatically generates, compiles, and loads event adaptor classes for logistics of events Lau et al (University of Manchester) Software Component Models CompArch 2014 87 / 177

  74. JavaBeans (NetBeans) Support for Idealised Component and System Life Cycles In NetBeans, individual beans are constructed as Java classes, and deposited in the Palette. Bean instances are retrieved from the Palette into the Design Form and composed into a system. NetBeans is the builder for Java beans the Palette of NetBeans is the repository (no composition) The Design Form of NetBeans is the assembler (composition of bean instances) JVM is the run-time environment Builder Repository Assembler RTE A = BeanA (JAR file) B = BeanB (JAR file) InsA A A A InsA= BeanA instance InsB= BeanB instance B B InsB B = adaptor object NetBeans Palette Design Form JVM Lau et al (University of Manchester) Software Component Models CompArch 2014 88 / 177

  75. JavaBeans: NetBeans visual builder Picture taken from [39]. Lau et al (University of Manchester) Software Component Models CompArch 2014 89 / 177

  76. Javabeans Component and System Life Cycles Component life cycle is separate from system life cycle In component design phase, beans are designed, implemented and deposited in the repository (e.g. NetBeans Palette) In system design/component deployment phase, beans are retrieved from the repository and composed into a system in the assembler (e.g. NetBeans Design Form). In system run-time, the system is executed in the assembler in JVM. Lau et al (University of Manchester) Software Component Models CompArch 2014 90 / 177

  77. JavaBeans: Example jButton1 has a method to generate an event (mouse press) when it is pressed jLabel1 has a method that outputs the message “You pressed the button” The two beans are composed by an adaptor that when notified of an event (mouse press) calls jLabel1’s method, to produce the GUI shown Pictures taken from [39]. Lau et al (University of Manchester) Software Component Models CompArch 2014 91 / 177

  78. Taxonomy of Component Models: Category 3 Web Services Web Services: Components Web services [9, 12, 5] are web application components that can be published, found, and used on the Web A web service contains: ◮ an interface in WSDL (Web Service Description Language) ⋆ describes the functionalities the web service provides ◮ a binary implementation (the service code) WSDL Service Code Service clients communicate directly with service providers [12]. Lau et al (University of Manchester) Software Component Models CompArch 2014 92 / 177

  79. Web Services: Composition Web services are composed by method calls through SOAP (Simple Object Access Protocol) or JSON (JavaScript Object Notation) messages SOAP uses XML tags while JSON uses name/value pairs [12] WSDL WSDL WSDL SOAP SOAP Service Code Service Code Service Code JSON JSON Service1 Service2 Service3 Lau et al (University of Manchester) Software Component Models CompArch 2014 93 / 177

  80. Web Services: Composition Orchestration 2: Invoke 1: Receive Web service Web service 1 3 . . . Orchestration 5: Reply (Coordinator) 4: Invoke Web service Web service 3: Invoke 2 n Choreography Web service 1 5: Invoke 1: Invoke Web service Web service 4 2 3: Reply 2: Invoke 4: Invoke Web service 3 Pictures from: http://www.oracle.com/technetwork/articles/matjaz-bpel1-090575.html Lau et al (University of Manchester) Software Component Models CompArch 2014 94 / 177

  81. Web Services Support for Idealised Component and System Life Cycles Web services are constructed in a programming environment, e.g. Eclipse for Java, and deposited on a web server. Web services are composed (by orchestration) in a BPEL editor and the orchestration is executed on a BPEL engine. The programming environment is the builder The web server is the repository A BPEL editor is the assembler a BPEL engine is the run-time environment Builder Repository Assembler RTE A A = WebServiceA A A A B = WebServiceB = orchestration B B B B Programming Web BPEL BPEL Environment Server Editor Engine Lau et al (University of Manchester) Software Component Models CompArch 2014 95 / 177

  82. Web Services Component and System Life Cycles Component life cycle is separate from system life cycle In component design phase, services are ◮ designed and implemented ◮ deposited on a web server In system design/component deployment phase, services are orchestrated in a BPEL editor At run-time, the orchestration is executed on a BPEL engine Lau et al (University of Manchester) Software Component Models CompArch 2014 96 / 177

  83. Web Services: Example Composition by Orchestration 1: Request <<invoke (sync)>> Client Retrieve employee 6: Reply travel status portType 2: Request Employee <<invoke (async)>> Travel <<invoke (async)>> Get plane ticket offer Get plane ticket offer StatusWeb 3: Reply from American Airlines from Delta Airlines Service 4.1: Invoke [American.price<=Delta.price] [American.price>Delta.price] American Airlines <<assign>> <<assign>> Web 4.2: Call-back Select American Select Delta Service Airlines ticket Airlines ticket 5.2: Call-back Delta <<reply>> portType Airlines Return the best offer 5.1: Invoke Web Service BPEL Process for Business Travels Picture from: http://www.oracle.com/technetwork/articles/matjaz-bpel1-090575.html Lau et al (University of Manchester) Software Component Models CompArch 2014 97 / 177

  84. Web Services: Example (cont’d) Composition by Orchestration <portT ype name="TravelApprovalPT"> <operation name="TravelApproval"> BPEL Process <input message="..." /> </operation> </portT ype> <portT ype name="ClientCallbackPT"> Employee <portT ype name="EmployeeTravelStatusPT"> <operation name="ClientCallback"> <operation name="EmployeeTravelStatus"> Travel Status <input message="..." /> <input message="..." /> </operation> Web <output message="..." /> </portT ype> </operation> Service BPEL Process Code </portT ype> <portT ype name="FlightAvailabilityPT"> <portT ype name="FlightAvailabilityPT"> <operation name="FlightAvailability"> <operation name="FlightAvailability"> <input message="..." /> <input message="..." /> </operation> </operation> </portT ype> </portT ype> <portT ype name="FlightCallbackPT"> <portT ype name="FlightCallbackPT"> <operation name="FlightTicketCallback"> <operation name="FlightTicketCallback"> <input message="..." /> <input message="..." /> </operation> </operation> </portT ype> </portT ype> Delta Airlines Web Service American Airlines Web Service Lau et al (University of Manchester) Software Component Models CompArch 2014 98 / 177

  85. Web Services: Example (cont’d) Employee Travel Status Web Service <message name="EmployeeTravelStatusRequestMessage"> <part name="employee" type="tns:EmployeeType" /> </message> <message name="EmployeeTravelStatusResponseMessage"> <part name="travelClass" type="tns:TravelClassType" /> </message> <portType name="EmployeeTravelStatusPT"> <operation name="EmployeeTravelStatus"> <input message="tns:EmployeeTravelStatusRequestMessage" /> <output message="tns:EmployeeTravelStatusResponseMessage" /> </operation> </portType> Lau et al (University of Manchester) Software Component Models CompArch 2014 99 / 177

  86. Web Services: Example (cont’d) American Airlines and Delta Airlines Web Service <message name="FlightTicketRequestMessage"> <part name="flightData" type="tns:FlightRequestType" /> <part name="travelClass" type="emp:TravelClassType" /> </message> <message name="TravelResponseMessage"> <part name="confirmationData" type="tns:FlightConfirmationType" /> </message> <portType name="FlightAvailabilityPT"> <operation name="FlightAvailability"> <input message="tns:FlightTicketRequestMessage" /> </operation> </portType> <portType name="FlightCallbackPT"> <operation name="FlightTicketCallback"> <input message="tns:TravelResponseMessage" /> </operation> </portType> Lau et al (University of Manchester) Software Component Models CompArch 2014 100 / 177

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend

VA Psychology Leadership Conference y gy p PAST PRESENT &amp; FUTURE FOR VHA: PAST, PRESENT

VA Psychology Leadership Conference y gy p PAST PRESENT &amp; FUTURE FOR VHA: PAST, PRESENT

VA Psychology Leadership Conference y gy p PAST PRESENT &amp; FUTURE FOR VHA: PAST, PRESENT &amp; FUTURE FOR VHA: THE REALIGNMENT IN CENTRAL OFFICE May 18, 2011 y , George W. Arana, MD Acting Assistant Deputy Under Secretary for Health g p

510 views • 32 slides
The Past, Present and Future of Irish Agriculture Brendan Kearney The Past, Present and Future of

The Past, Present and Future of Irish Agriculture Brendan Kearney The Past, Present and Future of

The Past, Present and Future of Irish Agriculture Brendan Kearney The Past, Present and Future of Irish Agriculture Changing role in the economy Main policy developments and output/ income trends Changing structure and performance

852 views • 17 slides
CUPA - RIO GRANDE CHAPTER ACA (PAST, PRESENT AND FUTURE) Agenda 1. ACA Foundations 2. Past -

CUPA - RIO GRANDE CHAPTER ACA (PAST, PRESENT AND FUTURE) Agenda 1. ACA Foundations 2. Past -

CUPA - RIO GRANDE CHAPTER ACA (PAST, PRESENT AND FUTURE) Agenda 1. ACA Foundations 2. Past - The Early Days 3. Present - Current State 4. Future Whats Next 5. Solutions ACA Compliance Tools 6. Question and Answer Jeff Taylor

373 views • 19 slides
20 Years of PaX PaX Team SSTIC 2012.06.06 20 Years of PaX About Past Present Future About

20 Years of PaX PaX Team SSTIC 2012.06.06 20 Years of PaX About Past Present Future About

About Past Present Future 20 Years of PaX PaX Team SSTIC 2012.06.06 20 Years of PaX About Past Present Future About Introduction Design Concepts Past Userland Present Kernel Self-Protection Toolchain Support Future Userland

803 views • 40 slides
El Nio Past, present and future perspectives M Jarraud Secretary-General Emeritus World

El Nio Past, present and future perspectives M Jarraud Secretary-General Emeritus World

El Nio Past, present and future perspectives M Jarraud Secretary-General Emeritus World Meteorological Organization Rome, 17 March 2016 www.wmo.int El Nio: Much ado El Nio (1997) about something Largest component of internal

499 views • 29 slides
Software Debugging: Past, Present, and Future Alessandro (Alex) Orso School of Computer

Software Debugging: Past, Present, and Future Alessandro (Alex) Orso School of Computer

Software Debugging: Past, Present, and Future Alessandro (Alex) Orso School of Computer Science College of Computing Georgia Institute of Technology http://www.cc.gatech.edu/~orso/ Partially supported by : NSF, Google, IBM, and MSR

1.46k views • 108 slides
Who Controls the Past Controls the Future Who Controls the Present Controls the Past Nothing

Who Controls the Past Controls the Future Who Controls the Present Controls the Past Nothing

Who Controls the Past Controls the Future Who Controls the Present Controls the Past Nothing gives rest but the sincere search for truth. -Pascal Greetz from Room 101 Kenneth Geers 1984 # Nineteen Eighty-Four (Orwell) # Govt IW vs own

1.03k views • 77 slides
PAST, PRESENT AND FUTURE OF APIS FOR MOBILE AND WEB APPS Once upon a time We tried to connect

PAST, PRESENT AND FUTURE OF APIS FOR MOBILE AND WEB APPS Once upon a time We tried to connect

Ole Lensmar CTO SmartBear Software PAST, PRESENT AND FUTURE OF APIS FOR MOBILE AND WEB APPS Once upon a time We tried to connect (early 90:ies) Multiple protocols / initiatives DCE/RPC (OSF) CORBA (OMG) COM / DCOM

621 views • 48 slides
a review of the evidence Maarten Goos The past, present and future The past (1820-1980):

a review of the evidence Maarten Goos The past, present and future The past (1820-1980):

How the world of work is changing: a review of the evidence Maarten Goos The past, present and future The past (1820-1980): Industrial Revolution results in skill-upgrading and decreasing inequality . The present (after 1980):Computer

337 views • 18 slides
Past, present, future and what impact they will have on the Art of Amateur Radio. also cats.

Past, present, future and what impact they will have on the Art of Amateur Radio. also cats.

Past, present, future and what impact they will have on the Art of Amateur Radio. also cats. What is Software Defined Radio? Software-defined radio (SDR) is a radio communication system where components that have been typically

452 views • 15 slides
The past, present and future of Monte Carlo methods (a personal experience) Scott A. Sisson

The past, present and future of Monte Carlo methods (a personal experience) Scott A. Sisson

Australian Centre of Excellence for Mathematical and Statistical Frontiers in Big Data, Big Models, New Insights The past, present and future of Monte Carlo methods (a personal experience) Scott A. Sisson UNSW Sydney &amp; ACEMS 8th12th

867 views • 71 slides
Yhc: Past, Present, Future Neil Mitchell The Past Started by Tom, fork of nhc He

Yhc: Past, Present, Future Neil Mitchell The Past Started by Tom, fork of nhc He

Yhc: Past, Present, Future Neil Mitchell The Past Started by Tom, fork of nhc He didnt tell anyone! Some students found out Me, Andrew, Mike, Bob Started helping seemed fun Never an official York project The

266 views • 5 slides
Past, present and future of CSCL Gerry Stahl 3 Parts of Talk Past:TheRootsofCSCL

Past, present and future of CSCL Gerry Stahl 3 Parts of Talk Past:TheRootsofCSCL

Past, present and future of CSCL Gerry Stahl 3 Parts of Talk Past:TheRootsofCSCL (expandingvision) Present:Alternativeapproaches withinCSCL (multiple analytic voices)

625 views • 33 slides
Future of Philanthropy: Trends to Watch Those who only look to the past or present are

Future of Philanthropy: Trends to Watch Those who only look to the past or present are

Future of Philanthropy: Trends to Watch Those who only look to the past or present are certain to miss the future. -John F. Kennedy Huge Leaps in Health Civil Society Freedoms Challenged Growth of Impact Investing Equity as a Superior

424 views • 16 slides
The Past, Present, and Future of the R Project Kurt Hornik Kurt Hornik useR! 2008 The Past,

The Past, Present, and Future of the R Project Kurt Hornik Kurt Hornik useR! 2008 The Past,

The Past, Present, and Future of the R Project The Past, Present, and Future of the R Project Kurt Hornik Kurt Hornik useR! 2008 The Past, Present, and Future of the R Project Prehistory of R: S v1 19761980 Honeywell GCOS,

649 views • 29 slides
30 Years of Regression Testing: Past, Present and Future Jean Hartmann Test Architect Office

30 Years of Regression Testing: Past, Present and Future Jean Hartmann Test Architect Office

30 Years of Regression Testing: Past, Present and Future Jean Hartmann Test Architect Office Client Services - Test What is Regression Testing? From Wikipedia: Software testing that seeks to uncover new software bugs or regressions in

498 views • 13 slides
Language and Framework Requirements for Adaptation Models 6th International Workshop on

Language and Framework Requirements for Adaptation Models 6th International Workshop on

Language and Framework Requirements for Adaptation Models 6th International Workshop on Models@run.time Wellington, New Zealand, October 17, 2011 Thomas Vogel and Holger Giese System Analysis and Modeling Group Hasso Plattner Institute

273 views • 23 slides
Welcome Email: raju.chiluvuri1@gmail.com Cell: +(91)99 89 121 729

Welcome Email: raju.chiluvuri1@gmail.com Cell: +(91)99 89 121 729

Welcome Email: raju.chiluvuri1@gmail.com Cell: +(91)99 89 121 729 http://real-software-components.com http://researchgate.net/profile/Raju_Chiluvuri4 http://pioneer-soft.com What is Component Based Design? Each product is divided into

328 views • 20 slides
A Survey into the Rigor of UML Use and its Perceived Impact on Quality and Productivity Software

A Survey into the Rigor of UML Use and its Perceived Impact on Quality and Productivity Software

A Survey into the Rigor of UML Use and its Perceived Impact on Quality and Productivity Software Engineering Seminar 2010 A Survey into the Rigor of UML Use and its Perceived Impact on Quality and Productivity Paper by Ariadi Nugroho and Michel

735 views • 26 slides
Lecture 5: Object Diagrams 2015-11-05 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal 5

Lecture 5: Object Diagrams 2015-11-05 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal 5

Software Design, Modelling and Analysis in UML Lecture 5: Object Diagrams 2015-11-05 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal 5 2015-11-05 main Albert-Ludwigs-Universit at Freiburg, Germany Contents &amp; Goals Last

491 views • 17 slides
Second Language Acquisition and Corrective Feedback Corrective Feedback Eva Kartchava TESL

Second Language Acquisition and Corrective Feedback Corrective Feedback Eva Kartchava TESL

Second Language Acquisition and Corrective Feedback Corrective Feedback Eva Kartchava TESL Ottawa Spring PD Event Albert Street Education Centre Form-Focused Instruction pedagogical events that occur within meaning- based approaches

774 views • 31 slides
Unit: Multicriteria decision analysis Learning goals I. General classification of strategies in

Unit: Multicriteria decision analysis Learning goals I. General classification of strategies in

Unit: Multicriteria decision analysis Learning goals I. General classification of strategies in Multi-objective Optimization based on the time of decision maker interaction. II. Ways to structure the decision making process III. What are

810 views • 43 slides
Modelling childrens experiences of online skills, opportunities and risks: a European

Modelling childrens experiences of online skills, opportunities and risks: a European

Modelling childrens experiences of online skills, opportunities and risks: a European perspective Sonia Livingstone s.livingstone@lse.ac.uk Department of Media and Communications www.sonialivingstone.net London School of Economics and

408 views • 30 slides
ISOLATION DEFENSES GRAD SEC OCT 03 2017 ISOLATION Running untrusted code in a trusted

ISOLATION DEFENSES GRAD SEC OCT 03 2017 ISOLATION Running untrusted code in a trusted

ISOLATION DEFENSES GRAD SEC OCT 03 2017 ISOLATION Running untrusted code in a trusted environment Possibly with multiple tenants Setting OS: users / processes Browser: webpages / browser extensions Cloud: virtual machines (VMs)

272 views • 25 slides

More recommend