Software development process

• US 7,000,219 B2
• Filed: 11/05/2001
• Issued: 02/14/2006
• Est. Priority Date: 11/03/2000
• Status: Expired due to Fees

• Current Assignee: Wilde Technologies Limited
• Original Assignee: Wilde Technologies Limited
• Inventors: Barrett, Stephen, Twomey, Colum, Evans, Malcolm, Higgins, Colum
• Primary Examiner(s): CHAVIS, JOHN Q
• Application Number:
  US09/985,501
• Publication Number:
  US 20020104068A1
• Time in Patent Office: 1,562 Days
• Field of Search: 717/107, 717/104
• US Class Current: 717/107
• CPC Class Codes: G06F 8/24 Object-oriented

Abstract

A flexible component-based software system is developed by generating a UML model (3) in a specification phase (4). Components are generated in an implementation phase (4). The UML model (3) is transformed to a meta model. A runtime architecture service (RAS, 10) dynamically assembles a system in runtime according to the meta model. A modelling tool (15) modifies the meta model via an API (34) and a meta modeller (31). This allows dynamic re-configuration of the system.

Claims

1. A process for development of a software system, the process comprising the steps of:

providing components, each having executable code;

providing a meta model, said meta model having a hierarchical structure, and comprising;

a type model comprising a specification of the types of components in terms of interfaces and in terms of services implemented by components, and in which the interfaces are those supported by a component and those of services that a component requires, and

an instance model for instantiating the type model;

a runtime activation service dynamically instantiating the executable code components according to the meta model by the instance model instantiating the type model; and

maintaining the meta model and dynamically modifying the system by modifying the meta model, and re-instantiating the components according to the modified meta model.

2. The process as claimed in claim 1, wherein the meta model is generated from a design model arising from a specification phase, the design model specifying the system in terms of components and their interactions.

3. The process as claimed in claim 2, wherein the design model is represented as a markup language file.

4. The process as claimed in claim 3, wherein the meta model is saved to storage by transforming it back to an associated design model in said markup language.

5. The process as claimed in claim 4, wherein the design model models the system declaratively as a graph of instances of component types and allowed interactions between them.

6. The process as claimed in claim 5, wherein the design model models a component type as an abstraction that specifies interfaces supported by a component and interfaces that a component requires.

7. The process as claimed in claim 6, wherein a component type is specified as a specialisation of another component type.

8. The process as claimed in claim 6, wherein a component type specifies how a plurality of component types may be aggregated to form a composite component type, and in which the composite component type is modelled as a template.

9. The process as claimed in claim 8, wherein channels between component instances are templated such that they can be bound to specific interface types on subsequent reuse of the templated component type.

10. The process as claimed in claim 2, wherein the meta model is generated by parsing the design model to generate a hierarchical graph of connected objects.

11. The process as claimed in claim 10, wherein the parsing generates a token stream arising from lexical analysis, the token stream representing markup language elements and attributes.

12. The process as claimed in claim 11, wherein the token stream is parsed in a plurality of passes comprising:

a syntactic parsing pass to create meta model objects;

a linking parsing pass to create links between objects based on defined bi-directional associations;

a pass to refine the objects according to stereotypes; and

a pass to perform semantic model validation for correct behaviour.

13. The process as claimed in claim 12, wherein the stereotypes include:

a component type stereotype;

a realisation stereotype to extend abstraction; and

an interface requirement stereotype.

14. The process as claimed in claim 1, wherein the meta model is modified by a modelling tool an API, the tool having a model view pattern on the meta model.

15. The process as claimed in claim 1, wherein the dynamic modification of the meta model comprises dynamically changing the number and identity of component instances, component types, and their interactions.

16. The process as claimed in claim 1, wherein the meta model is dynamically modified by generating a fresh or modified design model, transforming the design model to a meta model, and re-assembling the system according to the new meta model.

17. The process as claimed in claim 1, wherein the meta model automatically performs self type-checking before assembly of the system.

18. The process as claimed in claim 1, wherein the system assembly is performed by a technology-independent activation manager and at least one technology-specific activator, in which the activation manager directs at least one activator to:

instantiate components,

bind components, and

unbind components.

19. The process as claimed in claim 18, wherein the activation manager is an object which presents public methods for instantiating components, for binding components, and for unbinding components, and in which the activation manager instantiates technology-specific components by:

retrieving a technology identifier;

searching a list of currently instantiated technology-specific activators and identifying one having the same technology identifier; and

said activator instantiating a component.

23. A computer program product comprising software code for performing the step of claim 1 when executing on a digital computer.

20. A process for development of a software system, the process comprising the steps of defining a meta model and using the meta model to generate executable code, characterised in that,

the process comprises a step of storing components each having executable code;

the meta model has a hierarchical structure defining how a system is to be assembled by instantiating components in runtime;

the system is assembled by dynamically instantiating the components in runtime according to the meta model;

the meta model is generated from a design model arising from a specification phase, the design model specifying the system in terms of components and their interactions;

the meta model is maintained and the system is dynamically modified by modifying the meta model and re-instantiating the components according to the modified meta model, wherein the meta model is modified by a modelling tool and an API, the tool having a model view pattern on the meta model.

21. A software system comprising:

components having executable code,

an adapter for generating a meta model from a design model, the meta model defining how the components are to be instantiated in runtime, and comprising;

a type model comprising a specification of the types of components in terms of interfaces and in terms of services implemented by components, and in which the interfaces are those supported by a component and those of services that a component requires; and

an instance model for instantiating the type model;

a meta modeller for maintaining the meta model;

a runtime activation service for dynamically instantiating the executable code components according to the meta model by the instance model instantiating the type model;

a modelling tool for interacting with the meta modeller to modify the meta model; and

means in the runtime activation service for re-instantiating the components according to the modified meta model to modify the system.

22. The system as claimed in claim 21, wherein the activation sub-system comprises a technology-independent activation manager and at least one technology-specific activator, in which the activation manager comprises mean for directing at least one activator to:

instantiate components,

bind components, and

unbind components.