Thursday, December 9, 2010

Bottom Up and Top Down Software Development

Software Engineering is a rapidly changing beast, as software itself, being made of "pure thought stuff" (Brooks, Mythical Man Month) rapidly changes. Not only has the process orientation of the industry changed, from cascading waterfalls to Agile methodologies (Agile Manifesto, Beck et al), but the design focus has changed.

In 1980s, design and architecture tended towards the development of large models that fully specified the software. The emphasis on modeling and architecture led to favoring code generation and a focus more on the high level "how things work." Tools like IBM Rational Rose were seen as holistic tools that could allow full specification of the software process from the ground up.

These tools have gained limited market share. As part of the Agile Manifesto's emphasis on "Working software over comprehensive documentation," the emphasis on system specification via UML modeling and up-front specification has given way to TDD development (Beck, Test Driven Development by Example). This code-first approach has found wide acclaim with software developers and industry, and even design is being driven by it's ramifications via the use of Mock Objects as a design tool. (Freeman et all, "Mock Roles Not objects" http://static.mockobjects.com/files/mockrolesnotobjects.pdf)

The basic TDD workflow is fairly simple: write a test that fails, write just enough code to make it pass, refactor and evolve. This approach has won acclaim because it breaks the intractible software system into manageable chunks. But why hasn't modeling received similar treatment?

In theory, it's just as easy to write a test and make it pass as to write a class diagram for a single class, then implement it. Write a failing test for a new method, add it to the class diagram, then add sequence diagram that stubs that class and that method.

Why isn't this done more? Is it poor support from the tools, i.e. it's hard to quickly create a modeling artifact and bind it to the project in the same way it is for tests? Is it lack of developer buy-in, i.e. models are completely unnecessary? Is it a perception of complexity of the modeling constructs themselves, i.e. the models are useful, but they're too complex and add little value?

No comments:

Post a Comment