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:
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:
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 Hierarchy 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.
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. Any resources are appended to the resource section in the execuatble file format. You will need to purchase the Application Deployment Kit and license 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 Creating an Application tutorial follows much of the above process to describe the implementation of a standalone personal accounts application, PersonalMoney.