Software development process

• US 20020104068A1
• Filed: 11/05/2001
• Published: 08/01/2002
• Est. Priority Date: 11/03/2000
• Status: Active Grant

• Current Assignee: Wilde Technologies Limited
• Original Assignee: Wilde Technologies Limited
• Inventors: Barrett, Stephen, Twomey, Colum, Evans, Malcolm, Higgins, Colum
• Granted Patent: US 7,000,219 B2
• Time in Patent Office: Days
• US Class Current: 717/104
• 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 defining a meta model and using the metal model to generate executable code, characterised in that,

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

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

the system is completed by dynamically instantiating the components in runtime according to the meta model.

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

10. A 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. A 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. A 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. A 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. A process as claimed in claim 1, wherein the meta model comprises:

a type model comprising a specification of the types of components; and

an instance model which instantiates the type model set into runtime components.

15. A process as claimed in claim 14, wherein the type model specifies component types 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 component requires.

16. A process as claimed in claim 1, comprising the further step of 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.

17. A process as claimed in claim 16, wherein the meta model is modified by a modelling tool (15) and an API (33), the tool having a model view pattern on the meta model.

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

19. A process as claimed in claim 16, 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.

20. A process as claimed in claim 14, wherein the meta model automatically performs self type-checking before assembly of the system.

21. A 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.

22. A process as claimed in claim 21, 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.

25. A system as claimed in claim 24, wherein the system further comprises a modelling tool (15) comprising means for interacting with the meta modeller (31) to modify the meta model, and the activation sub-system (32) comprises means for re-instantiating the components for dynamic modification of the system.

26. A system as claimed in claim 24, wherein the meta modeller (31) comprises means for maintaining the meta model with:

a type model comprising a specification of the types of components; and

an instance model which instantiates the type model set into runtime components.

27. A system as claimed in claim 24, 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.

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

3. A process as claimed in 2, wherein the design model (3) is represented as a markup language file.

4. A 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. A process as claimed in claim 4, wherein the design model (3) models the system declaratively as a graph of instances of component types and allowed interactions between them.

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

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

8. A 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. A 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.

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

the process comprises a step of storing components (8) 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 (3) arising from a specification phase (2), the design model (3) specifying the system in terms of components (8) and their interactions;

the meta model is maintained (31) 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 (15) and an API (33), the tool having a model view pattern on the meta model.

24. A software system comprising components having executable code, characterised in that the system further comprises:

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

a meta modeller (31) comprising means for maintaining a meta model during runtime;

an activation sub-system (32) comprising means for dynamically instantiating the components in runtime according to the meta model.