If you happen to have a 64-bit Ubuntu operating system installed in your computer (which I have, btw ), just install the .deb package using the following command:

dpkg -i --force-architecture ./modelioFree1.2.1-20101008.i586.deb

Enjoy!

These premises complemented with a Model2, component-based structure, help us define a fairly appropriate way of defining components, along with their dependencies.

The following organization is only adecuate for domain-driven business components, meaning that it should only be used for components created to handle operations related to a single domain-driven entity. For example, if you were developing an e-commerce site your domain model would include entities such as Cart, LineItem, Product, etc. If you were organizing your business logic in a domain-driven fashion, probably a component for each domain model would exist.

The above mentioned strategy is described in the following illustration:

The elements in Figure 1 are:

• EntityModificationComponent. This element would be in charge of any modification logic (CUD of the CRUD). This element has a dependency from EntityValidationComponent since it would often need to validate the create/delete/update operations before performing them. A usual validation could be that the entity name must not already exist in order to be created or updated, or verify the entity is not being referenced from any other place in the system for us to be able to delete it. A dependency to EntityListComponent exists because normally any modification logic needs a number of queries before performing them.
• EntityValidationComponent. This element performs validation logic on a particular entity. It should contain any restrictions or rules regarding the update, delete, or create operations on the specified entity.
• EntityListComponent. All queries related the entity should be defined here. A separate element is defined because it normally does not reference any other bean, making it highly reusable. Another advantage of placing all queries in a different component, is that other beans depend on it, but it does not depend on any other bean, avoiding circular references that would come up if modification and query logic was placed in the same component.
• EntityFacadeComponent. This element should contain any logic you wish to share/publish to an external client. It is ideal if you want to expose some web services focused on the manipulation of a particular entity. Naturally, the contract exposed by this component should be compatible with the canonical data model in your enterprise or any other application you want to interact with.

Conclusion

I have found this organizational pattern very handy when the overall functional architecture is not stable but the domain model is. As the requirements are specified and the functional requirements become more stable, you realize that you have already done most of the job with the chance to add or update functionality quite easily.

Hope you enjoyed this post.

Indx Name            Predecessors    Effort    StartDate    EndDate     Resource
0    - PlanningRoot                  24h       12/04/2010   14/04/2010
1      - Node1                       20h       12/04/2010   14/04/2010
2        - Task1                     12h       12/04/2010   13/04/2010  Resource1
3        - Task2     [2]             8h        13/04/2010   14/04/2010  Resource1
4      - Node2       [1]             4h        14/04/2010   14/04/2010
5        - Node21                    4h        14/04/2010   14/04/2010
6          - Task3                   4h        14/04/2010   14/04/2010  Resource2

Figure 1. A simple plan.

As you can see from Figure 1, this is a two-day plan with three specific tasks assigned to resources 1 and 2. The important thing to note here is that, by the way predecessors are defined, a subtle modification such as increasing the estimated effort on Task1 may cause a chain of modifications that will end up on the whole schedule being delayed. Not that there is anything wong with delays, it’s just that this type of consistency is a little bit hard to achieve considering the many variables participating here, including:

• The project’s default calendar.
• The resource’s calendar.
• Each task’s effort and start date.
• Each task’s predecessors.
• The resource assigned to each task. This is important because the resource imposes its calendar as a restriction to the task. For example, if the resource works tuesdays and wednesdays only, the task’s duration will be longer.
• The percentage of assignation of the resource to the specified task.
• Other variables I haven’t thought of yet :p.

Now, if you have a schedule with completely isolated tasks (with no predecessors defined), the job gets to be easier. But life is tough and predecessors are a reality, so you have to accept them and move on. Seriously, I don’t consider predecessors one of my favorite friends, but they sure make the life of project managers easy. The thing with predecessors is that they impose really hard restrictions on the date a particular task is started. Besides, a task can have multiple predecessors. This means that all predecessor tasks must be finished by the time this task is supposed to start. And the task must not start months or years after de last predecessor was finished, but it must try to start as soon as it can.

The algorithm used to deal with all of these problems is quite demanding and I will probably write about it in later posts. For this post, I will focus on a more punctual problem related to predecessors and the detection of cycles between them. A cyclic relationship is not desirable when processing planning nodes since it can lead to the good old StackOverflowException leaving our application useless. I had to dedicate a long part of my time just to analyze the many different types of cyclic relationships that can happen. The following figures illustrate some of them:

Indx Name            Predecessors
0    - PlanningRoot
1        - Task1     [1]

Figure 2. Self cyclic relationship.

Indx Name            Predecessors
0    - PlanningRoot
1        - Task1     [2]
2        - Task2     [1]

Figure 3. Direct cyclic relationship.

Indx Name            Predecessors
0    - PlanningRoot
1        - Task1     [3]
2        - Task2     [1]
3        - Task2     [2]

Figure 4. Successor-of-successor cyclic relationship.

Indx Name            Predecessors
0    - PlanningRoot
1        - Node1
2          - Task1 [3]
3        - Node2
4          - Task2 [1]

Figure 5. Parent-of-successor cyclic relationship.

I can go on infinitely showing you how many types of cyclic relationships exist and how many combinations of them can exist. So I rather show you the rules I came up with in order to avoid these types of relationships:

1. A node cannot have itself as predecessor.
2. A node cannot have a child, child-of-child, etc. as its predecessor.
3. A node cannot have a parent, parent-of-parent, etc. as its predecessor.
4. A predecessor node cannot be a successor, successor-of-successor, etc.
5. A predecessor cannot be a child, child-of-child, etc. of a successor, successor-of-successor, etc.
6. A predecessor cannot be the parent, parent-of-parent, etc. of a successor, successor-of-successor, etc.
7. A predecessor cannot be the successor, successor-of-successor, etc. from a child, child-of-child, etc. of a successor, successor-of-successor, etc. This is sort of a combination of (4) and (5).
8. A predecessor cannot be the successor, successor-of-successor, etc. from a parent, parent-of-parent, etc. of a successor, successor-of-successor, etc. Combination of (3) and (5).

So that’s it. Simple huh? Well, I cannot say it did not demand much time from me. But finally, I got to where I needed to be. Once the rules are defined, the rest is just hard work. The following figures show a reduced version of the solution I designed to solve the cyclic reference problem.

public class ScheduleNode {
  private List<ScheduleNode> predecessors;
  private List<ScheduleNode> successors;
  public getPredecessors() {
    if (successors == null) {
      predecessors = new ArrayList<ScheduleNode>();
    }
    return predecessors;
  }
  public getSuccessors() {
    if (successors == null) {
      successors = new ArrayList<ScheduleNode>();
    }
    return successors;
  }
}

Figure 6. ScheduleNode class representing the schedule tree model.

public class ScheduleUtil {
  public static void predsValid(final ScheduleNode node) {
    if (node.getPredecessors().size() == 0) {
      return;
    }
    for (ScheduleNode pred : node.getPredecessors()) {
      if (isSelf(node, pred)) {
        // Handle cyclic ref.
      }
      if (isChild(node, pred)) {
        // Handle cyclic ref.
      }
      if (isParent(node, pred)) {
        // Handle cyclic ref.
      }
      if (isSuccessor(node, pred)) {
        // Handle cyclic ref.
      }
    }
  }
}

Figure 7. Main algorithm to avoid cyclic references among nodes.

As you can see, the solution is fairly simple and it covers all of the scenarios described previously. Additionally, you can check out the almost-full source code here. Tell me what you think of it.

Other inventions rely on Einstein’s law of conservation of energy, which states that energy can neither be created nor destroyed, it can only be transformed from one state to another. Imagine the amount of energy we waste every day just by walking, working, or eating. The energy spent to lift up a spoon or ride a bicycle is transformed into another type of energy that we cannot reuse. Well, mix that with another nice invention called piezoelectric materials. An article made from a piezoelectric material would be capable of producing electricity if a mechanical stimulus is performed on it. In addition to this, if the piezoelectric material is flexible enough, it could even be turned into clothes and produce energy as we walk. Cool, huh?

So, I can think of many applications for this kind of material, including human-powered homes and vehicles. Even simple games such as anti-stress rubber rings or some types of home appliances could be piezoelectric-powered devices. I can see this as an incredible opportunity except for some energy storage and transportation issues that would require us to be permanently connected to one of many batteries holding all of our energy production for us to be able to use it later.

Now, as a challenge to all of you reading these pieces of information, what real-world applications can you think of for piezoelectric materials?

Waiting for your feedback…

Regards.

@Entity
public abstract class CompanyItem {
@Id private Long id;
// ... Constructor
// ... Other properties
// ... Getters and setters
}
@Entity
public class Stapler extends CompanyItem {
// ... Constructor
// ... Other properties
// ... Getters and setters
}
@Entity
public class Chair extends CompanyItem {
// ... Constructor
// ... Other properties
// ... Getters and setters
}
Example 1. Company item hierarchy.

This structure is not so bad at first sight since it solves the problem of unique id in a simple way. The problem here lies in the fact that whenever you create an instance of Stapler or Chair, the JPA engine will ensure the id for each object is unique among all instances of CompanyItem. This is not so bad if the system is small, but for a large system, it means that soon there will be a lack of ids for new objects.
A simple solution to this problem could be the definition of the id property on each not abstract class that is part of the hierarchy. This may pose a problem of non-uniqueness for each company item.
The following structure shows a simple solution to this problem:

@Entity
public abstract class CompanyItem {
// ... Constructor
// ... Other properties
// ... Getters and setters
}
@Entity
public class Stapler extends CompanyItem {
@Id private Long id;
// ... Constructor
// ... Other properties
// ... Getters and setters
}
@Entity
public class Chair extends CompanyItem {
@Id private Long id;
// ... Constructor
// ... Other properties
// ... Getters and setters
}
Example 2. Company item hierarchy “reloaded”.

Now you’ve seen it. The solution is simple and it is to lower down the id property to each instantiable class inheriting from CompanyItem
In the following post, I’m going to show other sorts of problems regarding relationships with abstract classes. I hope you enjoy it.

Basic JEE GWT app architecture

As you can see, GWT was chosen as the core presentation technology for the application, which makes the system a RIA application. It provides tools that enable us to develop all the visualization logic using Java, while allowing us to deploy it as a Javascript client by using a GWT-to-Javascript compiler linked to the application development lifecycle. All of this results in the assembly of a JEE-compliant application were the WAR file contains both the server (servlets and Javabeans) and the client (GWT-compiled Javascript) code. The following diagram shows a very simplified version of such package:

WAR Structure

Now, there is a tricky side to these so-called “simple” technologies. Basically, when you work with JPA you have to define a set of entities which becomes the domain language in your application. If this entity model becomes your domain language, it must:

• Provide the basis to define the database schema supporting the system.
• Define the terms of how the business logic is to be realized. In other terms, the domain language helps us define the system’s business rules and scenarios.

Having this into account, what would be the best way to handle presentation logic knowing that the JPA model gives consistency to both persistence and business tiers? The answer is not simple and relies on one of the most notable restrictions of GWT: Javascript footprint.
The problem/advantage of any RIA application is that part/all of the presentation logic is displaced to the client’s machine. This is done in order to improve usability and decrease the memory and processing spent by the server when rendering presentation to the client. It also brings the dilemma of how to handle data transfer, specially in JPA where you would have to create an additional layer of data transfer objects along with a dto-to-jpa mapper to handle business logic. The problems arising from this approach are the following:

• Ease of maintenance decreased because DTOs represent an additional layer to be managed by the development team. The JPA entity model is evolutionary, and so the DTO layer will have to evolve with it.
• Complexity increased, because the domain language becomes a flattened layer of Javabeans designed to handle the latency restrictions imposed by a RIA model, which means that presentation developers will deal with a twisted version of the actual domain language. Also important is the fact that a managed JPA entity cannot travel to the presentation tier.

So, an additional layer of DTOs (if the application is big enough) can lead to a whole new level of complexity and maintenance that we did not want to get into. The workaround to these problems arrived from an article published by Adam Bien titled Lean service architectures with Java EE 6 where he proposes a Model 2 approach (boundary-controller-entity) using JPA and Stateless Session Beans. This solution defines a Session Facade bean as the boundary for a component, a regular Stateless Session bean as the controller, and JPA entities backing the business logic. Trying to adapt this pattern to architect our system, we realized that it could provide us a way to use our JPA domain model as the layer of DTOs mentioned above to increase ease of maintenance/development and keep complexity within bounds. See the following diagram for details.

Model 2 solution to use JPA entities as canonical model in all tiers

You may see that beyond the business tier, all entities must be detached since a managed JPA entity brings with it proxies and other harnesses the JPA Engine uses to sync them up with the database. The business tier is divided into two kinds of service to preserve the boundary-controller-entity model. The facade (which represents the boundary in this approach) picks up the managed entities to be returned and creates a copy for each one of them. Each copy is deep enough for the presentation to perform its work. Whenever a detached entity is received by the facade, a managed version of it is extracted to be used by the stateless/stateful service to perform its business logic.

We have experienced improvement in the development process thanks to this approach. Of course, if you use the additional layer of data transfer objects, you can also benefit from Model 2 by allowing the boundary services to create all DTOs necessary for the application to do its job. I have read about  different approaches including the definition of detachment logic having an xml datasource describing such information. You can read more about it in Sanjiv Jivan’s blog. You are welcome to post your comments regarding this subject.

Regards.