Navigation: Appendix B: Dolphin Pattern Book > Application Patterns >
Computers are only as useful as the software that they run. Although there is a trend to make different pieces of software interact seamlessly together, it is still useful to think of software elements as separate applications that can be installed and uninstalled individually.
In Dolphin, an application may be deployed as an executable (EXE) or as a package that can be imported into a development image. In either case we need to define a suitable development process.
Development of an application can be split into several stages:
|1.||Creating a Package|
Dolphin supports the idea of a Package for grouping together all the components of a project. When you start a new project it is expected that you will create a package to hold all the classes, globals, resources and extra methods of the project. As you develop the project the package will record all the objects of that belong to the project and which existing packages are also required for it to run successfully. Packages provide the following benefits:
A package can be exported from the image for porting to another.
It can aid in allowing Smalltalk code to be booked into a source code control system.
If the application contained in the package is to become a standalone executable (EXE) then, once complete, the package can be deployed as such. You will need to purchase Dolphin Professional to create and distribute executables.
|2.||Design of the Domain Models|
Much software models processes that take place in real life. Accounting systems deal with ledgers, customers, orders, invoices etc. These objects that interact in reality are often replicated in an application albeit with only enough essential function abstracted into the software to make it perform its required function. In Smalltalk, each type of object is modelled as a class. Often, additional classes that do not appear in the real world are used to bind together and enable the basic classes. Sometimes, in particularly abstruse applications, few of the classes may be taken from the real world.
In any case, the classes that model the heart of an application's function are its domain model classes. Variously called Entity Models or Business Objects it is most often advantageous to design and implement these domain classes first, before much attention is paid to to how a user will interact with them as part of the system. User interfaces, particualrly GUIs, can be complex as they try to offer a high bandwidth link between the user and the model objects. Enforcing the split between domain model and UI helps maintain the purity of the domain code which, after all, is the heart of the application.
It is beyond the scope of this pattern language to offer advice on the mining of domain classes from a particular problem space. For small applications the choice of classes may be intuitive and obvious. For larger systems the book, Object Models: Strategies, Patterns and Application by Peter Coad may offer useful advice.
Once the domain classes have been abstracted and designed each New Class can be created and tested within the Class Browser tool. Smalltalk provides an ideal environment for this sort of domain modelling. Because of its interactive nature, the domain classes can be instantiated and tested within a Workspace whilst being incrementally developed. Once the basic function is present concern can be given to the user interface.
|3.||Design of the User Interface|
The user interface portion of an application is responsible for interfacing the demands of a single user to the domain model objects. A number of different interface frameworks may be adopted but Dolphin proposes one, Model-View-Presenter, for first choice consideration. For all but the simplest applications, MVP will be a good starting point for user interface design.
If your application is intended to be a development tool for other Smalltalk developers to install into their images then no real effort is required to deploy it. Simply save the package contents to a file using the the Package Browser and distribute the resultant PAC file to your users. More likely, you will want to deploy your application as an executable file. The EXE will contain an executable file header followed by a stripped down image with all the unused and development classes removed. You will need to purchase Dolphin Professional to do this.
The design of an application will be significantly influenced by a fundamental design choice; whether the application is to be standalone or whether it is to follow a client/server model. In the former case, the design is relatively straightforward with the models in the MVP triad generally being actual domain model objects. For client/server applications the design is more complex due to a number of considerations:
|•||The server must support multiple clients. Therefore the domain models must be wrapped to be re-entrant and Process Safe and additional code must be written to manage the client sessions. Often the session handling can be implemented as part of a facade onto the domain classes but more complex scalable systems may make use of Corba or COM to manage the session traffic and to broker the domain objects.|
|•||The MVP model objects in the user interface will not necessarily be of the same class as the domain models. They will almost certainly not be the identical objects to those in the domain, due to the need to transfer the information across the client/server link. Depending on the implementation of the link they may be Proxies onto the original domain models or they may be Adapter classes that wrap them.|
|•||In general, using a set of adapted classes for the MVP models rather than the real domain classes can be useful for issues such as validation. Most domain models don't need to, and therefore shouldn't, perform validation in a client/server system since at the server side the objects can assume they were born healthy. The user interface exposes it's models to the vagaries of the human user and validation is therefore important. This can be shared around the MVP triad but model level validation will require extra code not present in the real domain object classes. Hence new model classes will often be required in the user interface that wrap and adapt the interface to the domain classes.|
The Creating a GUI Application tutorial follows much of the above process to describe the implementation of a standalone personal accounts application, Personal Money.