aeonic-devs — The main list for developers to discuss project development issues/artifacts

[Aeonic-devs] pyswarm is now Aeonic

[Anastasios H. <an...@ha...>]

Hi everyone!

With the revamped software design of our model-driven dev tool, and the
renaming from pyswarm to Aeonic officially effective today, I want to
let you know, that project resources have been changed, too.

Trac has been added and can be found here:
http://sourceforge.net/apps/trac/aeonic

The old bug and feature trackers have been deleted, and tickets are
managed in Trac now.

The mailing lists only changed their names and addresses.  Subscriptions
are not effected.

Greetings,
Anastasios

[pyswarm-devs] Test - please ignore

[Anastasios H. <an...@ha...>]

pyswarm is alive! :-)

[pyswarm-devs] SVN rev 671: Constraints diagram; Bugfixes

[Anastasios H. <an...@ha...>]

> Revision: 671
>           http://pyswarm.svn.sourceforge.net/pyswarm/?rev=671&view=rev
> Author:   pyswarmgeek
> Date:     2009-05-03 19:00:39 +0000 (Sun, 03 May 2009)
>
> Modified Paths:
> --------------
>     branches/dev/playground/pyswarmgeek/UML.Superstructure.08-05-12.xml

Hi Animesh

> 1) Constraints diagram of the Kernel package

Constraint::constrainedElement : Element
Fix [0..1] to [0..*]
Fix "-" to "+"

On opposite side:
Fix [0..1] to [0..*]

Constraint::specification : ValueSpecification
Fix [0..1] to [1..1]

> 2)Corrected for Expressions diagram  bug:  InstanceValue::instance has to
> be [1..1], not [0..1] 

Expressions diagram: OK

> 3)Corrected Namespace Diagram for Typos and two 
> multiplicities.
>

New bug in PackageImport::importingNamespace : Namespace
Please set aggregation back again to "composite", since that got lost somehow

Open: A_importedElement_elementImport and A_importedPackage_packageImport
The properties in these associations are still at the wrong sides of the 
associations.  Please check the narrative specs for ElementImport, Package, 
PackageableElement and PackageImport.  The Namespaces diagram won't help you 
here since the layout is overstuffed at these areas.

Other bugs in Namespaces diagram are fixed. Many thanks.

Anastasios

[pyswarm-devs] SVN rev 670: Expressions diagram

[Anastasios H. <an...@ha...>]

> Revision: 670
>           http://pyswarm.svn.sourceforge.net/pyswarm/?rev=670&view=rev
> Author:   pyswarmgeek
> Date:     2009-05-01 11:14:37 +0000 (Fri, 01 May 2009)
>
> Log Message:
> -----------
> Committed "Expressions diagram of the Kernel package"
>
> Modified Paths:
> --------------
>     branches/dev/playground/pyswarmgeek/UML.Superstructure.08-05-12.xml

Hi Animesh,

there is only a single bug in the Expressions diagram here:

InstanceValue::instance : InstanceSpecification
[0..1] is wrong, correct would be [1..1]

Seems to me that you are getting routine :-)

Anastasios

[pyswarm-devs] SVN rev 669: Multiplicities diagram

[Anastasios H. <an...@ha...>]

> Revision: 669
>           http://pyswarm.svn.sourceforge.net/pyswarm/?rev=669&view=rev
> Author:   pyswarmgeek
> Date:     2009-05-01 07:30:26 +0000 (Fri, 01 May 2009)
>
> Log Message:
> -----------
> Committed for "Multiplicities diagram of the Kernel package" .
>
> Modified Paths:
> --------------
>     branches/dev/playground/pyswarmgeek/UML.Superstructure.08-05-12.xml

Animesh, this diagram was OK.  Thank you! :-)

Anastasios

[pyswarm-devs] SVN rev 668: Namespaces diagram

[Anastasios H. <an...@ha...>]

Hi Animesh

> Revision: 668
>           http://pyswarm.svn.sourceforge.net/pyswarm/?rev=668&view=rev
> Author:   pyswarmgeek
> Date:     2009-04-28 14:40:15 +0000 (Tue, 28 Apr 2009)
>
> Log Message:
> -----------
> Added Missing Property Modifiers.
>
> Modified Paths:
> --------------
>     branches/dev/playground/pyswarmgeek/UML.Superstructure.08-05-12.xml
>
> Modified:
> branches/dev/playground/pyswarmgeek/UML.Superstructure.08-05-12.xml

Many thanks for adding the missing modifiers.  Looks much better now :-)

All added modifiers were correct, good work.  Modifiers are missing here:

Namespace::importedMember : PackageableElement
Namespace::member : NamedElement

If you find the time, please also fix the open issues in Namespaces diagram as 
posted regarding rev 667.  It seems we can soon proceed with the other 
diagrams in Classes::Kernel.

Thank you!

Anastasios

[pyswarm-devs] Meta-properties of properties (in MagicDraw)

[Anastasios H. <an...@ha...>]

This is a summary about properties used in figures of the UML 2.2 
specification, and which are needed to specify the UML 2.2 metamodel as a 
MagicDraw 16.0 model.

For any comments or questions, please post.  Thank you.


Property-modifiers are meta-properties of properties.  They are shown in curly 
brackets, e.g. {readOnly, ordered}.

In UML Superstructure 2.2 beta1, see section "7.3.44 Property (from Kernel, 
AssociationClasses)" for the details.

In order to specify property-modifiers or any other meta-property of 
properties shown in a model, in MagicDraw 16 you can either double-click on a 
property, or select a given property and press Enter key, or right click the 
property and select "Specification" from the context menu.  Please see 
attached screenshot for the Specification dialog in view mode Expert.

In the Specification dialog, on the right pane you see all meta-properties of 
the current element, e.g. Name (name), Type, Visibility.

On the right upper part of the main pane in the field "Properties" you can 
switch the mode in order to see less or more properties in the main pane.  
Modes are "Standard", "Expert" and "All".  By default, the "Expert" mode 
shows all meta-properties that are needed for modeling the UML metamodel.  By 
clicking on the "Customize" button on the right, you can customize which 
meta-property is shown in which view mode.



Here is the list of all important meta-properties (based on MOF/UML core) and 
their labels in MagicDraw's specification dialog:

Name:
Corresponds to the meta-prop NamedElement::name : String  [0..1]
Just enter a string into the field.


Type:
-> TypedElement::type : Type  [0..1]
You can choose one type from all types known in the model.


Visibility:
-> NamedElement::visibility : VisibilityKind  [0..1]
For modeling the UML metamodel always choose "public", which is denoted with 
a "+" symbol, e.g. "+name"


Default Value:
-> Property::defaultValue : ValueSpecification [0..1]
AFAIR, there are no default-value specified for properties used inside the UML 
metamodel.  Default values are denoted with "=" and the value-specification, 
e.g.:
greet : String = "Hello world!"


Navigable:
Check this when property is navigable or uncheck if non-navigable.  
Eventually, MagicDraw will reassign owner of the property.  This information 
does only indirectly correspond to the meta-prop Property::/isNavigable() : 
Boolean
For usability reasons MagicDraw allows to define the navigability directly and 
then, based on that checkbox, cares for correct ownership, instead of forcing 
the user to assign the ownership and have the navigability computed.
In association-end properties, a navigable property is denoted with an arrow.  
Optionally, a non-navigable property is denoted with an "X" on the line.  
When both ends are navigable, the arrows can be suppressed.
Attribute-based properties are always navigable from the owner (class) to the 
owned attribute (property).


Multiplicity:
Spans over two meta-props:
MultiplicityElement::lowerValue : ValueSpecification [0..1]
MultiplicityElement::upperValue : ValueSpecification [0..1]

When diagram shows "*" for a multiplicity element, this is a short notation 
for [0..*], where the asterisk represents an UnlimitedNatural; if it 
shows "1" that is short notation for [1..1], if "0" than [0..0]

When the multiplicity of an attribute-based property is suppressed in a 
diagram, than it means [1..1], as so for all attributes that have a Boolean 
as type.


Is Ordered:
-> MultiplicityElement::isOrdered : Boolean [1..1]
If checked, then items in collection are managed in a certain sequence and 
property-modifier is denoted as {ordered}


Is Unique:
-> MultiplicityElement::isUnique : Boolean [1..1]
If checked, then items in collection may appear only once.  All properties in 
UML metamodel, that I can remember of, are unique.  If a property is not 
unique, denoted with {nonunique}, uncheck this box.


Is Read Only:
-> StructuralFeature::isReadOnly : Boolean [1..1]
Check this box, when property is denoted with {readOnly}
This means that the property can only be written during instantiation (object 
creation), not after that.


Is Derived:
-> Property::isDerived : Boolean [1..1]
Check this box, when property name begins with a "/" symbol, e.g. "+/lower"
Values of derived property are computed, eventually a constraint defines the 
how.


Is Derived Union:
-> Property::isDerivedUnion: Boolean [1..1]
Check this box, when property is denoted with {union}
Values of derived-union property are computed by a union of sub-sets.  Such 
property usually is subsetted by other property.

Also note:  derived-union implies derived, and derived implies read-only


Aggregation:
-> Property::aggregation : AggregationKind [1..1]
Choose the "none", "shared", or "composite".  A solid black diamond in an 
association represents an aggregated association with ownership.  The diamond 
is attached on the border of the owner class.  A diamond in an association 
represents an aggregated association with no ownership.  The diamond is 
attached on the border of the aggregated class.  Associations with no diamond 
is of kind "none".


Subsetted Property:
-> Property::subsettedProperty : Property [0..*]
Denoted as {subsets foo}
Click the "..." button which opens the model tree.  Browse to the property (or 
properties) and select those that are subsetted by this property.  Since in 
the figures of the UML 2.2 Superstructure spec only the property-name is 
shown, see the narrative details for the qualified name of any subsetted 
property.


Redefined Property:
-> Property::redefinedProperty : Property [0..*]
Denoted as {redefines foo}
Click the "..." button which opens the model tree.  Browse to the property (or 
properties) and select those that are redefined by this property.  Since in 
the figures of the UML 2.2 Superstructure spec only the property-name is 
shown, see the narrative details for the qualified name of any redefined 
property.

[pyswarm-devs] SVN rev 667

[Anastasios H. <an...@ha...>]

Hi Animesh,

> Revision: 667
>           http://pyswarm.svn.sourceforge.net/pyswarm/?rev=667&view=rev
> Author:   pyswarmgeek
> Date:     2009-04-26 19:45:21 +0000 (Sun, 26 Apr 2009)
>
> Log Message:
> -----------
> Added "Namespaces diagram of the Kernel package"
>
> Modified Paths:
> --------------
> branches/dev/playground/pyswarmgeek/UML.Superstructure.08-05-12.xml

Thank you.  I've verified the Namespaces diagram which you have added at this 
commit.

All classes/enumerations in diagram: OK
Generalizations: OK
Attributes: On hold
Operations: On hold
Constraints: On hold

Regarding associations:
As we have talked, property-modifiers are ignored in this revision.

There were few errors though.  It seems to me that some of them are because 
figure 7.4 of the Superstructure 2.2 spec is really stuffed, so it is 
sometimes not clear in diagram to which element a text belongs.  In those 
situations please double-check with the narratives shown after the diagrams.

Namespace::importedMember : PackageableElement
The multiplicity [0..*] is missing.  You assigned it to the property on the 
opposite side, which is not navigable, so there is no property and no 
multiplicity meaningful.

ElementImport::importingNamespace : Namespace
Multiplicity should be [1..1], not [0..1]
Name should be importingNamespace *)

PackageImport::importingNamespace : Namespace
Multiplicity should be [1..1], not [0..1]
Name should be importingNamespace *)

ElementImport::importedElement : PackageableElement
Name on wrong side of association
Multiplicity should be [1..1], not [0..1]

PackageImport::importedPackage : Package
Name on wrong side of association
Multiplicity should be [1..1], not [0..1]

In the associations A_importedElement_elementImport (between ElementImport and 
PackageableElement) and A_importedPackage_packageImport (between 
PackageImport and Package), for some reason figure 7.4 shows multiplicities 
for the non-navigable properties (both on the left ends of their 
associations).  I think this is a bug in the spec.  I suggest you remove both 
multiplicities on the non-navigable side.

*) UML specification uses for properties the naming convention first letter 
lower-case (just for MOF/UML, user models may differ).  In figure 7.4, you 
see that attribute NamedElement::Name starts with upper case, but this is a 
bug in the diagram.  The narrative uses the correct lower-case ("name").


OK, that's it. :-)

Regarding the specification of property-modifiers in MagicDraw, I will post a 
seperate mail.

Anastasios

[pyswarm-devs] Draft for UML library

[Anastasios H. <an...@ha...>]

I've uploaded a draft of the pyswarmU2L documentation.  It includes a tutorial 
which describes features of the pyswarm UML 2.x lib, and shows examples how 
client implementations can use them.

http://pyswarm.wiki.sourceforge.net/U2L+Overview

Available as PDF and XHTML pages.  The docbook files are in the SVN 
repository, see commit rev. #659 and #660.

I hope, the examples are helpful to find the best implementation.  As far as 
I've seen a couple of weeks ago at the first implementation of the library, 
there were too many patterns that could be used for the implementation of the 
UML metamodel (metaclasses, decorators, ...).  Thus I had some issues to 
decide for one of them, and so I wrote this tutorial.

I think it is generally a good idea, because the tutorial describes the 
use-cases and it gives everyone a chance to suggest features changes or 
improvements, as well as give advice for the later implementation of the lib.

Animesh Kumar, who joined the project team recently, meanwhile works on the 
metamodel XMI --based on the recent UML 2.2 beta specification-- which will 
be used to generate the complete metamodel package of the library.  For doing 
so, only a small part of the metamodel (especially Kernel) needs to be 
implemented manually, based on the patterns for which we go now, before the 
UML library combined with the ADK is kind of "self-reflecting".  New 
metamodels can be added rather easily.

Any question / comment / advice is welcome.

Thanks.

Anastasios

[pyswarm-devs] MDA vs. MDA-light

[Anastasios H. <an...@ha...>]

I've found this general introduction to MDA. See slide 15 for a comparison of 
MDA (pyswarm 1.0) to MDA-light (pyswarm 0.7):

http://www.ida.liu.se/~chrke/courses/SWE/F13-MDA.pdf

Regards,
Anastasios

[pyswarm-devs] Python UML library and more about pyswarm redesign

[Anastasios H. <ah...@ha...>]

Hi,

there is progress with redesigning pyswarm technology, though I'm slower than 
I expected. Following a brief update on the recent work I have done and the 
future steps to be taken. The biggest job was to re-invent pyswarmSDK as the 
pyswarmADK (AKD = Architecture Development Kit). It seems to me that 
pyswarmADK will strongly improve future development of pyswarm software.

After finishing the redesign, there will be three separate programs with 
specific tasks:

- pyswarmSDK will be the tool with which an user can create pyswarm-based 
applications that are generated from UML models.
- pyswarmU2L will be a library for working with UML models and can be used by 
pyswarmSDK and other tools as well.
- pyswarmADK will be the tool that can generate pyswarmU2L and future versions 
of pyswarmSDK.

The separation reduces the complexity we face in this project, so any 
contributor could focus on special topics. pyswarmU2L is the foundation for 
pyswarmSDK and it covers UML2, which already is a well specified standard. So 
this lib would already offer a good chance for any expert to join the work. 

Please let me know if you are interested to bring in your expertise into 
pyswarmU2L. Especially helpful would be skills regarding Python, UML, XMI, or 
XML in general.


1. pyswarmADK:
This tool has its origins in pyswarmSDK v. 0.7.1. I have modified the code, so 
pyswarmADK will be able to generate pyswarmSDK and pyswarmU2L. Actually, 
pyswarmADK is only useful for developers of pyswarmSDK and pyswarmU2L.

Status:
a) Not specified in a model itself, but uses pyswarmADK/resources/pyswarm.xml 
as input for generating pyswarmSDK and pyswarmU2L.
b) Replaced old SDK's parser package with a light-weight UML2 library that can 
parse pyswarm.xml in the format as produced by MagicDraw UML 11.0.
c) Since this mini-UML2 lib is sufficient to create pyswarmU2L (which supports 
larger parts of UML2), theoretically it would be possible later to replace 
this lib by an early prototype of pyswarmU2L.
d) The transformation is incomplete, so the model pyswarm.xml is consumed but 
not transformed into code yet.
e) License will be same as pyswarmSDK, exception: any code template used for 
generating pyswarmU2L will have that license.


2. pyswarmSDK:
Purpose as in v. 0.7.1 and earlier: reads user domain models (PIM), and after 
transforming them to PSMs, generates the source-code and documentation of the 
domain application. The new pyswarmSDK will use the pyswarmU2L library for 
all UML-/XMI-related jobs.

Status:
a) Advanced progress in modeling the pyswarmSDK::pim package; some progress in 
pyswarmSDK::psm and pyswarmSDK::tdm packages. pim, psm and tdm will play the 
biggest role when pyswarmADK is generating the SDK. The other packages are 
more for documentation purpose currently, less for generating the SDK code.
b) No code-templates yet
c) No running code yet
d) GPL v3 or AGPL v3 are my favorite candidates for licensing this tool (have 
been GPLv2 at pyswarmSDK 0.7.1)


3. pyswarmU2L:
A Python UML library based on UML Superstructure specification v. 2.1.2. It 
can be used by tools (pyswarmSDK or any UML tool) to import an XMI file as 
UML model, work on an UML model (e.g. adding classes, associations, removing 
attributes, changing operation signatures), and export an UML model to XMI.

Different XMI formats should be supported, so a tool that will use pyswarmU2L 
could convert UML models from one XMI format to another XMI format. The UML 
meta-model (that is specified in the UML Superstructure Spec) is covered by 
the pyswarmU2L::meta package. The meta package is the foundation package and 
will play the biggest role when pyswarmADK is generating the pyswarmU2L 
library code. The package pyswarmU2L::xmi will contain specification for 
mapping the different XMI formats to the underlying UML model specified in 
pyswarmU2L::meta. In the best case, any supported XMI format could be used to 
import an UML model and export it to any supported XMI format.

Status:
a) Model covers entire UML::Classes package, all other packages of UML are 
missing yet in pyswarmU2L::meta, however they will all look the same way as 
UML::Classes. I expect that most work will be the pyswarmU2L::xmi package 
with all its XMI compatibility issues in the tiny details.
b) No code-templates yet
c) No running code
d) LGPL v3 is my current favorite candidate for licensing this lib


BTW, you can find the relevant code in the repository at
http://pyswarm.svn.sourceforge.net/viewvc/pyswarm/branches/dev/features/1980652_ADK-based-SDK/src/adk/

Please note that documentation is not udpated. Most important is the 
pyswarmADK/resources/pyswarm.xml which you should be able to open at least 
with MagicDraw 11.0 or any newer version. I will try to upload an HTML report 
of the model to the webspace.

Any questions or comments, please drop me a note. :)

Anastasios

[pyswarm-devs] Generating the generator

[Anastasios H. <ah...@ha...>]

Hi,

especially with the use-cases and activities I did understand that I want the 
SDK earlier and some much easier way to make the modifications on it that 
will be necessary.

Let it be, just to have a better base for discussing several features and 
aspects of pyswarm SDK and the runtime architecture of generated apps.

So, I came back to the generate-the-generator idea. And I think it looks very 
promising. Please see the wiki with some examples around the PIMs, PSMs and 
the model transformations, which are the core of the SDK anyway:
http://pyswarm.wiki.sourceforge.net/PIM
http://pyswarm.wiki.sourceforge.net/PSM
http://pyswarm.wiki.sourceforge.net/TDM

Instead of massively reimplementing the old SDK to create the 1.0 SDK, I plan 
to do the following:

I'm taking the old SDK (0.7.1) and I will modify it that way, so it will be 
able to process such models as I linked above... instead of generating a 
pyswarm application, as it did before. This new tool I call ADK - which is an 
abbreviation for Architecture Development Kit, since we can generate new SDK 
versions with it and we can design the runtime architecture of pyswarm.

I'm confident that I can create this ADK in the coming weeks, so we will have 
a new SDK releases soon. However, at the beginning they may be have all 
features as the 0.7.1 SDK, or may have differences, since I have already done 
some improvements in the concept and I want to reflect them in the next SDK.

Hope you like that.

regards,
Anastasios

[pyswarm-devs] Drafting the documentation output

[Anastasios H. <ah...@ha...>]

It's me again. Now I have also wrapped up all my home-work on documentation 
generation for pyswarm applications.

http://pyswarm.wiki.sourceforge.net/Documentation

This page describes the different sets of documentation to be supported.

It also contains suggestions and one example how a developer can use the UML 
model and/or manually written DocBook/XMI files to generate the complete 
DocBook/XMI output, so XHMTL or PDF documents can be rendered by using 
3rd-party tools (at least on GNU/Linux there is an entirely Free Software 
tool-chain available for this purpose).

I plan to define these feature suggestions in more detail when the concept 
gaps between all levels are closed (GUI <-> uses cases / business processes 
<-> domain logic).

Anastasios

[pyswarm-devs] More on GUI generation and built-in widgets

[Anastasios H. <ah...@ha...>]

On the wiki I have added a small example, how model-to-GUI transformation 
could look like. This example includes a state diagram, based on the most 
recent state of my home-work. (Activity diagrams are still a difficult issue, 
though I already have some interesting ideas. Despite that, I have to figure 
out how all these different diagram types can be tied together into a single 
and tidy concept.)

Additionally, I wrapped some examples of widgets that may come built-in and 
could be used for generated GUIs:

http://pyswarm.wiki.sourceforge.net/Desktop+GUI

For most of them I created (fake) screen-shots that hopefully helps to get the 
idea.

Anastasios

[pyswarm-devs] Dummy GUI screen-shots

[Anastasios H. <ah...@ha...>]

Happy New Year :)

I have started to make several screen-shots of my dummy GUI that show some =
of=20
the features I have suggested.

You find them in the project's wiki, see bottom of page for links:
http://pyswarm.wiki.sourceforge.net/Desktop+GUI

These are the general features that may apply to any application, e.g.=20
splash-screens, sys tray icons, perspectives...

I will add more screen-shots soon that will show widgets in the dialogs (e.=
g.=20
text controls, tree controls) and examples of domain-specific dialogs (e.g.=
=20
addresses, persons,...) and corresponding the domain class models.

Hopefully, the screen-shots make the discussion less theoretical ;)

Anastasios

[pyswarm-devs] Common GUI features

[Anastasios H. <ah...@ha...>]

This list contains GUI-related features that may become very handy for=20
end-users and developers of pyswarm applications. Consider them as=20
suggestions, where some of them really need discussion.


Do you want me to attach GUI screen-shots in the mails or do you prefer tha=
t I=20
just link to some URL in the web?



Splash screen

While the GUI app is starting up, a splash screen is shown. Predefined at=20
design-time by app developer. Can be turned off. (local user pref; overridd=
en=20
by network user pref)


Tip box

A dialog with random tips on usage of the app can start with the GUI. A=20
selection of tips and their translations are created at design-time by app=
=20
developer. turn on/off (network user pref)


System tray icon

Left-clicking allows access to the windows of the GUI app, restore / close,=
=20
and right-clicking shows menue short-cuts to other favorite features of the=
=20
application.


Context help

App developer can define default behaviour for context help on a per projec=
t=20
or per dialogue base. There may be three different behaviours to support:

A) Clicking on the "?" button of a window will change the mouse cursor to a=
=20
question mark (depending on the OS),
left-clicking on a widget will let pop up a bubble help text.

B) When a widget gets focus the corresponding help text will pop up.

C) All help text are directly shown for each widget (e.g. in decent color a=
s=20
part of the widgets' labels)


=461 help

Pressing the F1 key inside a window will start the online-help in a new win=
dow=20
(if not already there) and already calls a pre-defined help page. The conte=
xt=20
can be defined for a page that is specific for the window shown, or (if=20
technically possible) for a widget with focus,
or as fallback a welcome / content page of the documentation.


Class-specific icons

=46or non-image/non-document objects we can use class-specific default imag=
es=20
(SVG?) that are shown for each object. For typical actions (new, edit,=20
delete,...) and typical states (filed to archive, trashed, ...) we can exte=
nd=20
the default images with pre-defined symbols for actions and states. Perhaps=
=20
does make most sense for debugging / prototyping GUI.


Object bookmarks

Like in Web-sites an user can set bookmarks to (persistently stored) busine=
ss=20
objects, so these (frequently used) objects can be accessed in a later=20
session.


Virtual object folders

User can manage virtual object folders that contain other virtual object=20
folders or object bookmarks. This feature can help users to access many=20
frequently used objects, especially if they are linked thematically to each=
=20
other in a manner that is not modeled (fore-seen) by application designers.


URI

The object bookmark feature suggests that we use a URI pattern... e.g.:=20
pyswarm://host:port/object-id[.version-id] - AFAIR there is some RFC or ISO=
=20
standard describing how application-specific URIs should be designed. I thi=
nk=20
I have read such hint in PostgreSQL documentation.


Object monitoring

User can subscribe to monitoring service on a per object base. Maybe does m=
ake=20
sense for other clients, too, e.g. legacy system can be automatically=20
triggered at any data changes. PostgreSQL supports a feature on record leve=
l,=20
I think. I would like to provide subscription options specific for pyswarm=
=20
applications, e.g. filters on what actions or state-entry / state-leave,=20
object only or linked objects or all objects of a zone. Monitoring service=
=20
could inform the subscriber by complete log-files, diff log-files, emails,=
=20
http (think of RSS), short-message service, etc.


Versioning

Enables user to browse through version history of an object's attributes (a=
nd=20
probably its links and linked objects' verions).


Comments

Works like a discussion forum (with threaded view, sticky comments). Thread=
s=20
are attached to one or more objects of business classes selected at=20
design-time (or run-time?).
Cross-browsing threads should be supported (browse for similar threads in=20
related objects).


Notes

Notes are a specific type of comments. A comment can be defined as a note. =
By=20
defining a note as an important note that note will be displayed on top of=
=20
the business object (enforced overlay?).


Perspectives

Developer defines perspectives and containment of dialogues at design-time.=
=20
Admin can restrict those at run-time.
With-in these restrictions an user may be able to customize perspectives an=
d=20
views or not. If enabled user can manage multiple
perspectives and views for the same dialogue and quickly switch between the=
m.=20
In general developers and admins can define reasonable default preferences=
=20
that can be customized by user on global level or per dialogue.


Printing and print preview

wxPython already supports good printer support, including print previews.
During requirement analysis I have found some component-specific use-cases =
in=20
which the user after a print job has to be prompted if the output got corre=
ct=20
or not. Good example is billing: if output is correct the bill will be=20
archived.


Reports

We need some good reporting tools so developers, admins and end-users can=20
manage, design and generate reports. Reportman=20
[http://reportman.sourceforge.net/] may worth a look.


Office automatization

Integration of office suites (e..g OpenOffice.org) works into both directio=
ns:
A) Inside a pyswarm application the user can do an action so an office=20
template file is opened and filled with context-specific parameters.
B) Inside the office suite pyswarm data can be accessed, e.g. to fill the=20
address fields in a mail merge.


Application roles & rights

One option to design these aspects in a pyswarm application would be to hav=
e=20
actors that represent application roles. In use-case diagrams actors are=20
related to use-cases which would represent the privilege to execute such=20
use-case. By assigning users to actors (app roles) at run-time the admin ca=
n=20
manage privileges of users.


Object mirror

Business objects or a sub-set of business objects can be mirrored from one=
=20
business logic component to another. Such sub-set could be ruled on a Zone=
=20
object base.
Example: An address management component has address books as zone objects=
=20
where each one represents a customer and contains addresses available for=20
this customer. Only the addresses owned by the AddressBook object "ACME,=20
Inc." of the same customer will be mirrored in the component=20
WebOrderManagement.



Best regards,
Anastasios

Re: [pyswarm-devs] Basic GUI set-ups

[Anastasios H. <ah...@ha...>]

On Wednesday 12 December 2007, Anastasios Hatzis wrote:
=2E..
>
> Whenever a developer changes a pyswarm application it would be sufficient
> to generate the server-side controllers and XRC files, and then deploy th=
em
> on the server. After a server-update all clients would just get served the
> new XRC files.

Installation of a pyswarm GUI could be based on distutils which is standard=
=20
library in Python distributions. The pyswarm SDK 0.7.1 is using this lib,=20
too. So I would use same code as template for code generation of GUIs.

Python-egg / easy-install might be a better alternative, but I have not yet=
=20
implemented any installer based on it. However, this is non-critical for me=
=20
and can be considered again if the GUI concept got a more concrete shape.

Anastasios

>
=2E..

[pyswarm-devs] Single sign-on (SSO)

[Anastasios H. <ah...@ha...>]

Spy hats on, here we go ... :)

End-user privileges + security

Privileges must never be verified on client-side. These privileges do not=20
apply to typical read/write of values only, but also to the existence of=20
attributes. You probably don't want users with role X to even know that the=
re=20
is an attribute "laziness-factor" in the entity class "student". ;) Verifyi=
ng=20
privileges on client-side would be security leak since control over the=20
client is usually not ensured. Hacking the client should not result in=20
potential override of privilege verification. (What the client software=20
doesn't know, a hacker can't learn from a hacked client, right?)

Additionally, it seems that the privilege security model will be tightly=20
coupled with the =C2=ABpyswarm.zone=C2=BB class concept, (please see=20
http://pyswarm.sourceforge.net/doc/0.7.1/ref-osm-Zone.html).

A built-in single sign-on component should manage user accounts of pyswarm=
=20
applications and communicate access controls to the integrated business=20
components and databases based on the zone objects (authentication +=20
authorization). Probably this will be lot of hard brain work to get a solid=
=20
approach working for most use-cases.

After a client (GUI, Web, business component,...) successfully signed on th=
e=20
SSO component returns a SSO ticket (that can be represented as a random=20
string and identified again by this string). The SSO ticket is stored (agai=
n=20
encrypted) on the client until the session time-outs or the client is=20
explicitly signing off.

The client-side of SSO / session management should be included in the pyswa=
rm=20
client lib, commonly used by all clients, even business components.

Each client will provide some authentication mechanism and input method, wh=
ere=20
users are prompted to enter login name and password.

Again, the SSO component can be used by GUIs and Web applications as well.=
=20
wxPython has great features for incorporating HTML pages or fragments into=
=20
widgets, so an app developer could mixe both worlds together in a single=20
user-interface and offer the user a great experience. At the same time the=
=20
developer would not need to struggle with different, partially incompatible=
=20
SSO concepts in the same application.

Some months ago I had created a prototype that already worked pretty well: =
An=20
SSO component written in Python (that would be actually generated by pyswar=
m=20
SDK later) provided the SSO ticket handling and user management for a small=
=20
Web-application written in Python (Apache + mod_python). Whenever a browser=
=20
requested a page, the Web-app checked if there is already a SSO ticket ID=20
given - either an encrypted string as browser cookie or as parameter attach=
ed=20
to the requested URL. The SSO ticket also allowed distinction between=20
anonymous users and signed-on users. However, the Web-app was able to use t=
he=20
ticket transparently. For example the anonymous user got another navigation=
=20
than an user that has signed-on.



LDAP integration

The SSO component can

a) export its user account data to a LDAP directory (OpenLDAP?)

In this case the SSO component would manage all user accounts in an=20
organization. Any other application could access the LDAP directory for its=
=20
user management.

b) use instead of its own user accounts the LDAP directory.

This would add LDAP support to all components that are based on this SSO=20
component (usually to the entire pyswarm application). Application develope=
rs=20
and administrators would benefit from built-in LDAP-support with no=20
significant changes in their application models and no additional coding in=
=20
each component.


However, I have never worked with LDAP in detail. I heard it's not that=20
*light-weight* as the name suggests, but maybe someone else can help with=20
LDAP support later.

Any comments welcome.

Anastasios

[pyswarm-devs] Basic GUI set-ups

[Anastasios H. <ah...@ha...>]

=46ollowing, two set-ups for graphical user-interfaces (GUIs) of pyswarm-ba=
sed=20
applications:


Stand-alone, all-together installation:

All components will be installed on a single host, likely a PC. This would=
=20
include databases, business components, and GUI. The end-user might have=20
administrative privileges, for example, to install or remove software.

This use-case is special since it would allow us to avoid many=20
(time-consuming) network features between the components of the installed=20
pyswarm application. So all client libraries should support direct access t=
o=20
another component (e.g. "import componentFoo") instead of starting to handl=
e=20
plenty of wrappers designed for networking.

Beside that, principally I don't see any performance or hardware resource=20
problem for today's average home PCs or business PCs. Recent PostgreSQL=20
versions perform pretty well, CPU and RAM consumption is low and goes down =
if=20
the database is just idle. Assuming such application would not incorporate=
=20
overchallenging computation in the business logic layer, the biggest part o=
f=20
system load would be caused by the GUI.

This set-up could be the favorite local testing environment for pyswarm=20
application developers. They can easily run iterative tests on their local=
=20
host to see results of changes in the GUI or business logic. This may happe=
n=20
multiple times per hour. Of course these tests won't redundantize final rea=
l=20
tests with full network operations. But just imagine how nice it would be i=
f=20
you could quickly check features or behavior of particular components while=
=20
designing or coding - and not thinking of network issues or even side-effec=
ts=20
to stable components that already run in production system.


Desktop server:

Many users share the same desktop server over the network. The server hosts=
=20
the GUI of the pyswarm application, but installation *may* also include=20
backend-components or access them over network. Installation and removal of=
=20
software on such hosts usually are done by system administrators, not by th=
e=20
end-users.

AFAIU, virtual machines or physically distributed clients actually are noth=
ing=20
else as the desktop server set-up.

In order to reduce administration efforts and ease an automatic upgrade=20
process a pyswarm application I consider to separate the GUI into mainly tw=
o=20
parts: the part that is installed locally should have the client lib, widge=
ts=20
and other code that will need only update if the developers decide to upgra=
de=20
their pyswarm application to run on a newer pyswarm runtime environment.=20
Application-specific changes (workflows, dialogs and so on) will not requir=
e=20
any update of the GUI itself. Maybe it is possible to use wxPython's suppor=
t=20
of XRC for this. An XRC-file contains an XML-formatted specification of=20
widgets (e.g. layout, buttons, labels, ...) and the GUI app would parse tha=
t=20
XRC files and render the dialog with its content.

So deployment of GUIs would actually be a kind of frame on the client side=
=20
with a library of all widgets supported in a pyswarm application's GUI, let=
's=20
call it a "dialog controller". This dialog controller would interact with t=
he=20
back-end on a server, say a "dialog agent" which accesses the business=20
components and workflow controllers

The pyswarm SDK would at design-time create all XRC files, that are deploye=
d=20
to the server only. At run-time the dialog controller of the client would=20
send a (user) request to the dialog agent. The dialog agent asks use-case=20
controllers in the business components or workflow controllers for the=20
appropriate actions to take and will send back an XRC file to the dialog=20
agent. The dialog agent then renders the dialog and presents that to the=20
user.

Whenever a developer changes a pyswarm application it would be sufficient t=
o=20
generate the server-side controllers and XRC files, and then deploy them on=
=20
the server. After a server-update all clients would just get served the new=
=20
XRC files.

Conclusion:
So, there are no updates on dozens or hundreds of clients. No end-user with=
=20
administration privileges required. No out-dated client versions. No broken=
=20
business logic.

Did I forget something? What do you think?

Anastasios

[pyswarm-devs] Business component ideas

[Anastasios H. <ah...@ha...>]

As already announced, here are the candidates for the pyswarm component=20
world ;)

After analyzing requirements in our company I mixed these conclusions with =
my=20
experience from earlier software projects and tried sketching a set of=20
business components.

Please keep in mind that these components are suggestions only. I just foun=
d=20
that they make some sense for our company, but pyswarm should be suitable f=
or=20
many other companies: I appreciate your suggestions.

Identity management:
organizations and their units (head-quarters, subsidiaries, departments),=20
persons as individuals and as contacts in organizations.

Single sign on:
SSO would enable authentication and authorization features (login, logout,=
=20
register) across pyswarm components. Controls privileges of users, access t=
o=20
objects and particular activities. Maybe OpenLDAP should be integrated.

Address management:
see the pyswarm tutorial; manage recipient's addresses which can be=20
postal-code based addresses (geographical and P.O. box), email and Web=20
addresses (maybe other types of URI/URL, too), as well as the different typ=
es=20
of telephone numbers (cellular, video, VoIP, fax).


Maybe these three components can be considered as infrastructure components=
?=20
Developers could incorporate them as default components into new pyswarm=20
applications and the SDK would generate them along with any domain-specific=
=20
component, i.e., a customer management component that is covering very=20
specific domain rules could depend on the identity and address management.

There are some components which would be more domain-specific, in our case =
as=20
a contract manufacturer there could be components to manage...

* customers
* suppliers
* sales orders
* supply orders
* production planning
* pre and post calculation
* logistics, transporation
* storages and stocks
* products and services / parts, compositions,...
* billing (with-out accounting)
* operation data recording
* human resources (with-out payrolls)
* machines


=46urthermore I see some additional components for customers and suppliers =
to=20
access important information and services (think of customer self-service=20
a.s.o.). These components could provide a Web-based interface to the busine=
ss=20
partners, but realization of features would be a sub-set of the components=
=20
above. Use-cases and work-flows for these partners would usually be=20
restricted to the data related to themselves.

Anastasios
=2D-=20

Mit freundlichen Gr=C3=BC=C3=9Fen

i. A.
Anastasios Hatzis

HATZIS Edelstahlbearbeitung GmbH
Hojen 2
87490 Haldenwang (Allg=C3=A4u)
Deutschland

Tel: +49 (0) 83 74 / 9 30 8-13
=46ax: +49 (0) 83 74 / 9 30 8-10

Mobil: +49 (0) 15 20 / 8 59 28 78

Handelsregister Kempten (Allg=C3=A4u): HRB 4204
Umsatzsteuer-Identit=C3=A4tsnummer: DE 128791802
Gesch=C3=A4tsf=C3=BChrer: Paulos Hatzis, Charalampos Hatzis

http://www.hatzis.de/=20

[pyswarm-devs] Brief update

[Anastasios H. <ah...@ha...>]

Hi guys!

Before discussing the GUI features and other aspects of pyswarm I would lik=
e=20
to refresh the context and give you a short update.

pyswarm Applications:

I excpect that pyswarm will be mainly used in the domain of modern, n-tier=
=20
business applications: Enterprise Resource Planning, Customer Relationship=
=20
Management, Order Management etc. Other fields are possible where=20
applications depend on databases, f. e. document and content management=20
systems or groupware solutions. It is less likely that pyswarm will be usef=
ul=20
for development of strongly mathematical, technical, scientific, multi-medi=
a,=20
hardware-related or real-time applications. Users would typically be small=
=20
and medium sized organizations or solution providers acting on their behalf=
=2E=20
I will post a suggestion of components separately soon.


Architecture:

Business components of a pyswarm application are written in Python and can =
run=20
on all platforms with standard Python distribution. If necessary an user=20
should be able to distribute the components over network on different hosts=
=20
(XMLRPC?). Furthermore a business component should be able to access its=20
corresponding PostgreSQL database on the local host or on a remote host=20
(preferrably encrypted connection).


Interfaces:

Each business component should provide an interface so clients can access i=
t.=20
Clients can be:
a) command-line scripts (kind of those command scripts of which the pyswarm=
=20
SDK consists),=20
b) text-only user-interfaces (e.g. Python curse),=20
c) graphical user-interfaces / GUI (e.g. wxPython/wxWidgets, Tkinter,=20
pyQt/Qt),=20
d) Web-based interfaces (e.g. Apache+mod_python, Pylons, Django, TurboGears=
),=20
e) other pyswarm business components acting as a client of one pyswarm=20
business component (n-tier architecture),=20
f) or 3rd-party components (e.g. Python based libraries and packages such a=
s=20
Mailman; OpenOffice.org).

As you may remember I preferred to go with wxPython as default=20
framework/tool-kit for graphical user-interfaces (GUIs) generated by pyswar=
m=20
SDK.

Note: pyswarm should have some common libraries, so application developers =
are=20
free to choose another wxPython-based GUI concept or even a GUI based on a=
=20
different framwork/tool-kit. However, for the beginning pyswarm SDK should=
=20
support (semi-)automatic generation only for a single type of GUI.

It would be great if we can develop a strong GUI concept. I think that mode=
rn,=20
intuitive user-interface is one of the keys for the success of any software=
=2E=20
Actually it's (too) often the only way for an end-user to rate the software.

Best regards,
Anastasios

Re: [pyswarm-devs] wiki for "rocking herring" papers

[Anastasios H. <ah...@ha...>]

On Monday 07 May 2007 11:00, Anastasios Hatzis wrote:
> Hi,
>
> now we have a wiki for drafts regarding the re-design for the 1.0 release.
>
> http://pyswarm.wiki.sourceforge.net/
>

I have added more information and ideas, even those SDK-related from the 
Discussion part in the 0.7.1 documentation.

Currently I try to figure out what would be best to do next.

Best regards,
Anastasios

[pyswarm-devs] wiki for "rocking herring" papers

[Anastasios H. <ah...@ha...>]

Hi,

now we have a wiki for drafts regarding the re-design for the 1.0 release. 

http://pyswarm.wiki.sourceforge.net/

I think the wiki is okay to show recent planning online on a central place and 
with e.g. UML diagrams or XMI examples included. The mailing list is good for 
discussions of features and so on, but IMO falls short if it comes to 
illustrations and more complex issues and recent versions. However the wiki 
is not mentioned for the final documentation, where I still prefer 
DocBook/XML.

Currently project members only can edit pages, but anyone else can add 
comments to particular pages. If you feel the wiki should be opened 
completely, please do let me know.

However, I started with sketching the road-map and iterative re-designing 
process. Next I want to list the UML tool candidates to be supported next and 
the use-cases I already considered, and will work both out in more details. I 
will keep you noticed of future additions.

Best regards,
Anastasios

[pyswarm-devs] Getting the feet wet with MDA & Co.

[Anastasios H. <ah...@ha...>]

Hi,

I have started to think about the re-engineering of pyswarm for 
mile-stone "Rocking Herring" (hope you like that name, too). The 
documentation of 0.7.1 
[http://pyswarm.sourceforge.net/doc/0.7.1/discuss.html] already sketched a 
rough frame of the final release and some major improvements in the area of 
the SDK and the runtime architecture. Actually some of the SDK improvements 
have been implemented already, namely the GNU-style console options and 
arguments, an easier SDK installation, and (at least for the recent parts of 
the SDK code) the adoption of the PEP8-based naming conventions.

As far as I see most of the features are not too difficult to realize. A 
rather simple way would be to stay with the exlusive support of the MagicDraw 
XMI 2.1 format. After some clean-up work of the SDK's code base (especially 
seperating the layers) we could move soon to the target architecture and 
runtime platform for which applications are generated.

Despite this easier way I'm convinced that there are obviously good reasons to 
add the support for as many UML tools and XMI formats as possible. And this 
is where things become much more complicated. Probably I have read too much 
about meta-meta models in the recent days and therefor I started thinking 
about a generator-generator. - Well, we will come later to this topic.

Before you continue with this post, you may consider reading my new post here: 
http://pyswarm.blogspot.com/2007/05/feetwetmda.html
It contains an outline of the MDA-related standards so we get a rough 
impression of the big frame in which we want to paint our picture. I have also 
added links to specifications of the mentioned standards. I use some 
abbreviated terms that are also explained in that post.


pyswarm's Current Design

pyswarm SDK 0.7.1 has no support to store a PSM. The generator is only able to
read the PIM, transform that to a PSM and this PSM directly into an ISM. The 
PSM is not kept for further use. The SDK is also not recording any of the 
processed transformations, so there is no data to create a TRM.

The reason for this: The current design has not a clear seperation between the
different layers, which would make it easier to store the PSM, not to mention
of XMI-serializing the PSM model. Here a description how generation works
now. There are three code parts involved in the generation process (beside
the command handler in cmd_pysp_generate.py which controls the entire process
and its phases):
* sdklib/Parser.py and sdklib/ParseNodes/*.py
* sdklib/Transformer.py and sdklib/TransformationNodes/*.py
* sdklib/OutputNodes/*.py

The Parser module controls the parsing process during generation. It begins
with the top element which is the xmi:XMI tag found in the XML file, then the
uml:Model tag and all the way down the XML DOM tree. Each of the XML elements
found are verified for specific constraints, e.g. special stereotypes, before
the reasonable implementation decides as what kind of ParseNode sub-class the
element is treated. So, after the entire parse process we have a tree of
parsed elements which are representing together the PIM as it has been parsed
from the XML file. Therefor you can consider the ParseNode layer as a
representation of PIM-specific XMI elements.

The tree which results from the parse process is then taken by the Transformer
module which controls the transformation process. It again begins with a top
element and walks down the entire tree of ParseNode objects. For each
ParseNode object found in the tree there are constraints verified and a
transformation happens, actually a new tree will be created and filled with
TransformationNode elements while the old tree of ParseNode object will
remain unmodified.

During output phase the top element of the TransformationNode tree is
retrieved and a method output() is called on it. This method calls
recursively output() methods of child nodes down the tree. The output()
method of each TransformationNode (most of them has such method) is
responsible to create the corresponding ISM element, e.g. directories, SQL
files, Python modules, Python __init__ modules, packages, script files etc.
The content of all files is generated from template sniplets that are
scattered all over the TransformationNode modules and puzzled together with
some basic frame content added by modules from the OutputNode package
(depending on the type of file that is to be generated). So maintaining the
code templates can become rather difficult since the hard-coded
transformation rules (PSM->ISM) and the code templates are mixed and many of
the code templates are crowded with masking signs that are masking masking
signs that needs to be also generated. In short, this is a big mess. In any
case for mile-stone "Rocking Herring" I want an improved design with clean
seperation of the layers. Fortunetaly it is obvious how this could be done
and it shouldn't be a challenge to do so.


The Future Use-Cases

The following use-cases do not necessarily represent commands, for example the 
generate command would consist of sub-sequent call of other commands which 
represent certain tasks (use-cases), depending on the concrete options 
provided. Example: read XMI file with PIM, transform PIM to PSM (with TRM), 
write PSM to XMI and return TRM as UML/Python tree. The sequence of the next 
generate execution could differ from this. In pyswarm SDK 0.6.2 I have 
started to introduce scripts to be used via command-line, which can access 
specific command handlers. I plan a new Python API for other clients, such as 
UML tools, which can access the command handlers like the scripts already do.

XMI -> PIM
XMI -> PSM
XMI -> TRM

PIM -> XMI
PIM -> UML/Python tree
PIM -> PSM (optionally with TRM)

PSM -> XMI
PSM -> UML/Python tree
PSM -> ISM

UML/Python tree -> PIM
UML/Python tree -> PSM
UML/Python tree -> TRM

TRM -> XMI
TRM -> UML/Python tree

However, the fore-mentioned use-cases are suggestions, I don't think that this 
will be the final list. I think there are other use-cases or variations 
possible, e.g. using commands on entire models, selected model elements, one 
complete model in one XMI or Python UML tree, or parts of the model in 
multiple sources, and so on. I even thought about some kind of simulation 
engine that would work with-out a full generation of an application (perhaps 
with meta-classes), so models could be tested/verified in design time, e.g. 
in a UML tool that is a client to the new SDK API.

If you have any comment or question, please feel free to post. Meanwhile I 
will do some studying on the several standards (still challenging to me) and 
I also want to learn and play with some Python features I have never used. ;)

Best regards,
Anastasios

Re: [pyswarm-devs] SDK with-out PyXML

[Anastasios H. <ah...@ha...>]

On Saturday 28 April 2007 12:14, Anastasios Hatzis wrote:

> I'm currently experimenting in SVN
> under /branches/dev/features/1708563_pyxml-replacement to replace PyXML
> with the XML libs from Python standard lib.

Done! I commited the new version into SVN. Usage and behaviour should be the 
same, except:
(a) You don't need PyXML installation any more.
(b) On my notebook generation of PetStore took only 20% of the time needed by 
0.7.0. Except of calling it with --debug option which now adds some more 
XML-related debug messages to the log.

Best regards,
Anastasios