Software Engineering

The idea for Conqu was hashed long before the Android or Blackberry tablets were even a rumor. However, the idea sat on the back burner for several years until finally the first production tablet devices were on demo at Adobe MAX in late 2010. At that point the hardware finally caught up to the requirements of such an app. It was time to un-shelf the idea and put forth the effort to create an exceptional app for the Blackberry Playbook.

I think the event went very well. The setting was a little strange, with round tables and small screens spread out in the room, many of them looking away from the speaker. I was happy to see some more advanced presentations, so there was a little for everyone, I think. I'd like to thank Brian Rinaldi for his hard work and invitation.

A new Flex framework has been born. Actually, it is not really new, because we've been developing and using this framework for a long time, but it is now available to everybody.

"Mate" (pronounced "mah-teh" like latte) is a tag-based Flex framework that uses implicit invocation to route events to handlers using an "EventMap". Those handlers are a list of actions that is executed when the event is dispatched.

First of all we’d like to thank Michael White for sending us a gift from our wish list. We are so happy! It is the first time a reader other than my mother gets us a present (I don’t think my mother reads us anyway)

High in our wish list was a book about usability for the Web: Don’t Make Me Think! A Common Sense Approach to Web Usability. This book is great. It’s just so easy to read you’ll go non-stop and finish it in a day. Not only has very practical advice but also it’s very fun to read.

If you are interested, there is a sample chapter available at the writer’s website.

Thanks Michael!

I wish I could learn all the design patterns this way!
Listen to the Model, View, Controller song that was composed and performed by Apple Operations Engineer, James Dempsey, at WWDC.

Lyrics

Ah... the beauty of inherited code. And of course I am not talking about class inheritance and nice OO practices, I am talking about someone else’s code, someone else’s work —does it deserve to be called work? Certainly not work of art!— that falls into our hands to amuse us, to awaken us from our daily routines, to make us indulge in the satisfaction of feeling that we "know better", or is it to torment us? That piece of beauty is there, in front of our eyes, to be fixed, debugged, extended or, even worse, perpetuated.

While reading the first chapter of UML Distilled by Martin Fowler, I found that I didn’t know how UML could be used beyond the simple class diagrams that help us organizing our code. Although it may seem a little far-fetched, it is interesting to know that UML can also be used as a programming language.

Fowler describes three different modes in which UML can be used: sketch, blueprint and programming language.

Sketches are informal diagrams used to communicate ideas, explore alternatives or design in a collaborative manner. They are usually focused on some aspect of the system and are not intended to show every detail of it. Sketch is the most common use of the UML, and it is certainly the way I always use it.

Blueprints’ purpose, on the other hand, is to describe a system in detail. In the case of forward engineering, the details of the blueprint should be enough for a programmer to code the system. In the case of reverse engineering, the diagrams show all the details of a system in order to understand it better or to provide views of the code in a graphical form.

The UML can also be used as a programming language. When used in this form, the whole system is specified in the UML, the diagrams are the code, and they are compiled directly into executable binaries. There are some projects and books about that: Executable UML and the MDA (Model Driven Architecture).

The effectiveness of each way depends on what we are trying to achieve by using UML. In the early stages of development, using UML as a sketch is highly effective and can be used as a collaborative tool where the developers can brainstorm about the system design. In this case, it wouldn’t be effective trying to think about every detail of the model and generate a blueprint, because the system hasn’t been fully designed yet. After the system design is more stable, UML can be used as a blueprint, and developers can follow it to produce code. Using simple sketches wouldn’t be enough for them, because it would require them to fill in the blanks. This may produce incompatibilities between interfaces or other problems because every developer may interpret the model differently.

Effectiveness of using UML as a programming language would highly depend on the generating and diagramming tools used. If no tools are available to do the job, or diagramming in such detail is cumbersome, then it is not effective. Fowler believes that productivity of UML as a programming language today is not better than productivity of using any other language, thus it will be difficult for UML to go mainstream. He also believes that highly detailed blueprints are not effective because they are difficult to do and it would slow development. I still believe blueprints are good tools because they remove uncertainties for the developer, but I have to agree that even for senior designers it is difficult to delineate every detail of the model.

While working with the C2 architecture I realized the real purpose of using a framework. By definition, a framework is "a structure for supporting or enclosing something else". That is, a structure that allows us to do things such as using messages as communication between components (as in C2) or implementing implicit invocation (as in MachII) when the underlying language does not provide native facilities for that.

It is not only to be able to rapidly develop an application. Rather, it is to be able to use an architectural style to inherit all its advantages: modularity, anticipation of change, abstraction, low coupling, and high cohesion (all the properties that styles aim at). That, in turn, allows us to develop more quickly because the style put us constraints and we have some predefined configurations of component arrangement. We also achieve faster development by means of using proven patterns and reusing components. We could achieve the same results by applying other styles (as long as the language allows us) and skipping the framework.

So why use a framework? Because I am lazy and I don't want to have to think so much about how to realize a style or pattern. And by using a framework correctly, I get a free ride to a well organized application and I can focus on other things.

I have been working on a little project where it was required to use the C2 architecture. If you've never heard of this architectural style, you are in the great majority. It was developed by the Institute for Software Research at the University of California, Irvine.

It is event-based or better "component and message"-based. Components communicate using messages sent through a connector. What is interesting about it is that it differentiates between type of messages as "Notifications" and "Requests". Notifications are sent "down" and the component has no expectation that some other component is listening whereas Requests are sent "up" and the component sending them makes the assumption that the service will be provided by some other component above it (but it doesn't care who).