1 / 22

Component Based Approach to Scientific Workflow Management

Component Based Approach to Scientific Workflow Management. The C.R.I.S.T.A.L. Project ( C ooperative R epositories & I nformation S ystem for T racking A ssembly L ifecycle) CERN, LAPP(Annecy), KFKI(Budapest), UWE(Bristol). ACAT 2000 Fermi National Accelerator Laboratory.

gazit
Download Presentation

Component Based Approach to Scientific Workflow Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Component Based Approach to Scientific Workflow Management The C.R.I.S.T.A.L. Project (Cooperative Repositories & Information System for Tracking Assembly Lifecycle)CERN, LAPP(Annecy), KFKI(Budapest), UWE(Bristol) ACAT 2000 Fermi National Accelerator Laboratory

  2. The Problem Domain • The design of a production & assembly control system(CRISTAL) for the construction of the CMS ECAL detector using workflow(WfM) & product data management (PDM) techniques. Nigel Baker ACAT ’2000 Presentation 2

  3. The Product Family Problem • The design of a production & assembly control system for the construction of ANY detector or system. Software Product 1 Software Product 2 Software Product 3 A collection of software systems with the same application area. Nigel Baker ACAT ’2000 Presentation 3

  4. Product Line Engineering • Product line engineering defines a generic infrastructure, reusable across a family of target products. • Requires analysis of common and variable product characteristics • defining the scope of reuse • identification of reusable components • identification of suitable level of generality. • Requires building and evolving a generic infrastructure to • support application engineering • exploit common characteristics • integrate variant and optional features Nigel Baker ACAT ’2000 Presentation 4

  5. Software Product Lines Software Engineering Institute (CMU) Pertainto Market Strategy / Application Domain Software Product 2 Software Product 3 Share an Architecture Software Product 1 Are built from Components Nigel Baker ACAT ’2000 Presentation 5

  6. History of Reuse in Computing systematic reuse adhoc reuse patterns, frameworks models components objects modules subroutines large grain reuse Nigel Baker ACAT ’2000 Presentation 6

  7. Experiences of Reuse • Our experience over the past 10 years of building Object Oriented systems is that:- • Most reuse has come from higher level design patterns (in recent years captured and described in UML) • Very little code has been reused, a small amount of class library reuse mainly in the client user interface of systems • So why so little reuse at the code level? • Because the underlying software technology moves so fast, smalltalk, C++, Java, EJB, COM+, Active X, CORBA, C# • We are in a Fashion Industry! Nigel Baker ACAT ’2000 Presentation 7

  8. Why UML Has Helped • Provides a structure for problem solving: allows to contemplate problems that won’t fit on the back of an envelope • Usually the great thing about standards is that there are lots to choose from. However UML is the universal OA&D modeling standard. Used by OMG companies and Microsoft. • UML is an OMG Standard and tightly coupled into OMG’s Distributed Object Architecture. • UML 1.1 1997, UML 1.3 1999 Nigel Baker ACAT ’2000 Presentation 8

  9. CORBA Domains CORBA Domains CORBA Domains Analysis & Design; Metadata Common Business Objects* Business Object Facility* CORBAfacilities UML Modeling Meta-Object Facility SECURITY CORBAservices Interoperability: IIOP, Asynch* Realtime*, Embedded* options Components*, Scripting* IDL Interfaces, Mappings, & ORB UML a Key Part of OMG OMA Nigel Baker ACAT ’2000 Presentation 9

  10. EC Services Tele Services Offer Loc/Trade Intermodal Shop Floor Auto Stream Control Tele Netwk Mgmt Insurance Banking E-Payment Accounting PDM MPI Medical ERP Marine Rail Dental Financial Objects Manufctring Objects Telecom Objects Healthcare Objects E-Commerce Objects Transprtation Objects BOF, basic Business Objects & Framework Horizontal CORBAfacilities CORBAservices Domains in the OMG OMA Nigel Baker ACAT ’2000 Presentation 10

  11. Metamodeling Set of constructs for OO information modelling meta types meta relations meta schemas Defines a language for specifying metamodels Defines a language for specifying a particular information domain. types type relations type schemas Domain X Domain Y Nigel Baker ACAT ’2000 Presentation 11

  12. A B C A B C What is a Design Pattern ? • A Design Pattern • is a solution schema expressed in terms of objects & classes for recurring design problems. • Describes (UML) the elements that make up the design, their relationships, responsibilities and collaborations. • Describes heuristics for use & applicability. (Not modeled in UML) Problem Solution Nigel Baker ACAT ’2000 Presentation 12

  13. What is a Design Pattern ? cont.. • A Design Pattern • Documents proven design experience • Specifies concepts above the level of individual classes and objects • Provides a common vocabulary and concept understanding. Patterns have well known names. UML 1.4 Notation Nigel Baker ACAT ’2000 Presentation 13

  14. <<framework>> What is a Framework ? • UML 1.4 draft: • A Framework specifies a reusable architecture for all or part of a system. • May include reusable classes, patterns or templates. • When specialized for a particular application then called application frameworks. Notation Nigel Baker ACAT ’2000 Presentation 14

  15. What is a Component ? • UML 1.4 draft: • A modular replacement & significant part of a system that packages implementation & exposes a set of interfaces. • It represents the physical implementation of part of the system, and may include software code( source, binary, executable) or their equivalents, such as scripts. • Typically implements one or more classes, and exposes one or more interfaces. Notation Alternative Definition A component is something that is selling really well at the moment. Nigel Baker ACAT ’2000 Presentation 15

  16. Why Components ? • Programming by assembly (manufacturing) rather than by development. • Reusing existing software parts. Allows reuse lower down the software engineering process. • Time to market • It is in fashion! Nigel Baker ACAT ’2000 Presentation 16

  17. A B C Specification to Realisation Specification • How does a class in UML become a component? • There are many ways to do it! • There are several component models (EJB, COM+, CORBA CCM).The emphasis of these models is on implementation. Realisation Nigel Baker ACAT ’2000 Presentation 17

  18. Realisation Elements <<EJBHomeInterface>> StackHome creat( ….) FindbyPrimaryKey( ...) HomeObject call <<EJBEntityClass>> StackImpl call call <<EJBRemoteInterface>> Stack PushItem( ..) PopItem(..) RemoteObject call <<EJBContextObject>> ContextObject Specification Elements EJB Example Nigel Baker ACAT ’2000 Presentation 18

  19. UML Requirements • UML model elements are required to describe • the relationship between specification and realization component constructs. • Relationship between component deployment elements and UML model elements. • UML extensions to be able to forward/reverse engineer from UML to components. Nigel Baker ACAT ’2000 Presentation 19

  20. UML Roadmap • UML 1.4 Recommendations • support components at an earlier phase of the software life cycle • Focal Class - core logic of components • AuxiliaryClass - helper classes • clarify how subsystems, components and classes are combined • UML 2.0 (2002) Roadmap • Improve notations and semantics to support component development Nigel Baker ACAT ’2000 Presentation 20

  21. Component Development Methods • Catalysis • complicated • unfocused • Unified Process • complicated • limited view of components • KobrA • product line engineering in mind • component technology compatible Nigel Baker ACAT ’2000 Presentation 21

  22. Concluding Thoughts • Component technology is still at the beginning of its adoption curve. • No mapping between UML and common component technology at the moment. • It appears that UML will evolve to meet the requirements of components. • Component based methodologies and Case Tools are work in progress. Nigel Baker ACAT ’2000 Presentation 22

More Related