Forums

by cnwep1 >> Sat, 26 Aug 2000 3:50:35 GMT

Hello,

What approach do you folks take to building modular systems using Jade? How easy is it to build 'plug and play' modules? Say you have a suite of accounting modules (sales, puchase, general ledger, inventory blah blah). How would you organise your schemas? Everything in one schema and use some kind of licencing mechanism to prevent bits of your software being used?

Currently looking at building a number of interrelated applications for a client. One of the modules will be common to the others (let's call it Parent). The others (called Brother and Sister) need to talk to Parent, and also may need to interact with each other. The client would like these built as separate 'plug and play' style projects. The idea of this is that they might sell Parent and possibly other modules (say Brother but not Sister) to other businesses. I'm not sure how you could achieve this using Jade's schema hierarchy given the requirement that Brother and Sister may need to interact. I think you'd end up putting the whole lot into a single schema (or a series of schemas with the bottom one containing applications for all the modules contained in the superschemas). Trying to build separate schemas for each module and then somehow arranging them in a suitable hierarchy so that they can interact would be a challenge.

Just wondering how you folks see the practical realities of building modular systems using Jade.

Eric in Dunedin

by Dean Cooper >> Sat, 26 Aug 2000 5:20:22 GMT

With the global instance visibility introduced in Jade 5, you can achieve a certain level of modularisation using schema inheritance. This suits modular structures where you have superschema applications that implement common functionality on common/abstract classes, and you extend these behaviours for subschema subclasses for whatever modules you need. The example I often use is that of a common TreatmentCentreSchema which implements the core behaviour for a generic medical centre, with subschema modules for different departments (eg: XRay, Oncology, Radiology, etc) plugging into the core.

Building systems in this fashion using existing schema inheritance is possible, but it takes careful up-front design of your class hierarchy and interfaces (paying particular attention to how you use subschema copy methods), and it can be difficult to retrofit into existing applications.

Schema inheritance is useful to achieve reuse and encapsulation within a system or group of co-operating applications. However, schema inheritance alone isn't sufficient to support the construction of generalised "plug and play" type modules. For this, we have the concept of packages, and design is underway on this feature. A schema will be able to export packages of classes, which will make available to other schemas the public interface of the exported classes. Schemas will be able to import and use packages from other schemas, regardless of their relative positions in the schema hierarchy (ie: there will be no requirement for an importing schema to be a subschema of the exporting schema, which effectively is the case today with inheritance). This should enable you to build frameworks of standalone package schemas that can be assembled (imported) into application schemas as required.

Dean.

by Eric Peachey >> Sun, 27 Aug 2000 1:08:53 GMT

<snip>

... we have the concept of packages, and design
is underway on this feature. A schema will be able to export packages of classes, which will make available to other schemas the public interface of the exported classes. Schemas will be able to import and use packages from other schemas, regardless of their relative positions in the schema hierarchy (ie: there will be no requirement for an importing schema to be a subschema of the exporting schema, which effectively is the case today with inheritance). This should enable you to build frameworks of standalone package schemas that can be assembled (imported) into application schemas as required.

Super smashing great!!

Any planned release date for all this good stuff?

Eric in Waitati

by Chris Power >> Tue, 24 Apr 2001 0:02:41 GMT

Date: Saturday, 14 April 2001 1:52 p.m.
Resubmitted Monday 23 April 2001
Resubmitted Tuesday 24 April 2001 - I don't know why this doesn't stick when I post it - perhaps someone is removing it, 'coz it has an attachment? 'coz it's a blackout subject? Whoa, the paranoia is real, I tell you...

I've been spending some long bus journeys commuting to work figuring out why and how Jade could use real object-oriented interfaces.

Why should Jade have interfaces? Well I am convinced that a schema hierarchy is not the best higher-level organising principle. It works moderately for some purposes and situations, but doesn't allow you to incorporate frameworks easily. Mostly these frameworks or subsystems require you to subclass classes in the framework, which is altogether too tight a form of coupling for re-use. Interfaces allow you to define a views of classes and hand out only interface references, which don't let you get at stuff you shouldn't know about. Interfaces can be implemented by classes anywhere in a class hierarchy, and this is the loose coupling required between subsystems. As an example, think of a class that you might want to simultaneously to have table-displayability and to have task-schedulability and half a dozen other things. It would simply implement the table-displayability interface and the task-schedulability interface, etc. without having to be a subclass of anything in particular.

I believe that some sort of package concept with interfaces would meet the need. Interfaces have been around OO circles for long enough and Java programmers and many C++ programmers have met them. There is support for them in Rational Rose.

How? Well, that's a long discussion I'd like to have, along with the "Why?" question, with anyone who's interested.

As a starting point for debate, I've whipped up a tiny proof-of-concept demo that shows interfaces - without the desirable changes to the development environment and language. The implementation of interfaces in this schema is very much manual, whereas it should use dialogs in the development system and hide the "implementation classes" I've had to use for mapping of method calls to methods of the implementator classes.

--

Chris Power
Email crpower@ihug.co.nz
Phone 64 (9) 818 1281

by Dean Cooper >> Tue, 24 Apr 2001 1:48:09 GMT

Schema inheritance can be used effectively to achieve reuse within related projects and teams, and many systems out there have been implemented successfully with reusable/framework code factored-out into common superschemas. However, it is not the most convenient vehicle to achieve widespread reuse across projects/teams, or to implement frameworks and modular systems (particularly where new modules or framework components have to be added to already-deployed applications).

This has been recognised, and (early) design is underway to implement both packages and interfaces in JADE.

Dean.

by Craig Shearer >> Thu, 24 May 2001 0:07:37 GMT

Hi Dean

Your last comment is interesting - presumably this will allow us to break out of a schema hierarchy for reusing stuff from other schemas.

This being so, does this mean then that certain features of the JadeSchema might become available for use in end-user applications? Features that spring to mind would be the editor window. If this were available, methods could be typed by a suitably qualified end-user/developer and have syntax color highlighting work.

Comments?

Craig.

by Dean Coooper >> Tue, 29 May 2001 5:44:24 GMT

Your last comment is interesting - presumably this will allow us to break out of a schema hierarchy for reusing stuff from other schemas.

Yes, that's the idea.

This being so, does this mean then that certain features of the JadeSchema might become available for use in end-user applications?

While packages might enable components of the JadeSchema to be exposed, that doesn't mean they will be. The intent is to provide enhanced capabilities for user schemas.

Features that spring to mind would be the editor window. If this were available, methods could be typed by a suitably
qualified end-user/developer and have syntax color
highlighting work.

Most of the editor is actually implemented in the RootSchema, as is any core functionality that needs to be available in runtime-only databases (ie: those with no development environment). Such functionality is already inherited by user schemas (because they are subschemas of RootSchema - packages aren't required), but much of it is either unpublished or unavailable (ie: restricted to system processes).

Dean.

by Chris Power >> Thu, 26 Apr 2001 19:56:17 GMT

I attached the wrong files in my previous posting - don't even try it, the demo doesn't even run.

Attached is Interfaces2.zip which comprises SCM and DDB files.
There is no application, just a JadeScript called runDemonstration.

This shows a token interaction between two objects via interfaces. Among other things, the demo illustrates
1. the point that an interface acts something like a restricted view of the methods of a class
2. that it's workable but clumsy to dummy-up interfaces; the ideal is to modify the language

--

Chris Power
Email crpower@ihug.co.nz
Phone 64 (9) 818 1281