This post originated from an RSS feed registered with Java Buzz
by Hugo Pinto.
Original Post: Hands on... CASE, RAD and AOP
Feed Title: Hugo Out There
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Welcome to my blog. It happened. I succumbed to the vanity exercise that a weblog is and started my own one. Here youll find information and thoughts (some worth reading, some not) on Java, J2EE, Software Architecture, Music and Parapolitics
Enough about JBoss and JBoss Group. I'm starting some week-long vacations, and what's better to do on vacations than some hard-core, intensive - you guessed it - software development? ;)
Ok, I admit it, I'm also taking some time on the beach, but this week I'll be focusing on getting of the ground a series of ideas o my previously discussed RAD and CASE postings - so, let's get our hands dirty with some experimental development.
I'm focusing on building a RAD framework/runtime/IDE that enables one to quickly come up with a full-working "enterprise" application. By "enterprise application" I am referring to the typical "get/put data on a database, render part of that data on-screen, get inputs from user, manipulate one/many of those data entities, and store them back modified on the datastore".
It is my opinion that many readers will be familiar with the feeling that the vast majority of the "enterprise applications" we do nowadays are actually variations of the same framework, evolutions on the same idea. I'm getting pretty fed up with this feeling. So, I've been slowly trying to come up with some pre-solutions to this problem. I actually got a series of them. Some of you will say "naive! naive!", some will comment "this guy is trying to re-invent the wheel", some will say "look at CA's Advantage Joe, Borland's Together/J, Rational XDE, or [insert your favorite product name here]", some will say "wake up, bozo, you're aiming at the impossible". Well, each of you might just be right. But I actually think that I may be trying to do something different. Here's why:
1) I'm aiming at a specific problem, instead of a general, domain-neutral framework. I don't want, for now, to generalize it into a plain CASE tool. It's just an aid to create "enterprise applications".
2) I'm taking a very straightforward approach: I want my framework/runtime/IDE to be able to solve the problems me and my team solve, every day. I'm not going to over-engineer it right away to support every kind of problem.
3) I'm just having plain old good fun trying to get my ideas in a solid piece.
So, now that we have that cleared, let's get on with my approach.
I am an OOP guy. Or, at least, I used to be. Soon, I started to realize that software development is a multi-dimensional problem. And that each of the dimensions intersected and crossed over the others at some points. Bad Thing here is that OOP didn't cope that well with this idea, as its hierarchical decomposition techniques usually exercise only one dimension.
I got to learn AOP. Nowadays, it's trendy to talk about AOP (see my posting's title?). And it happens that with AOP we start to harness this multi-dimensional nature of software development. We can fix one of the dimensions, and cross-cut it with aspects. I've usually seen this happen with the functional dimension: people usually fix the functionality (and choose to decompose this dimension with OOP, top-down techniques) and the cross-cut functionality with security, transactions, logging, the usual stuff. This results in a much lower LOC count, and supposedly, in more maintainable code. Ok, I'm cool with that.
I'm also into meta-modeling. I believe that stuff like adaptive object models and some form of business process modelling will play an increasingly larger part in complex, enterprise-grade applications, since the sheer complexity of the average application nowadays starts to overwhelm the human capabilities.
So, I started to put all this together. Starting this week, I'm aiming at the creation of a tool that:
1) allows the definition of business domain objects. These have attributes and behaviour, and represent the business domain and it's internal rules. Ex.: A Client has one Fiscal Number, one Name, and at least one of several Addresses. Each Address has a Street Name, a Door Number, and a Complement.
2) allows the definition of business functionalities, that fulfill business use cases. Each of this functionalities will change the system's state (i.e. it's business domain objects) in some way, and will be mapped onto the system's architecture in a way consistent with their information needs.
3) allows the definition of system boundaries, that specify how the system interacts with other systems, what information is exchanged and how. This boundary concept is applicable both to user interfaces (GUI's, etc) and other systems (EAI, API's, etc)
As you can see, I'm focusing on functionality too. From the previous paragraphs, you also get the idea that my focus (for now) is not at all on the development process. I'm assuming the tool user already has a full list of business domain objects, with their behaviour fully specified. Since I'm focusing on functionality, let's bring AOP to the table now.
I'm kind of a lazy guy. I figured that If I'd put together AOP techniques with my modeling efforts, It might somehow save me some coding and time. Here is what I'm trying to do. I'm considering three levels of aspects:
1) code-level aspects: these are aspects whose scope is how the code behaves. They are programming concerns, domain neutral, and application-neutral. They are useful as tools to achieve better programming results, but the end-user of my tool won't worry too much about them unless he/she wants to: these are stuff like Call Logging, Profilling, Tracing, Pre/Pos Contracts (maybe), and stuff like that.
2) system[or application]-level aspects: these aspects concern the application that we're building - stuff like Role-Based Security, Persistence, User Interfacing, Distribution, Fault-Tolerance, etc. The user will choose these (or configure them) as part of the architectural choices he/she will make during the design of the application.
3) domain-level aspects: well, these are the ones that I'm less sure how to address. I know they exist. These are stuff that cross-cut not code, not the application's architecture, but the non-IT, business-specific processes. The one I could quickly consider is authorization. In so many organizations, to get something done (that is, in the middle of a well-defined process), the process' executor must go to meet a superior and get his/her authorization to continue with the process. These, I believe, will be the more difficult to identify (since, I suppose, the organizational processes are nowadays modeled ALREADY considering these intermediate - crosscutting - steps). My tool will not address these. Maybe if the kind user recognizes some of these patterns he/she will be kind enought to comment them back to me...
So, I want the user to be able to model a domain-specific set of objects, features and processes, instrument them with system-level advices, and get a full working application (either by model interpretation or code generation, we'll get there soon).
Absurd? I don't think so.
But what about user interfaces? Remember I was telling that I was focusing myself on the functionality part of a very specific kind of applications - the "enterprise application" solution. These usually feature some very limited user gestures (add object, edit object, list objects, remove object, execute command [that is, "execute feature"] on an object, show object's detail, etc). And these can also be easily modeled.
Like an interface with any other system, a computer-user interaction obeys a protocol, a set of rules that specify which messages can be exchanged on which contexts. So, why not model it and have the system interpret it / generate it?
But let's not get ahead of time. First milestone? Must get a working system that, using an "enterprise application"-meta-model, allows me to define business domain objects.
Previous Topic
