Udi Dahan explains how his team identified and overcame unforeseen problems while developing a large-scale software + services trading application.

We introduce you to “Oslo” and demonstrate how MSchema and MGraph enable you to build metadata-driven apps. We’ll define types and values in “M” and deploy them to the repository.

Domain driven design can be most readily applied to stable domains in which the key activity is for developers to capture and model what is in users' heads. But it becomes more challenging when the domain itself is in a state of flux and development. This is common in Agile projects, and happens also when the business itself is trying to evolve. This article examines how we used DDD in the context of a two-year programme of work to rethink and rebuild guardian.co.uk. We show how we ensured the evolving perceptions of our end-users were reflected in the software architecture, and how we implemented that architecture to ensure future changes. We provide details of important project processes and of specific evolutionary steps in the model.

Traditional code generation provides great developer productivity, but doesn’t help address the need for runtime flexibility or adaptability. A model-driven approach offers many of the same productivity benefits as traditional code generation, with the added ability to adapt to changing or dynamic runtime requirements. In this article I will compare and contrast these two approaches.

This article introduces RGen, a modelling framework inspired by openArchitectureWare. RGen uses internal DSLs for defining metamodels and offers a full modelling stack for Ruby.

With the growing expense and complications of building software, we are continually seeking to increase our productivity while maintaining user satisfaction, but that goal is a global concern that is valid to just about any company of any size. How does a Global Systems Integrator (GSI) manage to become more agile and cost effective, while its developers may be spread across many geographic regions? How does a company know what it knows? And more importantly, how does it leverage this knowledge in a consistent way? These may seem like very strange questions and ones that would make a smaller company do a quick pulse check and wonder, "What's the problem?" The truth is that the larger the company, the more assets are collected and the easier it becomes to overlook these assets in a rush to solve a client's problems. We fail to build systems in a consistent manner. Although we can take some amount of pride when a system is delivered on budget and on time, how many projects fail even though we know what we know? Let us look at ways in which a GSI can take advantage of a software factory approach.

This chapter provides historical context for why the Object Oriented paradigm was developed.

Once during an interview, I was asked why I didn't apply MDA over all software projects I leaded. The question should be hooked as a point of discussion on MDA misconceptions, and generally, on modelling and UML. Unfortunately these interpretations are hindered by a phenomenon that a famous observer of human events (Mark Twain) revealed, that I repropose it again in IT terms: People commonly use UML like a drunk uses a lamp post; For support rather than illumination.

With software applications becoming increasingly complex and the demand for rapid deployment (including rapid prototyping) of software applications increasing, automated tools and updated methods for software development have become necessary. It follows that these new software development processes require new approaches for software safety. One company’s 15-element Software Safety Process has now been adapted to a model-driven, spiral software development effort. This process provides an open working relationship to incrementally identify the causes of hazards at different levels.

Software product lines are designed to promote the efficient reuse of artifacts between projects. Domain specific modeling allows for the faster development of custom applications within a particular domain. Each provides powerful techniques for developing applications more efficiently, but together they provide a particularly effective toolkit for the faster development of custom applications. In this article I'll review an internal software product line that I have been involved with developing for a number of years, designed to rapidly build semi-custom web applications.