Dan Bergh Johnsson

Omegapoint AB
Sweden

Domain Driven Technology Migration: Saving the Domain from Legacy-Death

So, you have just finished your big project using the hottest Java-framework of the day. And now, when everything is in production, this new framework comes around and turns all your “state of the art” code into ... well ... legacy!

Most probably this code will sit around and rot, until no one ever heard of the not-so-hot-any-longer framework of yore, whereafter maintenance will be so costly that the entire codebase is reimplemented (using the tech-of-the-day) and thrown way. And, it all starts over.

This session shows a way out of this wasteland. Using goal-oriented refactorings, much of the application logic can be saved, so just a minor part of framework-dependent code must be replaced. Depending on how the code is structured this refactoring might be a small or a large project in itself. However, it is in most of the cases far easier and cheaper then a total reimplementation.

The technique is demonstrated through an example going from EJB 2.x to Spring, but can just as well be applied to Hibernate -> EJB 3.0 or Struts -> JSF.

Non-functional Requirements — How to Get Them in Shape

"And by the way, the system needs to be up 24x7, it must be fast, security is a top priority, and scalability is mission critical. Oh yeah, and maintainability is important also."

The requirements (or rather expectations) on non-functional system qualities are very often over-general, vague or unrealistic. Being a senior developer or technical system architect, these expectations will probably end up in your lap in the form of a requirements document (e.g. the RUP "Supplementary Specification"). With a requirement document of that sort you are surely bound for failure (e.g. someone will always find some part that is “slow”).

In this session we investigate some ways to improve the quality of non-functional requirements (NFRs). We try to make the meaning of each NFR precise, identify trade-offs between them and think about how we can make the business side make priorities (which is not always easy).

Hopefully, this session might help you form the next requirements document so you at least have a fair chance of success.

Dan Bergh Johnsson is working on creating a toolbox of technologies, tools, and methods for building secure system architectures. He does this through his job as an architecture and security consultant at Omegapoint AB, one of the leading IT-security companies of Sweden. At Omegapoint he leads the process of applying the company's security competence in the Java/J2EE space. From his background in programming Dan has taken a broader interest in architecture in general and system integration in particular. This is also the background for his interest in high-quality practises such as unit testing. Through consulting and teaching he has played a pioneering part in the introduction of Java and J2EE in Sweden. In his spare-time Dan is a dedicated dancer and member of the swing dance show troupe Sanslös Swing. Email: Dan.Bergh.Johnsson@omegapoint.se