Some thoughts on the UML and MDA!!

So I am thinking of starting in to the world of MDA and UML 2.0 that is supposed to help you achieve all the benefits of the MDA. But before I start going in that direction, I wanted to put down what is it that I am trying to solve when I start developing application to solve a business model. Now based on my limited understanding of the application that I have worked with there are the following things that I should be able to represent in a modelling system.

• Object Template (Class)Representation So basically in order to start modelling a system, we need to be able to model the entities of the system. These entity (in an object oriented world) will have Data/properties and methods. But I think we need to increase this list as follows
  • Properties: This just like in object oriented world would represent the data that actually makes an object the object that represents an entity in real world.
  • Method This represents the actions that can be performed on this object.
  • Constraints Now most of the times this is something that is built as part of the implementation but I think we really need to allow people to set the constraints where the mouth is i.e. at the Design level. This will ensure that if required these constraints can be enforced by compiler or by the generated code either at the object definition level or better still extrapolate that to user/external input interface validation step. Now these constraints are contextual and thus have to be specified at the level where that context is complete which can be at object template level. These constraints could be for object creation, data validation, data dependency (like you can not have interest value without interest rate and principal amount), method invocation, object deletion and so on(TODO: need to complete this list).
  • Relationship I some how feel that UML class diagram has not done enough justice to provide efficient representation of the relationship. Now typically the relationships are represented as an object template/class with pointers to associated object template(s) or as a line with relationship names and additional information about relationship type (many to one, one to one, etc) but you can not have both the features at the same time (or can you?). Another thing that I see missing in such a scenario is definition of reverse relationships like father, son and so on. Most of the times the relationship typically gets defines as a "is a" relationship and so the design would create a class for the relationship and later on a complete redesign would be needed in case the reverse relationship comes into picture. But instead in case the relationship could be defined as a separate entity that binds atleast two object, it will automatically get defined as a concept of "role" which is less restrictive in the sense that it can be assigned to or removed from the base objects as the system evolves. This idea will help the system representation grow more organically as the components become clear. So this provides us to avoid some basic design flaws during the design phase. These relatioship definition would obviously have associate properties, methods and constraints (for relationship creation, relationship deletion, relationship enforcements to name a few).
• Use Case definition (or getting the work out of the system) This basically defines the work that we want to extract out of system and how the system components work with each other to achieve the same. There are a few things that I think are missing from UML.
  • object selection constraint/rule definition The activity or sequence diagrams are used to describe the interaction between the various object instances during the performance of the use case. Now when we typically make the call from one object instance to another, we need to ensure that we are sending the message to or calling method on correct object. This information can not be built into the UML diagram since the nearest thing present in the diagram is the description name of the object. We need to be able to extend this model to be able to specify a constraint rule description the object selection rule. Now there is an interesting consequence to that. When we describe such a rule, this rule will have input variables that will have to be fulfilled by either calling object or the environment. In case this has to be satisfied by environment, it automatically brings in the concept of session into picture which is basically collection of minimum set of attributes that uniquely identifies a transaction/process (if the session is not being used as cache as most of people end up using it as).
  • Business Logic Most of the business logic can be divided in to two types: Business Process and Business Rule. The business process basically defines a series of steps that need to be performed which involve interaction with external entities like Person, Web Service, Database or other application modules. This is represented very well by sequence diagram (and its extensions). But not all aspects are represented very well through activity diagrams. For example, it does not allow you to specify what are the inputs needed from the users or how to express the input interface to the user using a platform or technology independent way like XUL (though not the best example) or may be a new standard. This requires that the Interface Design itself should be part of the business logic and should be expressible in technology independent format which can then be used to generate platform specific code during next stage.
    Business Rule on the other hand basically represents basic business algorithms like interest rate calculation or user access control calculation which can be evaluated given all the inputs are available. This piece of the business logic is typically missing from the UML diagram (is it?).
• Deployment Definition Now an important part of the architecture is the decision of how to deploy the model that has been defined. Now the platform and technology used to deploy an object will decide how the interface will get designed. For example, if the event trigger comes from a user and that is deployed over web, then the interface will be a ASP.NET or J2EE(JSP) implementation while if it is implemented in client server environment, then the client may have to a swing application or a windows application. So it is at the deployment level, where we have to make the choices about the technology and then the next step would be code generation!! Once we have have such a platform ready with automatic code generation capabilities, it is not very far to be able to see large computers being able to simulate using the hardware specifications and software specifications (like how many CPU instruction is taken up by specific kernel call), whether the specific deployment is the best implementation in terms of throughput, response time and other QOS parameters before going into production over a specific architecture (I really would like to see that in my lifetime), like we are able to do for chip designs.
• Aspects An important part of the architecture is the basic generic services that are shared by most or all modules which may or may not be part of the original system models. These include the services like logging and mesurements (Error/Performance monitoring, reporting and correction), audit, security (authentication, authorization, privacy), performance enhancer (cache, replication, prediction), middleware and so on. These are now a days termed under aspect (am i correct?) which are supposed to be integrated with business logic but do not form integral part of the same. It is very important to be able to integrate the aspects in to the business logic at the deployment level (so that we can change them based on the technology constraints, Policy constraints and so on) and will vary based on the deployment configuration selected. So for example, an interface is selected as client-server on NT environment, then it may make more sense to use Window based Kerberos security for authentication vs using token based authentication in case the Web based application.

Most of these thoughts may be representation of me not understanding the capabilites of the UML diagrams and may be its me that needs to do a catchup rather than vise versa. So let me begin my quest for the same...