Bluffer’s Guide to CA Plex Development

Introduction

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):

  • Aim to provide low maintenance solutions
  • Aim to use best practice and standard approaches
  • Aim to produce bug free code
  • Aim to ‘not reinvent the wheel’
  • Aim to initiate change with least impact
  • Aim to do as little work as possible
  • Aim to leverage all of a departments skill set
  • Aim to get better at what we do every time and to enjoy the process

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:

  • Object oriented approach to application design to eliminate the need to code repeatable elements of applications
  • Working at a level of abstraction rather than at the ‘nuts and bolts’ level, probably just saying the first point again but this can’t be over stressed the importance to think this way instead of coding procedural code line after line
  • Model-based and pattern-based approach to increased application quality and flexibility
  • Multiple inheritance is a key part of the way applications are developed in CA Plex therefore leveraging the full value of a site’s existing patterns
  • Encapsulation so that function interfaces contain only the attributes pertinent to the use of the function
  • An application should be separated into separate layers/tiers, Functionality should be strictly separated into data access, business logic and presentation logic, as this promotes the consistency of the application as well as the possibilities to reuse functionality.

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.

Development Process

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

Before Development:

“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.”

Standards Layer:

        

“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 


The three-step process of Data Modeling, Pattern Matching and Customization

STOP Coding - Start Architecting

http://wiki.plexinfo.net/index.php?title=Plex_Technical_Overview

Data Modeling

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)

Pattern Matching

 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.

Customization

“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”

Golden Rules:

  • Inheritance – Never create a function without inheriting an action diagram first enabling future inheritance possible.
  • Inheritance - Inheriting from the right place makes all the difference. If you aren't sure, ask or refer to the documentation.
  • Abstract or Implemented - Never Both. Using abstract functions as ancestors give a high production yield, because common functionality can be specified once and used multiple places. However tempting it can be to inherit from an existing object, if the new object is equal to the existing object plus a small amount of additional functionality, this praxis is strongly discouraged, as it creates maintenance problems if the need arises for the parent object to be changed, but not in the child.

          
 

  • Inheritance - Never inherit from the standard views (Fetch, Update etc). You always get loads of functions under these which you don't want. Simply create a new view and get your pattern master to set up Fetch and Update templates which you can inherit from.
  • Coding - Never change a standard data access function E.g. if you change ProcessGroup to delete a load of records, and some-one else inherits from it, guess what happens See Abstract or Implemented Golden Rule.
  • Coding - Local panel changes are BAD NEWS. You have to take account of too many things so try and get everything done in the patterns. Obviously not possible for a screen with 20 fields but 80% of most systems should be done with no local changes at all.
  • Coding - Assume the worst Case Scenario – too often applications only hold together if everything is working and promoted, don’t assume a record will be there, don’t assume a file will be there, Assume nothing works and make the function report back its findings I,e mapped directory does not exist, don’t assume the mapped directory does exist even if it is meant too.
  • Coding – local action diagram modifications should be kept to a minimum, no one likes opening a function like visa kund to do change and seeing all the code they have to check to see what impact their change will do. It should be possible to inherit most of the code and if not ask why not.
  • Keep it simple stupid – if something seems over complicated and is hard for you to maintain imagine how hard it will be for another developer! Simply stand back and rethink and start again, none of this is rock science, ask for help.