3.1. Start with the Big Picture

 <  Day Day Up  >  

The big picture refers to the broad perspective of a system in development. The big picture includes the system's overall architecture and business purpose.

Most successful systems have a single vision of the architecture. The vision can come from group consensus or from a single respected individual. Design decisions within a system should be consistent with that architecture. [*]

[*] For more information, see "The Third Principle: Maintain the Vision" by David Hooker at http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment.

As Tim and I develop Sam's system, we will keep in mind that its ultimate goal is to function as a multistore system. As the individual pieces of the initial system are developed, the choice between the various design approaches will be affected by that business purpose.

Sam's system is being created in an entirely new environment. Any components that we create (classes, display widgets, etc.) are going to be used in that context. If we attempt to develop components in a vacuum (e.g., without reference to their use), we might have a lot of vacuuming to do when we are finished.

For example, we are developing a new Customer class. Its purpose and interface are driven by its representation as someone to whom Sam rents a CD. An attempt to make the class more general (e.g., so that it can represent a purchaser of CDDiscs ) not only would be unnecessary, but also would complicate its required purpose.

On the other hand, much software development occurs within an existing environment, which represents the even "bigger picture." The environment might consist of the entire enterprise, a single division, or a single department. Gaining knowledge of that environment before creating your own system helps save development time. The environment might have components that you can use in your system. It might have established frameworks that will make your system structure consistent with other systems in the environment. [*]

[*] See The Enterprise Unified Process: Extending the Rational Unified Process by Scott W. Ambler, John Nalbone, and Michael J. Vizdos (Prentice Hall, 2005) for a discussion of enterprise frameworks and environments.

For example, the bigger picture might already contain a Customer class. If that class represents the concept that you want to use in the new system, to create another would be unnecessary duplication. This "bigger picture" also determines how you can develop components. If there were no existing Customer class, taking the effort to make your class more reusable might make sense.

THINK ABOUT THE BIG PICTURE

Decisions within a system should be congruent with the big picture.


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net