Model-driven development: the good, the bad, and the ugly

IBM Systems Journal,  July-Sept, 2006  by B. Hailpern,  P. Tarr

• E-mail
• Print
• Link

INTRODUCTION

Most developers operate by sitting down with their favorite text editor and typing in their program, attempting to compile it, making changes, compiling it, testing it, and so on until the program "works." Sometimes the various reasons for design decisions are captured in comments or other documents. Often, they are lost to posterity. Those rationales and design decisions are, however, critical for the success of a long-lived, ongoing, high-quality programming product. Hence, the standard laissez faire approach to programming that many practitioners learned must be replaced by a more disciplined engineering methodology.

Various software-engineering methodologies (1-5) describe processes whereby requirements, architecture, design, implementation, and testing information--along with their interrelationships- can be captured. Why is this information preserved at all? Maintaining this captured data may be a requirement of a customer or mandated for software quality certification. In addition, it may be essential to the development organization, when the development of software extends beyond a single individual developer or development team. It can also be useful or required when teams are distributed geographically (i.e., when requirements are gathered in one city, but code is developed in another). Then this captured data becomes a vital communication link between the teams for many purposes, even as a contract between them. When a software product takes a long time to develop or has multiple versions over time, then this captured data becomes essential to support the institutional memory as team members leave the project or are required to revisit parts of the software that they have not seen for some time. For large ongoing programming products, capturing and maintaining this data is critical to the success of the product.

It is challenging to convince development teams to create the information in the first place, because it costs time and money that could be used to meet immediate deadlines. It is even more challenging to ensure that the critical information is kept current as changes to the requirements or system are made over time, especially when some information will never be critical and some critical information will "age" and eventually stop being critical. In both cases, the cost of creating/updating the information lies on one part of a team, but the benefit usually accrues to someone elsewhere or "elsewhen." Yet once a development process can rely on the existence of current, accurate information, opportunities for automation abound. Everyone wishes the information were available when questions arise about why some concept was included or excluded or tested or not tested, but collecting and maintaining this data costs time and money.

How then should one describe and preserve the various documents (and other artifacts, such as program comments, test scripts, architectural diagrams) associated with a software project? The simplest answer is to "do what comes naturally." Requirements are often written (text) documents (with bullet points or textual scenarios). Architectures are (unfortunately) frequently just pretty pictures with annotated details of programming interfaces. Programs are almost always source code in some programming language. Test suites are usually embodied by scripts and regression test data. "Bug" (unexpected defect) reports are kept (if at all) in databases or logs. The problem with this simplistic approach is that none of the meta-information associated with these artifacts is captured, and therefore, nothing explicitly relates to anything else, even though the relationships are clearly present. If requirements are documented in unstructured text, what chance does a person (or a system) have of matching them to an architectural element or injecting task automation? What chance is there that someone else will understand the requirement a year later? How well can we understand C code without (or even with) comments? Why was a particular test case included and is it still valid?

An alternative to this multidocument, natural collection of information is to use a "single source" approach, where a given concept is represented only once, in one type of software-engineering electronic artifact, rather than having multiple artifacts per concept. This approach can help reduce the number of types of artifacts and the interrelationships among those artifacts. It does not, however, eliminate the problem described in this section. Interrelationships among concepts (and hence, among artifacts) still exist. Moreover, interrelationships to existing libraries also exist. (6-8)

Model-driven development (MDD) is a software-engineering approach consisting of the application of models and model technologies to raise the level of abstraction at which developers create and evolve software, with the goal of both simplifying (making easier) and formalizing (standardizing, so that automation is possible) the various activities and tasks that comprise the software life cycle. MDD imposes structure and common vocabularies so that artifacts are useful for their main purpose in their particular stage in the life cycle (such as describing an architecture), for the underlying need to link with related artifacts (earlier or later in the life cycle), and to serve as a communication medium between participants in the project (over space or time).