Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part V...

Developing Specifications.

By: Chris Sully Date: March 25, 2004

Introduction

The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so it is following Microsoft’s recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.

We've looked at the following thus far:

Article I: phase 1 of the process, the Envisioning Phase.

Article II: started on phase 2 (gathering and analysing requirements) focussing on business requirements.

Article III: continued with phase 2, focussing on user requirements and issues surrounding globalisation and localisation of your application.

Article IV: finished off phase 2, focussing on operational and infrastructure requirements.

In this article we look at phase 3, considering issues around developing specifications for the proposed system.

During this phase system requirements are transformed into functional specifications. This is one of the documents produced by the design stage of the project lifecycle, also known as the planning phase in MSF. Planning or design also encompasses Conceptual, Logical and Physical Design. Thus 'developing specifications' which we've somewhat artificially split into a separate topic is performed in parallel with the other design activities with functional specifications and other design artefacts (which we'll visit in forthcoming articles) being the results.

Some of the goals of the functional specification are to:

• Consolidate a common understanding of the business and user requirements
• Break down the problem and modularize the solution logically
• Provide a framework to plan, schedule, and build the solution
• Serve as a contract between the team and the customer for what will be delivered

As an introduction to the planning/ design phase begins we'll look at some of the general areas you will need to consider.

Firstly, a couple of important higher level questions:

• What is the network solution: Internet/ extranet/ intranet?
• What are the primary considerations for the three general elements of the solution, i.e. UI, middleware and data store?

We'll now introduce a collection of other areas for consideration during the design/ planning phase of the project lifecycle, several of which we'll revisit in subsequent articles from slightly differing angles.

Auditing and logging system activity

You must determine who and what you want to monitor, under what circumstances these events are trapped and kept, and where the information gathered by the process is to be stored.

Minimally you should be planning for techniques to monitor system problems. You might also want to record the application user’s activities for the purpose of maintaining statistical information. In a secure environment you should track attempts at breaching security. You may also want to track system usage.

For such activity storage you have a variety of tools at your disposal: event logs, server level apps like SQLServer, IIS and the Repository.

As an aside, and in case you are unfamiliar with the repository, the Microsoft Repository is an automation application that stores data for tools. The Repository engine object model includes classes that expose their properties and behaviour through interfaces. The Repository contains objects and their relationships as well as their respective property values.

Monitoring and logging system information essentially breaks down in the following manner:

• Ensure that all system errors are recorded to the event log maintained on the server where the application resides.
• Have user activity or other statistical information stored in a database system, such as MSSQLServer.
• Have personal information identifying the user stored in cookies on the user machine with user/ customer account information maintained in a database.
• Data alterations maintained for a legal audit should be implemented through the Repository or the additions of triggers and procedures to the database storing the data.
• User information and application preferences maintained on the user’s behalf should be stored in the registry (or an XML configuration file).
• Permissions should be maintained on sensitive data and auditing implemented to identify attempted breaches and abuse of permissions. Depending on the system these permissions are maintained in the operating system's security log or in a database system designed for security purposes.

Other forms of monitoring and logging are equally important within the environment but fall more on the shoulders of the network administrator rather than the developer.

Note that the log information must be regularly reviewed or there is little point in capturing it!

Appropriate error handling

At each tier appropriate error handling should be implemented, preferably via structured exception handling.

Different error types should be considered: syntax, logic, possible user errors (e.g. data entry) and system malfunctions.

Integration to leverage investment

Data integration is possible through ODBC and OLEDB. Mainframe integration is possible through SNA (System Network Architecture) technologies, such as COMTI (Component Object Model Transaction Integrator). Intranet, extranet and intranet integration can be performed using DCOM or ASP.NET technologies.

Globalization, localisation and localisability

You can expect to see several questions on globalisation in the exam. The most efficient way to increase the global reach of your application is via cultures/ locales – sets of rules and standards that are specific to a given language/ geographical area, e.g. date/ time formatting.

Data storage

Consider what form(s) of data storage are appropriate for your application? Standard SQLServer? XML files?

State management

What's appropriate for your solution particularly with regard to your user population and the sensitivity of information you are handling?

Client-side
Use resources on the client computer/ HTTP connection: viewstate, hidden form fields, querystring, cookies.

Server-side
Use resources on the server computer: session, cache, application.

Constraints to support business rules and validate data

Different forms of data validation exist of various complexities:

• Data type validation: ensure that it matches expected numeric, date, or other type of content.
• Range checking: test data validity against acceptable valid data ranges.
• Code checking: more involved processing that takes the inputted data and tests it against known acceptable values stored in another data store.
• Complex validation might be required when simple test conditions and lookups are insufficient.

Deployment strategies

Will XCOPY suffice or do you need an Installer application. Related issues:

• Will components of your solution be used by other applications?
• Co-existence: you may choose to run new and old in parallel.
• Do you have licensing issues to consider?
• Data migration or integration - which is the better option for your scenario?

Development of the security strategy

Security should be considered throughout the project lifecycle, particularly when it come to the application design, e.g. file system, data access, network, ASP.NET application security, code access, security and data privacy, signing and sealing which we’ll consider in a little further detail.

Data privacy is chiefly a matter of maintaining secure communication channels and encryption.

Encryption options:

• SSL (Secure Sockets Layer)
• TLS (Transport Layer Security)
• IPSec (Internet Protocol Security)
• RPC (Remote Procedure Call) encryption

SSL is the dominant option when it comes to web application security.

Signing: you can sign with a strong name thus guaranteeing the identity. The user still needs to decide whether to trust the identity. Or you use a digital certificate to sign the assembly. This provides additional verification from the 3rd party supplier of the digital certificate.

Sealing: encrypts the message contents with a key that only the sender and receiver understand. In Microsoft environments this is normally achieved with the Kerberos protocol. Sealing is also defined in the Microsoft Global XML Architecture (GXA) by using SOAP standards.

Secure access is achieved via three methods already discussed in this series of articles: authentication, data encryption and authorisation.

Operations strategy

The system's day-to-day operations should be planned with administrative and maintenance roles clearly defined such as:

• Data archiving
• Data purging
• Upgrades/ patching

Planning the system support

Supporting the system after it has been deployed should include plans for finalising documentation for end users, administrative staff and the support team. Maintenance plans and upgrade procedures are also a key part of supporting the system after it is deployed.

Testing

The following should be undertaken at various stages, with the following being categories you might encounter (some overlapping):

• Functional tests: test all features.
• Unit testing: testing individual units of code.
• Coverage testing: which lines of code are executed and in what quantities the executions are occurring.
• Ongoing testing: should occur at strategic landmarks.
• Build testing: when a major release occurs.
• Regression testing: whenever changes are made, re-test.
• Usage testing: allowing for performance tuning and optimisation of the system as it works in a real life situation.
• Integration testing: are the system components and different systems interacting as they should.
• User acceptance testing: let the users loose when the developers and testers have done their stuff and see what issues arise.

Testing will normally be closely tied to the use of a source code control utility such as Sourcesafe. For example a developer may unit test their code module, update it in Sourcesafe and the test team will then undertake integration and regression testing.

Get users involved

Finally, the more you get uses involved the more chance there is that the project will be a success. Getting user 'buy in' to a project will increase the likelihood of their accepting it. Firstly it is likely to better meet their requirements. Secondly, they'll feel like they have contributed to the project and are thus more likely to accept the solution. So pay attention to the user requirements captured when you come to the specification and involve them as much as is possible.

References

Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que

http://msdn.microsoft.com/architecture/

Analyzing requirements and Defining Microsoft .NET Architectures
Microsoft