- •BlackBox
- •Component Pascal Language Report
- •1. Introduction
- •5. Constant Declarations
- •6.1 Basic Types
- •6.2 Array Types
- •6.3 Record Types
- •6.4 Pointer Types
- •6.5 Procedure Types
- •6.6 String Types
- •7. Variable Declarations
- •8. Expressions
- •8.1 Operands
- •8.2 Operators
- •8.2.1 Logical operators
- •8.2.2 Arithmetic operators
- •8.2.3 Set operators
- •8.2.4 String operators
- •8.2.5 Relations
- •9. Statements
- •9.1 Assignments
- •9.2 Procedure Calls
- •9.3 Statement Sequences
- •9.4 If Statements
- •9.5 Case Statements
- •9.6 While Statements
- •9.7 Repeat Statements
- •9.8 For Statements
- •9.9 Loop Statements
- •9.10 Return and Exit Statements
- •9.11 With Statements
- •10. Procedure Declarations
- •10.2 Methods
- •10.3 Predeclared Procedures
- •Function procedures
- •Proper procedures
- •10.4 Finalization
- •11. Modules
- •Appendix a: Definition of Terms
- •Array compatible
- •Parameter compatible
- •Expression compatible
- •Appendix b: Syntax of Component Pascal
- •Appendix c: Domains of Basic Types
- •Appendix d: Mandatory Requirements for Environment
- •Object Lesson 1 - objects and inheritance
- •Introduction
- •Course Aims - Creating Beautiful Systems
- •Why Design?
- •Design methods
- •Objects
- •How do objects relate to other concepts in design methods?
- •Inheritance
- •The big deal about inheritance
- •Clarity
- •Delegation
- •Relationships
- •One to one relationships
- •One to many relationships
- •Many to many relationships
- •Object Models
- •Exercises
- •Object Lesson 3 Analysis - the rudiments of an approach
- •Removing synonyms and/or generalising
- •Look for attributes
- •Irrelevant objects
- •The process of development
- •Prototyping
- •Evolutionary development
- •Charters
- •Why object modelling lends itself to iterative methods
- •Lesson 4 - Dynamic Modelling - Event traces Dynamic Modelling
- •Event traces - building scenarios
- •Progressing the analysis with event traces
- •What do you do with the event traces?
- •Dynamic modelling - state diagrams
- •An example of an object model for a simple computer
- •An object model for genetic algorithms.
- •Business Activity Modelling - a Starting Point for Software Development Applied to The Functional Specification of a System for Planning Elderly Care in the European Community (planec)
- •Abstract
- •Functional modelling - data flows
- •Use Cases
- •Opening up the use-case requirements model
- •Conclusion
- •Business Process Reengineering
- •Conclusion
An object model for genetic algorithms.
Let us now consider another example, this time from the realm of evolutionary computing. A genetic algorithm uses simulations of genes to solve problems. To begin with, we have the idea of a chromosome which is made up of one or more genes. The more genes you have, the more complicated the problem you can try to solve.
The genes themselves can be represented as integers, bit strings, characters, or whatever. Normally they are described as bit strings. But basically they represent some value. Suppose we want to find high values of an equation such as
2x3+3yx2-xz3+5
Now we could represent this with a sequence of three genes, each gene being an integer value for x, y and z. We end up with an object diagram:
The chromosome represents (in a sense) the equation. Each gene defines the value of one of the variables. Now the equation knows how the variables are combined, and so can calculate its value using the integer values defined by the gene.
Of course, this is all very uninteresting, until you start putting lots of chromosomes together in a gene pool. The chromosomes can start with randomly chosen values, and you end up with a large number of equations with different values.
Now, by randomly creating a set of chromosomes in a gene pool, we have effectively generated lots of values of the equation. Some will be greater than others. The genes which represent high values are considered to be "fitter" than those representing low values of the equation. This is where Darwin steps in. Let us look at the operation of the gene pool.
From a randomly generated set of chromosomes, firstly all the chromosomes are evaluated for their fitness, which is done by evaluating the equation which the chromosome represents. Then the chromosomes are selected; strong ones (ie those with a high fitness) have multiple copies made. Weak ones are destroyed. Then the selected chromosomes are interbred, by mixing their genes up in some way. Then the new set of chromosomes are evaluated, and the process goes on indefinitely. Let us examine the state transition of a chromosome.
A chromosome comes into being either by being generated randomly, by being created as a copy of a strong gene, or by the result of inter-breeding. It is destroyed either because it is unfit, or because it breeds with another gene.
Let us look at one way of breeding. An object interaction diagram is a good way of describing this.
Firstly the chromosomes are paired up. Then a crossover point is chosen. Finally, the chromosomes swap tails.
Now we can go back to our object model and add a few attributes and operations.
Having done all this work to define the genetic algorithm, we can now try and reuse it on another problem. Let us suppose that we want to find a good schedule for a truck delivering Christmas puddings to supermarkets in different town centres. The truck must deliver as much product as it can in the day. However, it has to stop after doing three hundred miles. We can use our genetic algorithm to describe the problem thus:
This time the gene represents a particular supermarket rather than the value of a variable. The fitness function would return zero if the schedule broke the mileage limit, or the number of Christmas puddings delivered if the schedule is within the mileage limit.
One of the great benefits of a good design method is the capacity to re-use components. Hopefully you can see from the above example how the simple notion of a genetic algorithm could be re-applied to lots of different problems.
Exercises
One feature of genetic algorithms is the notion of mutation. Periodically a gene mutates, say with one chance in a thousand during breeding. Add mutation to the genetic algorithm design above.
Construct a design for a genetic algorithm system to find solutions to the travelling salesman problem. Starting from home a salesman must visit each of ten (say) towns, exactly once and return home at the end. The objective is to minimise the distance travelled.