pyswarm can import a PIM which specifies a custom pyswarm application. Using an UML CASE tool this PIM could have been created by a modeler or developer, e.g. yourself.

Partial PIM of an pyswarm application.

The PIM defines two business classes in the application, Foo and Bar. Classes stereotyped as «pyswarm.entity» represent persistent business classes. A class in a logic component stereotyped as «pyswarm.zone» is also a business class but has some additional features (they are covered in other parts of the documentation). As you can see both classes have public attributes of the Text datatype.

Both classes are associated where the composition defines a life-time concept and ownership aspect, so each Bar object is owned by one Foo object while each Foo object may own multiple Bar objects (see 0..*). The names of each role in the association are unique in the component and should be meaningful. Deletion of a Foo object will cascade delete all its owned Bar objects.

Foo has also an operation (a business operation since it is defined in the PIM of the custom application) which will create a new object of the Bar, associate it with the self object of Foo and makes the self object the owner and zone object of the recently created Bar. The operation's stereotype and tag define that this operation is generated 100% automatically (no programming) and that it is used to create a new business object of the class defined as return-type. The parameters given in such an operation are related to the class of which a new object is going to be created.

Currently the PIM is notated in UML serialized as XMI file which then is imported by the pyswarm SDK. The SDK transforms the PIM into a PSM. The PSM represents the code that will be generated in the next step of generation. Below you see a simplified incomplete PSM how the generator would create one from the PIM example earlier.

Note

The PSM is only shown for information purpose. Please note that the SDK currently does not create an UML representation of the PSM. Indeed the generator directly writes the source code represented by the PSM to hard drive with-out saving the PSM. This is one reason why pyswarm SDK can be considered as a light-weight MDA, while some other MDA tools deliver the PSM which can be fine-tuned by the developer before it is finally generated as source code implementation.

Partial PSM of an pyswarm application.

In the upper left area you can see the two business classes that will be generated. The lower left area has collection-like classes that are generated by pyswarm SDK due to convenience. They represent collections of the corresponding business classes, global and association-specific. The right frame contains classes that are base-classes in the runtime environment of pyswarm. They are in the serve library package and has no custom features for any applications.

First let me describe the serve classes. Entity is the top base-class for all persistent business classes. It has some convenient features, e.g. EID and strEID methods to retrieve the entityID attribute value of any business object. Zone is sub-class of Entity and any zone plays a special role in its logic component - in our example this zone is the Foo class.

Now let us have a view on the generated business classes. The SDK added some operations: there are getter and setter methods for each attribute of the class, but also getter methods for each association of the class to retrieve the opposite elements whatever they are. As you know Bar's opposite role is FooOfBar which represents exactly one Foo object. So you can call on any Bar object the generated getFooOfBar method to retrieve the owning Foo object. Note that the returntype of the method is Foo. With setFooOfBar you can associate the Bar object to the Foo object given as parameter value.

The Foo class has the opposite association-role BarsOfFoo with the multiplicity 0..*, thus each Foo object may have no, one or many Bar objects associated. Since they can be many objects returned for convenience reasons pyswarm uses collection classes. In principal pyswarm adds one collection sub-class for each business class, representing a collection of business objects of this class. You can count all objects in the collections (or only objects filtered by classifiers and criteria) and you can get pages of all the objects ordered by a specific attribute, where you can define if you want to get one single page with all objects inside or page-wise with providing page size and page number. getPage does like count support classifiers and criteria to restrict the operation to a sub-set of the collection's objects.

	Note
	Note the automatically generated collection sub-class names: many Foo objects are Foos (a plural s is appended), many Country objects are Countries (trailing y become ies, and many Address objects are Addresses (trailing ss become sses). There are no lingual exceptions supported, e.g. in the case of Child the name Children would be lingually correct, but it will become Childs.

In order to retrieve the opposite collection of objects (which probably is empty, contains only a single object or plenty of them) you can call on any Foo object the generated getBarsOfFoo method which will return a BarsOfFoo object which itself is a sub-class of Bars.

	Tip
	Association-specific collection classes have additional methods to operate on the association, e.g. inserting new objects (insert) or removing associated objects (remove).