«Sharam Hekmat PragSoft Corporation Contents 1. INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 SOFTWARE TOOL 1.4 GLOSSARY OF TERMS 2. ...»
• Ultimately it is the user interface that shapes the way the user works. If the conceptual model portrayed by the user interface is a close reflection of the user’s work practices, then it will be quickly understood and accepted by the user. On the other hand, if the conceptual model is so complex, confused, or alien that the user finds it very difficult to relate to, it will put unnecessary burden upon the user and reduce his/her productivity. In other words, the user interface should be designed to match the user, not the other way round.
Common sense dictates that user interfaces should be designed based on the principle of recognition rather than recollection. A successful user interface is one that draws upon the background and business experience of its users to provide an intuitively obvious way of using it. A poor user interface is one that requires extensive formal training and/or memorisation of an extensive list of commands and procedures.
4.3.1 Metaphors Sensible use of metaphors can make a user interface much more accessible to its target audience. A metaphor is “a figure of speech in which an expression is used to refer to something that it does not literally denote, in order to suggest a similarity”.
A user interface metaphor relies on a user’s familiarity with a common concept in order to suggest
how to do something unfamiliar. Graphical User Interfaces (GUIs) are full of such examples:
• Use of a ‘trash can’ as a means for deleting files.
• Use of ‘drag and drop’ as a means for moving objects around.
• Use of ‘desktop’ as a way of visualising and organising your work.
• Use of ‘directories’ as a way of organising files.
Before we go about designing a new user interface, we should spend some time exploring potentially useful metaphors that can enhance the design. These should then influence the design.
There are two ways to present a user interface design:
The latter is always preferred, for two reasons. Firstly, people find it easier to relate to a mock-up.
They can play with it and quickly come up with feedback about its good and bad aspects. Secondly, experience suggests that a good user interface is almost never created in one go. It often involves many iterations, during each of which the interface will undergo (sometimes major) changes. It is invariably more productive and more effective to do these changes in a visual development environment.
The creation of a mock-up should be guided by the following principles:
• The scope of the mock-up should be the business processes (or use-cases) that the application will support. If someone suggests a screen or GUI element that cannot be directly or indirectly justified in terms of this scope, it should be excluded.
• The objective of the mock-up should be to show how a business process (or use-case) is performed both in terms of the static information presented (i.e., screens) and the dynamic flow between the screens.
• Under no circumstances, a mock-up should be allowed to become anything more than a mockup. There is always the risk of some users or business decision makers concluding that simply enhancing or ‘finishing’ the mock-up will result in the final application. That is why that the purpose of the mock-up should be clearly established and communicated up-front: to agree on a user interface design, and nothing more. The mock-up must be understood as a throw-away artefact.
• Involving potential end-users in the design process can save a lot of time and energy. They not only can come up with valuable insights and ideas that would have been inaccessible to the technologists, they can also become potential champions in introducing the user community to the new application.
5.1 Multi-tier Architectures Modern information systems tend to be distributed: they use a multi-tier, client-server architecture
that can support the non-functional requirements of the system. These requirements often involve:
• Geographic distribution. Most large businesses are geographically distributed and require their information systems to be accessible irrespective of geographic boundaries.
• Scalability. Once implemented, an information system may be required to serve the needs of a growing user base. It should be possible to scale the system by increasing the computing resources, and without resorting to design changes.
• Heterogeneous computing environment. Most organisations have a multi-vendor computing environment, consisting of incompatible hardware and system software. An information system may be required to operate across the boundaries of such incompatible domains.
Distribution of an information system involves tiering, which divides the system into separate partitions that can run on separate (but networked) physical resources.
Tiering should not be confused with layering or, put differently, a software tier is not the same as a software layer. A software layer is a conceptual abstraction, which packages a defined set of functionalities and makes it accessible through a logical interface. A software tier, on the other hand, is the physical packaging of the implementation of one or more software layers.
Layering and tiering are the means through which an architect logically and physically partitions a system, respectively. The software layers are defined during application modelling, whereas the software tiers are established during system modelling. Layering affects tiering. By defining layers, an architect is providing opportunities for creating tiers.
Early client-server systems were mainly two-tiered, consisting of a front-end and a back-end tier.
Under this model, the front-end (also known as a fat client) contains the presentation as well as the business logic, and the back-end consists of a database system. A two-tiered system is inflexible in a
number of ways:
• There is no logical separation between presentation and business logic, which makes maintenance difficult.
• The system is not scalable.
• In most cases, the system lacks openness, because it is based on a vendor’s proprietary technology (e.g., database vendor’s technology).
UML Process 37 Copyright © 2005 PragSoft Modern client-server systems are mainly three-tiered, where the business logic is separated from presentation and occupies its own middle tier. This approach provides a basis for overcoming the shortcomings of two-tiered systems.
The main challenge of building an effective three-tiered system is in designing and building the middle tier. This tier needs to be designed in a way that delivers all the promised advantages of three-tiered
• It needs to remove the business logic from the front-end, so that the front-end only deals with presentation concerns. This is known as the thin client approach.
• It needs to componentize the business logic in a way that can be distributed across hardware resources so that it becomes scalable.
• It needs to provide open interfaces so that other systems can be integrated with it with minimal effort.
The middle tier is often designed such that it can be subdivided into further tiers – hence the term ntiered – to achieve greater scalability and to provide additional open interfaces. For example, it may
be broken into these three sub-tiers:
• A dynamic content tier that generates the content to be presented by the front-end.
• An application tier that realises the business processes offered by the system.
• A business object tier that realises the business objects underlying the system.
Productive development of the middle tier requires the use of middleware technology, which provides the necessary tools for packaging the tiers, defining the interfaces between them, communication across the tiers, and transaction management. These are complex, system level activities that are well beyond the scope of a typical project. Middleware eliminates the need to work at this level, and provides a reliable basis for the project to focus on developing business functionality.
www.pragsoft.com 38 UML Process Component technology goes a step further from middleware technology. It also provides a means for packaging functionality so that it is highly independent and reusable. Whereas middleware allows one to develop business functionality without dealing with low-level system issues, component technology aims to provide a basis for productively developing new functionality by reusing an existing set of components (as well as creating new ones for future reuse).
System modelling must deal with all these issues. Specifically, it must:
• Deliver a proper tiering model into which the software layers map.
• Define the abstractions (e.g., components) that comprise each tier, and show how they support the application model.
• Select the technologies that are to be used to build the system (e.g., middleware/ component technology, persistence technology, presentation technology, scripting technology).
5.2 Front-End Models Under the thin client architecture, the front-end deals with presentation only. Based on the
requirements, the front-end may be designed according to one or more of the following models:
• Conventional client. This is a traditional style GUI client that involves intensive interaction between the user and the system (e.g., as in a spreadsheet, a word processor, or a CAD system). These interfaces go beyond the simple input/output of data in most business applications, and require the lower-level controlling of the windowing system to deliver the expected performance and ease of use. Although the client is not fat, it does not have a zero footprint, as it needs to contain components that can support the interaction and communicate with the middle tier.
• Page-based client. This is a browser-based client (i.e., runs within a HTML browser) with zero footprint. The interface consists of a set of web pages, through which the user enters and/or views data. A web server in the middle tier receives the data entered by the user, and generates the dynamic HTML to be displayed by the browser.
• Content-based client. This is also a browser-based client, but is implemented as a downloaded applet that runs in the browser and communicates with a servlet in the middle tier’s web server.
This is useful when we need to provide functionality directly at the front-end that helps a user organise and interact with the system. In this case, the server exchanges raw content (typically expressed in XML) with the client instead of HTML pages.
Because of their simplicity, flexibility, and web-readiness, more and more business applications are adopting the page-based and content-based styles. The key difference between these two is the point of control for presentation. With a page-based interface, the client receives preformatted presentation (i.e., HTML) from the middle-tier, which it cannot alter. In this case therefore, the middle-tier determines presentation. In a content-based client, however, the middle-tier delivers raw data (i.e., content) to the client, and it is up to the client to determine how to display it. This is closer to the conventional client model.
5.2.1 Screen Specifications By the end of application modelling, the user interface concept (including mock ups) should have been established, so that once system modelling commences, the expected look and feel of the user interface (and the underlying metaphors) is well understood.
Although the user interface concepts developed during application modelling include the actual screens, they do not get into the details of each screen. The layout of each screen is rough and not finalised, the widget types and the type of data to be displayed in each widget is not fully specified, and the data entry validation rules are excluded. These details are specified during system modelling.