Model Refinement   «Prev  Next»
Lesson 1

How to Refine the Software Model

Rethinking Systems Development

New books and articles are appearing on analysis patterns and refactoring the development process. Analysts are recognizing that our development processes need to support repeated refinement and our tools need to support this approach. In short, our development processes are broken, and we need to apply deliberate effort to rethink our approach to systems development.
The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for
  1. planning,
  2. creating,
  3. testing, and
  4. deploying
an information system.

The systems development life-cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both.
A systems development life cycle is composed of a number of clearly defined and distinct work phases which are used by systems engineers and systems developers to plan for, design, build, test, and deliver information systems. Like anything that is manufactured on an assembly line, an SDLC aims to produce high quality systems that meet or exceed customer expectations, based on customer requirements, by delivering systems which move through each clearly defined phase, within scheduled time-frames and cost estimates.
Computer systems are complex and often (especially with the recent rise of service-oriented architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of SDLC models or methodologies have been created, such as
  1. "waterfall";
  2. "spiral";
  3. "Agile software development";
  4. "rapid prototyping";
  5. "incremental"; and
  6. "synchronize and stabilize".

In recent years, object-oriented development concepts and methods have received a lot of attention. Some outstanding success stories sing the praises of objects. The claims run as high as 90% savings in time and money, 70% to 90% savings on code.
The counterpoint to these claims is an industry-wide savings of only 10% to 30%. Some development teams even slow down because the learning curve is so steep for the new technologies and techniques. Research into why these powerful new concepts are not yielding the expected results has identified three very important causes:
  1. People using the new technologies are still approaching analysis and design from a procedural and/or data-centric perspective.
  2. The systems development process is not closely linked to a business reengineering process.
  3. Reuse is not a priority.
This module focuses on the attitudes and practices that will help you avoid common pitfalls in software design.


The first section examines the inherent complexity of software and the ways in which complexity manifests itself. We present the object model as a means of helping us manage this complexity. In detail, we examine the fundamental elements of the object model:
  1. abstraction,
  2. encapsulation,
  3. modularity,
  4. hierarchy,
  5. typing,
  6. concurrency, and
  7. persistence.
We address basic questions such as "What is a class?" and "What is an object?" Because the identification of meaningful classes and objects is the key task in object-oriented development, we spend considerable time studying the nature of classification. In particular, we examine approaches to classification in other disciplines, such as biology, linguistics, and psychology, then apply these lessons to the problem of discovering classes and objects in software systems.

Module Objectives

In this module you will learn to:
  1. Apply encapsulation throughout your models and your process
  2. Apply cohesion and coupling throughout your models and your process
  3. Focus on responsibility to improve cohesion and coupling
  4. Understand the purpose and process of refactoring
  5. Apply some guidelines for assigning attributes and operations

Domain Driven Design