As part of the emerging MCSD.Net certification track, the Solution Architectures exam (70-100) has been revised. The new test, "Analyzing Requirements and Defining Microsoft .Net Solution Architectures," (70-300) will go live in February 2003. It covers some of the most difficult topics related to software development, taking you beyond the code of whatever platform for which you design and into the reasons and processes for developing it. In this study guide, which I created based on my impressions after taking the beta version of the exam, you'll be exposed to many of the topics covered by this exam -- including requirements gathering, technical architecture, conceptual and logical design, data modelling, user interfaces, and physical design -- all in reference to Microsoft .Net. Prepare for the 70-300 exam with our study guide
This article is part of a downloadable study guide that will expose you to many of the topics covered by this exam. In the study guide, you'll learn how to accomplish a variety of design tasks, including requirements gathering, technical architecture, conceptual and logical design, data modelling, user interface design and physical design, the Microsoft .Net way. An important part of the design process is translating a conceptual design into a logical architecture. This translation involves identifying the logical design points, choosing from the various types of application interfaces, and then using that information to build a broad design specification that identifies the components and modules that make up the solution. Finally, you'll need to review your proposed solution to ensure that the business rules are correctly incorporated into the design and to benchmark the impact of this logical design on the goals of performance, accessibility, security, scalability, maintainability, and extensibility. (PASS ME goals). Types of application interfaces
When a client asks about setting up an application for them to do a certain task, for example, "I need something that lets me manage my contacts. Can you do that for me?" my first impulse is to answer, "Yes, I can do that in 144 different ways. Which way shall I choose?" When you're translating the conceptual design into a logical form, you'll need to consider the types of application interfaces and which of the many ways that you can build it will be the best for your solution. In most cases, you'll wind up with some combination of the following application types:
- Desktop applications
- Web applications
- Tiered applications
- Collaborative applications
A desktop application is the standard form-based application with which all GUI users are familiar. These types of applications usually fall into one of several classes:
- Single document interface (SDI) applications are the simplest type, allowing a user to have one active window open in any single instance of the application. Imagine a version of Word that allowed you to edit only a single document at a time.
- Multiple document interface (MDI) applications can have many active windows open simultaneously, usually inside a single main parent window. The menu items available on the parent window will change based on which functions are available when working with the active window. Word and Excel are classic examples of MDI applications.
- Console applications run at the command prompt. These are usually system utilities or services that require little, if any, user interaction.
- Dialogue-based applications in Windows are usually referred to as wizards. These applications run as utilities that allow users to perform complex linear tasks by answering a few questions or following a few steps.
Web applications have many benefits over desktop applications, including central administration, easy updating, and uniform client features. The single big downside is that they usually won't work if you don't have access to the server. However, even this shortcoming is addressed by .Net, which includes support for disconnected Web applications and even for disconnected databases. Tiered applications
In a tiered solution, functionality is divided into "tiers" of components, usually hosted on other machines. When designing a tiered application, you'll want to identify the various tiers necessary for it to work when you're translating your conceptual design into a logical one. The big advantages of tiered applications include scalability and ease of maintenance. The downside is sheer complexity. Collaborative applications
The final and most complex type of application is the collaborative application. An example of this application type is Microsoft NetMeeting's whiteboard feature, which allows multiple users to draw on it at the same time. All of the whiteboard's users can see any changes in real time. Visual Studio .Net, which allows many developers to work on the same application at the same time, is another example of a collaborative application. Logical, modular, and component-based design
Once you establish your conceptual design points and identify the type of application you'll use to build out that concept, you will have a foundation on which to build the solution. You can then begin to design the actual components and services that will make up the deliverable product. As with all design elements, the components and service definitions should be well documented and well thought out before coding begins. Components
If you tell a programmer that you want a component, you'll get an ActiveX control, Java Class, or .Net Assembly, depending on the platform. If you tell a software architect the same thing, however, you'll get something different. To a software architect, a component means any chunk of a solution that can be isolated as a set of functions and features that also relates to other components of the same solution. For example, an architectural component could be the set of database-stored procedures or the redistributable client programs that ship on CD. Or it could mean the set of skills that the users will need to have to work with the end solution. You'll need to think about components like an architect would to flesh out your component design. Services
Programmers think of services in terms of a Web service, COM+, or protocol server. However, to a software architect, a service usually means paying a fee to an individual or organisation in return for an ongoing commitment to support some need. This could be $500 (£302)/year to VeriSign for a code-signing certificate or $250/month to an ISP for a low-bandwidth, static IP connection. If this kind of ongoing support is required by your solution, you'll want to make sure that it's well documented in the solution proposal. Business rules incorporated into object designs
Whether your solution is a set of components, a suite of services, or more likely a combination of the two, you'll want to make sure that it incorporates the organisation's business rules: those rules that define or constrain some aspect of the business with which your solution is concerned This process has a high propensity for being a point of failure for the solution as a whole. No matter how solid or well designed the solution, if it violates an important business rule -- such as "Every purchase order must be approved by a member of management" -- it will be considered a failure. Impact of logical design on PASS ME goals
The last part of designing the logical, modular, and component-based solution actually occurs at the end of the design process and continues for a bit afterward. You have an acceptable solution, but now you'll want to grade how well it met or exceeded expectations. This where you gather the metrics to determine whether the solution meets the PASS ME goals. Does it perform well? Is it easily accessible by those who need access? Is it stable and secure? Is it easy to maintain? Will it extend well into the future? Created by developers, for developers, Builder.com brings software developers fresh, real-world perspective on topics from programming to architecture to management. Builder.com will improve the way developers work with the information, tools, and services to help them conquer the challenges they face everyday in real-world development.
For all job and work-related news, or to search for a job and get information on training, go to ZDNet Jobs.
Let the editors know what you think in the Mailroom.
