A first glance of Mizura core diagram

At this moment (at Sta Cruz do Sul Shopping Center, delighting with a special coffee...), I'm working in mizura configuration section.

To do this, I need to understand more about Mizura architecture. So, like one picture say more than a thousand of words:

This "beatiful" diagram show the mainstream classes and interfaces of Mizura project.

With these elements in my mind, I will to proceed with the configuration elements (not displayed in diagram, yet).

More coffee, please ;)

Like a Rolling Stone. Ops, JDBC API

At this moment, I'm working in framework basis, to create a similar JDBC API approach to work with Mappers (aka databases flavors), Finders (aka Statements) and Connectors (aka Connections).

But, queries into specific repositories (like Jira, EA, Excel, Rose, Mantis and so) does not support sugars like SQL ANSI 92.

So, I need to use another techniques.

One of them is Java Generics. However, I am not an expert, and still have to use some SupressWarnings on pieces like this:

@SuppressWarnings("unchecked")
public < T> T createFinder(Class< ? extends T> finderType) {
  return (T) new EaFinder(this);
}

I hope to improve these code fragments, and have a complete refactoring even this week.

In coming days, I will return to the Element part, which represents the wrappers for objects in each repository (aka usecase, Issues, etc.)

Mizura Jira Connector Plugin Growing

In the last two days, I've been working on the architecture of mappers and elements of Mizura's connector plugin.

Mappers

The mappers are responsible for obtaining the configuration mapping, for example, notifying that one use case is mapped to one issue task in Jira or that one UML package is mapped to one Jira component.

In practice, the mappers are extensible and configurable, allowing any type of connection between elements.

In default implemention, Mizura comes with a simple PropertyFile mapper.

Elements

The elements are the artifacts to be synchronized, such as use cases, tasks, components, versions, relationships and so.

The elements are configurable using type and synchronization options, and are linked one to the other in configuration mapper.

Synchronization

The architecture of the mappers and elements seems to be good.

What will be tricky now is the synchronization itself. See the class:

public enum SynchronizationOptions {
 ADD,
 UPDATE,
 UPDATEIFNEW,
 DELETE,
 DELETEWITHPURGE,
 ADD_UPDATE,
 ADD_UPDATEIFNEW,
 ADD_DELETE,
 ADD_DELETEWITHPURGE,
 ADD_UPDATE_DELETE,
 ADD_UPDATE_DELETEWITHPURGE,
 ADD_UPDATEIFNEW_DELETE,
 ADD_UPDATEIFNEW_DELETEWITHPURGE,
 UPDATE_DELETE,
 UPDATE_DELETEWITHPURGE,
 UPDATEIFNEW_DELETE,
 UPDATEIFNEW_DELETEWITHPURGE;
}

Powered Synchronization

This list shows the 17 (there are some mistake?) possible synchronization options available for mappable elements.

I'll be working on it in the next few days and I believe that in two or three(layer) weeks an alpha version of the Mizura connector will be available.

Extensible Architecture

After some refactors, now it is relatively easy to create new connectors to other tools, like Rose, Excel, Trac, etc.

In short, the Mizura platform should be open to various synchronization possibilities, like as Ea to Jira, Jira to Jira, Jira to Rose, Rose to EA, Excel to Jira or ... any combination form.

Again, I hope ;)

Mizura project is launched

After more than a year of research, sleepless nights and a lot of code testing, the project Mizura was lauched.

Like any open source project, it depends of personal efforts to be done and so, this weekend, I dedicated some hours to it.

It was created an Jira to control the project development, a space in Confluence to organize documents, a discussion group to allow people interact with ideas and this blog to publish relevant news.

Motivation

The project Mizura came from a daily affliction of our development teams and project management areas: the integration between software management tools (in this case, the Atlassian Jira) and the modeling and project tools (in this case, Sparxsystems Enterprise Architect).

So, I have been working since 2008 with the idea of integrating these softwares, allowing project managers to visualize usecases and requirements as manageable artifacts, while our systems analysts, architects, developers and users can track these same elements as project issues.

Thus the Mizura idea appeared, allowing a unified, transparent and bidirectional interaction between these greatest tools.

Architecture

Basically, the Mizura is composed by 5 parts:

• EA Connector, which allows read, extract and update information in UML diagrams.
• Jira Connector, which allows read, extract and update issues and other project information.
• Spreadsheet Connector, which transforms and integrates UML elements and issues into lines in the spreadsheets, making easly tabulation of data and estimatives.
• Mapper, which defines the mappings between connectors, allowing things like "an issue is mapped to a usecase" or "an issue link is mapped to a requirement dependency".
• MDA Connector, which enables the visual definition of the Jira's workflows using default diagrams in the Enterprise Architect.

Current status and future works

Today (January 2010), the project Mizura was lauched to the public audience, where we are looking for developers and partners to implement the basic functionalities and give relevant feedback.

We expect that the first stable version be available at the half of this year, in both community and comercial releases.

Mizura project is maintained by 3layer Foundation developers and sponsored by LM2 Consulting, both brazilian organizations.