220 likes | 332 Views
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.
E N D
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
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
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
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
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
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
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
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
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
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
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
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
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
<<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
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
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
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
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
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
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
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
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