Publication: IBM Systems Journal
Publication Date: 01-JUL-06
Delivery: Immediate Online Access
Author: Hailpern, B. ; Tarr, P.
Article Excerpt
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).
The Object Management Group, Inc. (OMG **) defines a particular realization of MDD using the term Model Driven Architecture ** (MDA **). Further, they define a special concept of models that distinguishes those models that take into account the details of the underlying hardware and software (platform) and those that do not. OMG defines MDA to be
based on a Platform-Independent Model (PIM) of the application or specification's business functionality and behavior. A complete MDA specification consists of a definitive platform-independent base model, plus one or more Platform-Specific Models (PSMs) and sets of interface definitions, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support. (9)
MDA begins with a model concerned with the (business-level) functionality of the system, independent of the underlying technologies (processors, protocols, etc.). MDA tools then support the mapping of the PIM to the PSMs as new technologies become available or implementation decisions change.
MDA represents just one view of MDD, though it is perhaps the most prevalent at present. Others also exist, such as Agile Model-Driven Development, (10) Domain-Oriented Programming, (11) and Microsoft's Software Factories. (12) This paper is about MDD in general. However, due to its prevalence and status as a standardized entity, OMG's MDA is used to exemplify issues throughout this paper. This paper is not, however, intended to be a full exposition of the advantages and disadvantages of MDA. It is too early to predict which--if any--of the current MDD approaches will perform best in real-world scenarios.
Thus far, we have defined MDD in terms of "models," relying on the reader's intuition about what models are. We now turn to the question, "What is a model?"
BACKGROUND: TERMINOLOGY AND...
NOTE: All illustrations and photos have been removed from this article.
More articles from
IBM Systems Journal
Beyond predictable workflows: enhancing productivity in artful business processes., 01-OCT-06
Following the sun: case studies in global software development., 01-OCT-06
Business activity patterns: a new model for collaborative business applications., 01-OCT-06
Looking for additional articles?
Click here to search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Click here to search our complete database of Industry & Market reports by text, subject, publication name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company analysis or best practices in managing your organization, Goliath can help you meet your business needs.
Our extensive business information databases empower business professionals with both the breadth and depth of credible, authoritative information they need to support their business goals. Whether it be strategic planning, sales prospecting, company research or defining management best practices - Goliath is your leading source for accurate information. |
