Technical Design:System design overview

9.3 System design overview

Any large and complex system needs to be divided into layers if it is to be comprehended and managed. The system design for the theatre booking application will follow a three-tier client-server architecture. A client-server architecture links computers such that some computers – servers – perform functions for other computers – clients (usually end-user PCs). Indeed, this is how the worldwide web works. The user browses the web using a client PC that can request web pages (a service) from Internet web servers.

The three layers of the application can be configured in different ways (figure 9.3), ranging from server-intensive (distributed presentation) to client-intensive (distributed data management). For the Theatre Booking System we will take a straightforward approach: remote presentation. The presentation layer will be handled by the user's web browser. The business logic layer will reside on the server, but some of it could be distributed to the client (distributed function) to reduce network traffic and server load. For example, form validation and simple calculations, such as VAT (sales tax), could be handled using JavaScript or a Java applet downloaded by the client. Data management will reside on the server. Although cookies will be used to store data on the client, for example, to identify returning customers, client-side cookies are only used for transient data. Permanent data will be stored on the central server since cookies are ephemeral and specific to individual client PCs.

The architecture of the theatre booking system consists of three layers: business data services, business logic services, and user presentation services (figure 9.4). In UML notation, each of these layers is represented as a package. The user presentation services are the responsibility of the client, while business logic and business data services will reside on the server. The business logic services will handle business functions such as 'find available seats at performance', and the business data services layer will be responsible for maintaining details of productions, performances, ticket transactions, etc.

The UML stereotype <<import>> in figure 9.4 indicates that one layer has access to the contents of another layer, for example the user presentation layer  can access the business logic services, but not the other way around. This architecture will make the application easier to maintain and extend in the future; changes to the databases or the addition of new business logic can be localized to individual layers such that they are transparent to the invocating layer. So, if the way the seat allocation algorithm works was re-specified, then the change is localized to the business logic layer – no changes are required to the user presentation services, assuming that the interface exported by the seat allocation business logic is unchanged.

9.3.1 Design constraints

In some situations the development team start with a blank sheet of paper and choose technologies for the project based on the system requirements. In other cases, the project team is mandated to use specified technologies, perhaps because these are the house standards for the organization or even just the favoured technical platform of a senior manager. In practice both of these scenarios – the blank sheet and the mandated platform – have their drawbacks. A too restrictive approach can result in the project team being forced to use inappropriate technologies, i.e., differences between this project and previous projects have not been recognized. But, what could be wrong with the project team being given carte blanche? Unless it is carefully managed, too much choice can be problematic as well as it can lead to endless evaluations and the introduction of new technologies for which the organization has inadequate infrastructural support (skills, experience, operating procedures, quality assurance, etc.). We want to avoid the situation where everything looks like a nail – our only tool is a hammer – but we also want to minimize search costs and capitalize on the existing skill base.

The major constraint on the design of the theatre booking system is that it must be publicly available via the Internet. This immediately places technology constraints on the project: some variant of HTML (and possibly XML) is going to be needed to serve up pages on the client's browser and an Internet server is going to be needed to host the web pages. Application development will require a database technology that can be accessed via the Internet server and a server side programming or scripting language will be needed to develop the system functionality. Within this broad constraint there are still plenty of technology platform decisions to be made before physical design can be completed:

• What operating system will the web server run on (Linux, Windows/NT, Unix)?

• What database will be used (Microsoft SQL Server, Oracle, mySQL)?

• How will the server-side business logic be developed (Active Server Pages (ASP), ColdFusion, Perl, Java, C++)?

For logical design the choice of technology platform should be irrelevant – that's why it is called logical. However, as the design becomes more physical and detailed (figure 9.2) then the choice of technology impinges more and more. For example, the physical database design needs to take account of performance issues, and as a result the physical design will in all likelihood differ from one database management system to another.