Jimmy Z

My last few posts have been written on the topic of Model Driven Architecture (MDA). I recently read a white paper(pdf) on Mentor Graphics’ EDGE UML Suite, which is a tool that will take you through the entire MDA software cycle. I must say that I’m beginning to be more convinced of the power of MDA.

The Edge UML Suite is primarily a tool for building software for embedded systems. Mentor Graphics’ MDA tools have been tried and proven in “launch vehicles, life-critical medical systems, fault-tolerant telecom systems, resource-constrained consumer electronics, and distributed, discrete-event HLA simulation systems.” (EDGE UML Suite product page)

Their tools claim to produce code that require smaller footprints than other UML-modeling-to-executable-code tools.

The EDGE UML Suite consists of four tools: the BridgePoint Builder, the BridgePoint Data Access Package, the BridgePoint Debugger, and the BridgePoint Model Compiler. The following diagram displays how these products work together:

Another version of this graphic that is included in the white paper labels the design layer as the platform independent model (PIM), and the translation layer as the platform specific model (PSM). Most embedded systems don’t need much as far as interface design, so there doesn’t seem to be as much interface-related information on this tool like there is for the OlivaNova Model Execution tool.

In the past, I programmed small applications for various barcode-scanning handheld devices. I always prefered working with Rapid Application Development (RAD) tools rather than building the software from scratch in C, or some other lower-level language. RAD tools seemed to limit the application to a small, predefined set of functions, which often forced the creation of custom software. Designing from UML seems to give much greater flexibility in functionality while still allowing for a quick, visual approach to software creation. I would like to someday try out a tool like this.

Model Driven Architecture (MDA) is marketed as the all-encompassing solution for your company’s CIO (http://www.omg.org/mda/executive_overview.htm). It is meant to solve age-old industry problems faced by Systems Analysts and Engineers. It is a means of rapid system design, development and implementation. These systems will be platform independent and will be able to communicate with past, present, and future information systems. It will also offer maximum flexibility for making changes to the system’s model which will then be automatically translated into all parts of the operating system.

As an Information Systems professional, I agree that this would be ideal. Being able to implement a system purely from a higher level design seems to be the utopia for supporting the technical functions of a business. After all, every large-scale system must have a well thought out design including a data model, business processes, use cases, interfaces, etc. The success of an information system relies heavily on the design that precedes the implementation.

MDA seems to be wonderful in theory and I recently saw the OlivaNova Model Execution System in action, which was quite impressive I must say. However, I have my doubts that MDA is the silver bullet that will solve all systems related problems.

One weakness that I see in the MDA approach to software creation is that it seems to remove a lot of the human element of software creation. Although OMG states that one of the core benefits of the MDA is that it focuses on business processes, it seems that “The problem with software development is that there is too much ambiguity in the problem statement and in the design description…” (Alistair Cockburn, Humans and Technology).

Alistair Cockburn, the author of several books on Agile Software Development and Crystal Clear, has written an awesome article titled, “Characterizing people as non-linear, first-order components in software development,” which identifies two main problems with trying to fit people into systems or models.

• Problem 1. The people on the projects were not interested in learning our system.
• Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.

Alistair talks about a tool, which resembles MDA characteristics, that was rejected by the technical team. Here is an exerpt:

I shifted over to tool development, working in an ethnocentric fashion as far as possible. I watched the designers of communications protocols, and discussed with them what might be their problems. My colleagues and I decided that, “The problem is that the people are still drawing at the whiteboard. Things will go better if we give them special tools so that they can draw directly into the computer and give them early execution of their designs.”

We spent several years developing an inference engine that would convert time-flow, interaction diagrams into a software architecture and rule system. Many groups were and are working on a similar agenda, e.g., Harel’s executable finite state machines.

We completed the prototype after several years and showed it to our would-be user group, and were shattered to hear them say, “No, thanks, we actually like drawing on the whiteboards. We don’t want to take the time to put the drawings into the computer. Um, may we use the drawing editor portion of your tool suite?” Listening to other tools vendors, we heard the same experiences, usually ending up with, “they use just the drawing editor portion.”

In my experiences with software development, I have found this to be true. Teams prefer to draw on whiteboards, and quickly implement the designs that they have produced. This process works well as the system is broken into small portions and worked on in manageable pieces. Close communication with people who will actually be using the system is vital during this process. End users think of the system in terms of interfaces, rather than the data model that sits behind it to support the interface.

It might be that I don’t have enough experience with MDA to give it a fair judgment. I would be interested in seeing more of it in action. MDA might just be the level of abstraction that brings the technical world to a new level of productivity. I am a big fan of working at the higher-level. That is probably why I enjoy building web software in Ruby, on the Rails framework. Perhaps I will be even more satisfied with the even higher-level development capabilities that MDA wishes to offer.

Model Driven Architecture (MDA) is a standard developed by the Object Management Group (OMG) for separating business logic from application logic. All of the busines logic of your system will be carefully defined by using standard UML modeling and other associated OMG modeling standards which will then be used to generate the technology that actually makes it work.

“OMG’s Model Driven Architecture provides an open, vendor-neutral approach to the challenge of business and technology challenge.” (Object Management Group)

One of the benefits of Model Driven Architecture is that your applications will be built on a standard that will be able to interact with legacy systems and new systems regardless of the platform that it was built on. It uses standards such UML for defining the business model, XML Metadata Interchange (XMI) for exchanging and storing model information, and CORBA for middle-ware interaction between systems (http://www.omg.org/mda/executive_overview.htm). These standards are not tied to any software or hardware platform, thus making it possible for an MDA system to adapt to new hardware and software platforms.

You can think of MDA as USB at a system-level. It provides a standard interface for things to connect and work together. For example, my USB flash drive doesn’t care if it’s being plugged into my Mac or my brother’s PC, nor does the PC care if I’m plugging in a Sandisk drive, or my Ipod Shuffle. Rather, it knows that a device of some sort that has been built to the USB standard will be plugged in and that it will be interacting with that standard. The same goes for MDA, it is a standard for defining domain specific, platform independent systems and how these systems will interact.

A standard MDA configuration consists of three components (http://www.omg.org/mda/faq_mda.htm):

1. A definitive platform-independent base model (PIM).
2. One or more platform-specific models (PSM).
3. Sets of interface definitions.

The PIM defines the business logic and domain model of the system. This may consist of use cases and other specifications that don’t depend on a specific platform.

The PIM is then translated into a PSM which is something that a computer can actually run. It may be translated into C++, .NET, Java, or any other major general purpose language. (http://en.wikipedia.org/wiki/Model-driven_architecture)

The interface definitions can either describe how a human will interact with the system, or how middle-ware interfaces will interact with the system.

Because the application is broken down into these different components or layers, a change can be made at the platform independent model (PMI) and then be translated down into working software that will be able to interface with any system or user. This should save time and money.

OMG states that the three biggest benefits of using MDA include (http://www.omg.org/mda/faq_mda.htm):

1. “… attention focuses first on the application’s business functionality and behavior, allowing stakeholders’ investment to concentrate on the aspects that critically affect core business processes.”
2. “An architecture based on the MDA is always ready to deal with yesterday’s, today’s and tomorrow’s ‘next big thing’ and makes it easier to integrate applications and facilities across middleware boundaries.”
3. “Domain facilities defined in the MDA by OMG’s Domain Task Forces will provide much wider interoperability by always being available on a domain’s preferred platform, and on multiple platforms whenever there is a need.”

So, MDA allows systems developers to focus on business processes, integrate with past, current, and future systems, and operate on any platform. That seems to be its main value proposition.

MDA isn’t a technology, it’s a standard, which means that different vendors will be providing solutions built on this standard. For a list of vendors that are already building tools for the MDA standard, see OMG’s Committed Companies and Their Products.

See OMG’s MDA site for more details.

Java Message Service (JMS) is a Java library that allows you to do Message Oriented Middleware (MOM) in order to facilitate messaging between different parts of a distributed system. This type of messaging can be useful in large enterprise information systems that require systems to communicate in a simple manner.

The JMS provides two models for messaging: a point-to-point queuing model and a publish/subscribe model. In the point-to-point model, the message producer knows where it wants to send the message, and it sends it to the queue which is then taken by the receiver. The publish/subscribe model allows for multiple receivers to subscribe to receive certain messages selected by topic. RSS feeds seem to follow a similar pattern as that of the publish/subscribe model in that new content is published and multiple subscribers to that feed can retrieve the new content.

I’m not an expert by any means in using JMS. I just think that the MOM architecture is just an interesting concept. For more information on JMS, see Wikipedia.

In my Information Architecture class we’ve been discussing the benefits of logging and best practices for implementing logging in your applications. Because logging seems to be such a tedious task, it is something that is often overlooked or neglected in custom software development projects.

It seems that it is too much work to open up a handle to write to a log file just to record that an event happened on your server. Add the complications of rolling log files to older versions as soon as you log files reach a certain size, and it seems that logging events in your application is overkill. I used to think this way until I was introduced to Log4J and its ports.

Log4J is a Java library that was written to solve all of your logging needs. It provides a simple interface for logging messages as easy as logger.debug("Error encountered..."); which can be configured to output to a log file, an SMTP email message, a database record, a network socket, a console, or even a Jabber client for instant message alerts.

Log4J offers different levels of debugging, which allows developers to log debugging information all over the application, and then simply switch off that level of log messages with a simple configuration file.

The levels of logging include:

• Trace
• Debug
• Info
• Warn
• Error
• Fatal

If the configuration file is set to trace-level logging, then messages will be logged for everything below it as well. Debug-level logging will ignore trace statements, and info-level logging will ignore both trace and debug.

Making log calls at the different levels is extremely easy. It’s just a matter of calling the right method on your logger object. Here are some example calls that can be used:

logger.trace("Use this instead of print lines");
logger.debug("SQL: " + sqlStatement + "Executed in: " + executionTime );
logger.info("invalid login attempted at: " ipAddress);
logger.warn("a warning statement");
logger.error("could not connect to socket");
logger.fatal("application crashed");

This type of logging is pretty simple and straight forward.

Another really cool thing about Log4J is that you can specify the format of your log messages in the log file. If you want to capture timestamps, class name and line number of a log message, etc. you can set that up all in the configuration file.

Log4J can also automatically roll your log files at certain size limits and set to only keep X number of rolled log files so that you don’t eat up your entire hard disk and crash your system.

Because Log4J has made logging so simple and easy, Log4* ports have been created for several other languages including C, C++, .NET, PHP, Ruby, Perl, and even JavaScript.

I wish I would have known about this years ago so that I could have taken advantage of easy logging in php and Java.

Mobilefish.com has posted a simple tutorial on using Log4J. I recommend checking it out.

The ability to mash two or more concepts into a new product has sparked some really creative ideas that have received a lot of attention in the web 2.0 boom. Recently, toys have seen some thrilling success, as movie brands have been mashed up with traditional toys of the past.

My favorite mashup has been Star Wars mashing with Legos. I’ve always been a huge Star Wars fan, so naturally I get really excited when traditional toys get mashed up with Star Wars themes. I’m kind of jealous of kids now days, although I have a 1366 piece Imperial Star Destroyer sitting in my spare bedroom, waiting to be assembled.

The mashup concept was taken to a new level as Lego Star Wars: the video game was released. I don’t play many video games, but when I visit our in-laws, I usually have a good time playing some games with my brothers-in-law. Lego Star Wars I and II bring together 3 great concepts into an extremely creative, fun game.

My sister sent me a link this morning to a new mashup, Spider Spud. Wow! This one is awesome! I already have Darth Tater and Spud Trooper, but I’ll probably have to get this one too.

I may have just revealed too much of my underlying nerdiness, if I hadn’t done so already with this blog. In case you’re wondering, yes, all of my action figures are cherry.

Jay Pipes, a MySQL employee, gives a lecture at Google on MySQL Optimization. I’ve been in several discussions on how to optimize large queries, especially during my time working on TagJungle*.

This video has opened my eyes to some query practices that I used to do that are sub-optimal, and how to correct those problems.

One of my favorite optimizations that Jay Pipes demonstrates is that you can actually run a query like: SELECT * FROM users WHERE email LIKE '%@gmail.com'; and have MySQL use an index to help perform that query. It’s really quite clever, and I used to think that you were just out of luck with a slow query if you ever wanted this type of information. I would post the solution to this problem here, but the video is beneficial enough to just recommend watching the entire video.

Another big eye opener for me was the concept of Correlated Subqueries (which aren’t a good thing to do). Here’s an example of a correlated subquery:

SELECT name,
(SELECT COUNT(*) FROM Reservation WHERE confirmed<>'N' AND campId=C.campID) AS Confirmed,
(SELECT COUNT(*) FROM Reservation WHERE confirmed='N' AND campId=C.campID) AS Unconfirmed
FROM Camp C

This is bad because each of the subqueries must be executed for each camp record. This makes it so the query doesn’t scale well as the number of camps grow.

To fix this problem, it is suggested to think of these types of queries in sets rather than as procedural operations. The above query could be executed like so:

SELECT C.name, Confirmed, Unconfirmed
FROM Camp C LEFT JOIN
(SELECT campId, COUNT(*) as Confirmed
FROM Reservation WHERE confirmed<>'N'
GROUP BY campId) AS ConfTable
ON C.campID=ConfTable.campId
LEFT JOIN
(SELECT campId, COUNT(*) as Unconfirmed
FROM Reservation
WHERE confirmed='N'
GROUP BY campId) AS UnconfTable
ON C.campID=UnconfTable.campId;

This is provides much faster execution as only 3 lookups need to be made to the db and then just joined together. This will scale up as more records are added to the database.

Here’s the video:

* Disclaimer: I no longer am an employee of Tag Jungle or 42Co.