We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byEvan Monroe
Modified over 2 years ago
Page 1 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG© März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG To Boldly Go Where No IDE Has Gone Before Component-Based Development with Eclipse – A Tangible Vision Thorsten Fink, Ph.D. Wolfgang Metzner GmbH & Co KG
Page 2 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Starting with a quote The plug-in extension model of Eclipse provides a powerful and general paradigm for architecting extensible systems based on loosely-coupled components. [Bolour]
Page 3 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Background We agree with the quote, but at the same time believe that the Plugin Development Environment has much more to offer than a paradigm. Because: PDE is the only IDE known to us which offers real support for component-based development. The developers of Eclipse had to overcome many obstacles, in order to produce a component-based software. So they created their own development environment (PDE). Developers of Java applications face similar problems when trying to develop component-based applications. Todays reality is that component-based development is frequently given up in favor of monolithic development. One of the reasons being that todays IDEs do not offer sufficient support in that direction. This is where our vision starts!!
Page 4 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG The Vision Our vision is an extension of the Eclipse Java Development Environment (JDT) offering the following functionality Component dependencies by id and version Manifest Files for components, modules, applications --and editors for these JDT offers infrastructure classes that can used in the application (supporting component extensions) Direct support of components, modules (couple of components) and applications (couple of modules) Build takes component dependencies into account, validates, that all necessary component configurations are in place, automatically creates a property file (left-hand side only) with all parameters needed by the components Components communicate the way in which they can be parametrized, configured and extended in their manifest files
Page 5 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Component Hierarchy: An Example ain ain-clientain-persistence dbo.coredbo.ain util client.coreclient.ain Component Module Application enthält hängt ab An application consists of modules which in turn consist of components. Only components can be extended and configured (by other components). In our example dbo.ain configures the component dbo.core.
Page 6 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Manifest Files (in a Nutshell) Each component has a manifest file with the name component.xml A component is what today is an Eclipse Project. The manifest file component.xml contains the following information. main information: id, name, version dependencies on other components runtime information: name of the component jar (and possibly other jars) parameter information: which parameters are necessary to parametrize this component (e.g. database url)? configuration information: how can this component be configured by one and only one other component? An example would be metadata in an xml instance document. listener-point: which listener can be registered with this component? listener registration: welche Listener are registered with another component? Possibly other extensions and uses thereof
Page 7 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Component Manifest: Example
Page 8 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Component Manifest: Example (ctd)
Component Manifest: Example (ctd)">
Page 9 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG component.xml: the elements Main information component-id : unique id of the component component-name : name of the component component-version : version of the component requires : dependencies on other components (referring to id and version) runtime : name of the build jar (and possibly other jars) param-point : name of parameters needed by this component. Using these parameter names a property file for the application will be created (or validated) configuration-point : name of a file used in the configuration of this component. The component itself does not contain the file. In the context of an application or a module there is exactly on other component configuring this component (see: next element configuration ) configuration : location of the configuration file used in the configuration of another component.
Page 10 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG component.xml: the elements (ctd) startup : classes which are instantiated at the time of application startup. After instantiation their method initalize(Properties properties) will be called. listener-point : this is where other components can register their listeners. listener : here a component declares that it registers a listener at anothers component listener-point. There might very well be other extension elements. We would prefer to concretely model these elements (as weve done in the case of listener-point and listener). This way important features of the communication between components do not get lost in general extension- point, extension pairs. We believe that in the case of applications a restriction to a few selected forms of communication should be possible.
Page 11 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: An Overview The manifest files of the components, modules and applications are used in the build process – internally by Eclipse as well as externally by Ant. Well only consider the Eclipe build process (but see: Appendix). Dependency analysis and use In the case of inconsistences, problems (tasks) are created. Examples for inconsistencies are a component of the referenced version is not available. references to different versions of the same component exist within a module or an application. a configurable component is not (or more than once) configured within the context of a module or an application. All components are build as specified in the manifest files. The parameters (in param ) are written to a property file. The startup information (in startup ) is collected in a startup.xml. The file is used during application startup.
Page 12 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: An Overview (ctd) Additional information is collected for use by the infrastructure classes The exact process and the functionality of the infrastructure classes is to be determined. The infrastructure classes are used by Eclipse and by the Java application.
Page 13 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: Component Parametrization The param elements of all components of a given application are collected during the build process. A property file will be created or a given one will be validated (completeness) on their basis. component.xml Application.properties – left-hand sides are created ## Parameters of component: dbo database.url= database.user= database.password=
Page 14 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: Component Configuration A component may specify that it can (and should) be configured by an XML instance document. In the context of a module or an application, one and only one other component configures the above component. The component doing the configuration contains the required XML instance document.
In the context of a module or an application, one and only one other component configures the above component. The component doing the configuration contains the required XML instance document. ">
Page 15 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Modules Modules consist of (configured) components. Modules cannot be configured. They are described by manifest files with the name module.xml.
Page 16 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Applications Applications consist of modules and possibly (configured) components. Applications cannot be configured. They are described by manifest files with the name application.xml.
Page 17 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Outlook There are many obstacles to overcome and gaps to fill in on the way to a complete support of component-based development. We believe that the route outlined in this document is promising and can be taken. Selected functionality could possibly be migrated from PDE to JDT or quickly implemented by Monkey See, Monkey Do. Pleasant side effects should not go unmentioned Reverse Engineering of Component Diagrams on the basis of manifest files, and other yet undiscovered possibilities. Architects can be sure that their architecture is reality. Developers, designers can base their discussions also on the content of manifest files. A heigthened appeal to create product-independent or platform- independent components (which will have a higher degree of re-usability).
Page 18 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Literature [Bolour] Azad Bolour, Notes on the Eclipse Plug-in Architecture, in: Eclipse Corner Article, Juli 2003http://www.eclipse.org/articles/index.html [Gamma, Beck] Erich Gamma, Kent Beck, Contributing to Eclipse, Addison-Wesley, 2004
Page 19 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Appendix: Build Management The vision for the build management is as follows In order to build an application you only need access to the configuration management system (CMS), as well as a manifest file application.xml The build process pulls the needed components in their correct version from the CMS, validates the component dependencies and starts the application build during which property and startup files are created components are configured Infrastructure classes (for e.g. listener registration) are build
Software Engineering Model Driven Architecture Software Engineering 2011 Department of Computer Science Ben-Gurion university Based on the book: MDA Explained:
1 Computer Systems & Architecture Lesson 3 5. Designing the Architecture.
Copyright (c) . Roger L. Costello. All Rights Reserved. 1 REST (Representational State Transfer) Roger L. Costello XML Technologies Course.
Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK
Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Software Re-use IS301 – Software.
aQute Bundle Programming By Peter Kriens CEO aQute OSGi Director of Technology & OSGi Fellow.
Chapter 5: Distributed systems with JAVA: sockets, RMI, Threads Rufin Soh Wilfried Probst – Rufin Soh INE4481 DISTRIBUTED DATABASES & CLIENT-SERVER ARCHITECTURES.
Nica Valentin–Danut SEM 2012 Service system fundamentals: Work system, value chain, and life cycle.
Executional Architecture Lecture Conceptual vs execution Conceptual Architecture Execution Architecture Component Connector Domain-level responsibilities.
Lecture 6: Software Design (Part I) Dr Valentina Plekhanova University of Sunderland, UK
Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Introduction to Computer Science I Topic 11: Introduction.
Page 1 LAITS Laboratory for Advanced Information Technology and Standards Duh 7/10/03 Geospatial Service Workflow Concepts and Tools Liping Di Laboratory.
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
Information Systems Analysis and Design. Systems Modeling Enterprise Model graphically represents organizational entities and the relationships between.
Chapter 7 – Design and Implementation 1Chapter 7 Design and implementation Note: These are a modified version of Ch 7 slides available from the authors.
S-100 PORTRAYAL MODEL DIPWG-2 May TSMAD20/DIPWG2-08.1A.
Architectural Design IS301 – Software Engineering Lecture # 14 – M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University.
Project Management in Team Software Projects The primary challenge of project management is to achieve all of the goals of the project charter while adhering.
AQute R4 By Peter Kriens CEO aQute OSGi Technology Officer and OSGi Fellow.
Using T4Eclipse tool to Analyze Eclipse UI For t4eclipse version Ben Xu July 17,2010.
1/23/2014 9:52 AM SOA4HL7: Defining Services based on HL7 Messaging Artifacts Alan Honey, Kaiser Permanente Enterprise Architect (Based on material initially.
1 The Arena modeling system is a flexible and powerful tool that allows analysts to create animated simulation models that accurately represent virtually.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Component-Based Software Engineering.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 1 Chapter 29 Configuration Management.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps Unit - II.
Adding User Interactions actionscript 3.0. Common event-handling tasks Writing code to respond to events Stopping code from responding to events Working.
© 2017 SlidePlayer.com Inc. All rights reserved.