Bluffer’s Guide to CA Plex Development
The purpose of this document is to provide a CA Plex developer with a guideline for rapid development of stable and maintainable applications while focusing on business workflow instead of technology.
With this in mind a developer may have the following goals (in no particular order):
Lofty goals maybe but no reason why they cannot be achieved albeit even partially by utilizing CA Plex tool effectively.
Firstly and foremost a CA Plex developers requires a particular mindset:
STOP Coding - Start Architecting
Plex development is essentially a three-step process involving Data Modeling, Pattern Matching and Customization. There are no shortcuts, each step must be adhered to achieve the goals. Missing a step may seemingly achieve a short term solution but in the medium and long term the solution will surely decay far quicker than it should have. The mindset required to use plex effectively is one of:
Note: A plex developer could conceivably create whole functions using the source code statements in an action diagram. It would work but it defeats the object of choosing plex as the development tool. ‘It worked’ could be argued is not a defense for the shortened long and medium term life span of a solution.
The following two sections borrow heavily from CA partners Websydian and Desynit best practices docs. They as CA Plex consultancy firms of outstanding experience who have learned a few things over the years across many CA Plex sites
“Make sure you have at least a general picture of the patterns made available to you before making a head start into solving problems already solved. This way the model will become more simple and easier to understand for other developers. Also, upgrading from one version of Plex/Websydian to another will be easier”
“When designing the application, carefully consider what functionality should be placed where. Figure 4 below shows two different designs, where the first design implies a high number of boundary crossings, and the two alternative designs imply only a single crossing.
Communication across the boundaries can be expensive with respect to performance, and it is important to keep the boundary- crossing overhead at a minimum to help improve the overall performance.”
“Push functionality down as far as possible in the application, as it allows reuse of the functionality across interfaces.”
“The standards layer should be started well before you start coding. It is wise to employ a very experienced developer for this, imagine using a novice builder to build the foundations for your house! We suggest the development of your Standards layer runs parallel with Business Design.”
EdgeTechnicalPresentations\2003 USA\Pattern Factory a new platform to share patterns.ppt
STOP Coding - Start Architecting
Please see Chapter 5 Data Modeling - Plex Help (mk:@MSITStore:C:\Program%20Files\CA\Plex\6.1\ObUsersGuide.chm::/dtaml/ug_dtaml_first.html)
Plex provides a comprehensive list of data modeling verbs which can describe any given business data relationship and help data driven design after Normalisation. But in the past developers have relied on purely creating entities in isolation using known by and Has triples and not utilizing the Entity to Entity Relationship Verbs such as Owned by, Refers To, Association. These verbs provide a language for defining a data model that is easily understood, not only by analysts and programmers, but also by end-users. Plex diagramming is also driven by the Entity to Entity relationships.
Secondly the CA shipped FOUNDATION (mk:@MSITStore:C:\Program%20Files\CA\Plex\6.1\FOUNDATI.chm::/FOUNDATION_definition.html )entity patterns rely on these relationships existing in the model. For example the BlockFetchSet is provided by a Child Parent relationship, Fetching data restricted on parent key, but there are only a few of these functions in the Agaton model, surely there are times when Child records are being fetched.
Thirdly data integrity is implemented on a functional level and not DBMS, “Referential integrity checking is handled through the use of the class libraries. There is no automatic referential integrity checking” Plex Help (mk:@MSITStore:C:\Program%20Files\CA\Plex\6.1\ObReference.chm::/Advantage_2E/Ob_Functions.html)
PATTERNS Plex Help (mk:@MSITStore:C:\Program%20Files\CA\Plex\6.1\patterns.chm::/PATTERNS_overview.html)
Know your patterns available to you and if in doubt ask others. More than half the skill of a modern developer is to know what reusable code is available and when to use it.
Pattern matching can be seen at an entity level and functional level. As plex has developed over the years a more granular approach to pattern development has been observed led by www.patternfactory.de and www.azurtechnology.com but as a rule of thumb entity patterns exist to support and build data model and data access functions whereas business logic and presentation logic consist of functional inheritance.
Patterns allow architects and mentors years of deep experience to be imparted to the development cycle without having to code every function.
The CA-supplied patterns provide most of the basic functionality required by a typical business application such as the shipped CA pattern library FOUNDATION but where the shipped libraries lack functionality we have built on this library
This fact means that new users of Plex can quickly become productive without needing the relatively advanced product knowledge required to actually design patterns of their own.
“The third phase of constructing the application is to customize the implemented Patterns. If we think of the Patterns as classes of behavior, held as design information, then our implemented Patterns need to be sub-classed in order to suit the application requirements. Examples of this could be overriding elements of the Pattern structure, replacing part of the Pattern design with our own design or adding logic to the application to add behavior to the design”