Architecture and Design Issues

I l @ ve RuBoard

It's not unheard of for developers to just jump in and write code ”a sort of design-as-you-go approach. Such enthusiasm is laudable, but it rarely leads to applications that are maintainable or extensible. It's best to view the development process as only a small part of a much larger, system-level approach.

"Design" can mean many things in software development. When you write a function, you're effectively designing that function's implementation. At a higher level, someone had to design the function's interface (access level, name , parameters, and return values) as a part of the larger software system. Moving further out, someone had to sit down and draw up the system's functional and feature requirements. All of these tiers of design contribute to the overall success of any project. Failure to adequately design at any level will lead to problems that put the budget, schedule, and ultimate success of a project at risk.

More Info

I'll touch only briefly on the software development process, so you might want to consult Code Complete by Steve McConnell (Microsoft Press, 1993) for more information. This classic book details a process-oriented approach to software development.

Before you write even a single line of code, you should have an appropriate architecture and have as much of your design detailed as possible. The more time you spend in the design phase, the less time you'll spend fixing design- related bugs later. Keep in mind a fundamental truth of software development: bugs cost less to fix the sooner they're found.

Analyzing Business Requirements

Before you start on any project, you should clearly define the target market and what problem you're trying to solve. Understanding the customer problem is the key to success, not code. No matter how well the code is written or how efficient it is, it won't be of any use if it doesn't help solve the customer's business problem. Many a project has failed because the designers simply didn't understand what they were trying to achieve. You should design with extensibility in mind so the application can accommodate the customer's changing needs. A good market assessment, with help from folks in the field, can be critical to determining your application's business requirements.

Defining the Technical Architecture for a Project

The design process can be crudely broken down into two phases: logical design and physical design. Logical design is when you logically organize and segment your application into assemblies, namespaces, and classes. The process is about strictly enforcing architectural integrity. Physical design refers to how components of the application are physically separated. In this case, you must think in terms of implementing physically tiered architectures.

Visual Studio .NET Enterprise Architect

Visual Studio .NET does not provide anything to help you through the business requirements phase, but it has a plethora of tools to help you through the physical and logical design phases. It also offers tools to assist with other aspects of team development, including

• Visio for Enterprise Architects (for Unified Modeling Language [UML] code modeling)

• Enterprise templates (for defining project templates and development policies)

• Microsoft Visual SourceSafe (for source control)

Most of the features described in following sections require the installation of Visual Studio .NET Enterprise Architect, Visual SourceSafe, and the Visio product that accompanies Visual Studio .NET. If you don't have these installed, it might be a little tough to follow along.

Note

If, when you install Visual SourceSafe, you select the Custom option, be sure to select the Enable SourceSafe Integration option.

I l @ ve RuBoard