Algol (562407), страница 11

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 11)

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

1. 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.

2. 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.

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)

Dr K. Lunn

Meniscus IT Ltd.

email: kenlunn@firstnet.co.uk

Abstract

One of the most fundamental problem of software engineering is the construction of suitable abstractions. Another is the adequate communication of functionality between all parties involved in the construction and implementation of IT solutions, from end-users, through business managers, to software developers. The approach described here uses the notion of business activity (or business process) as a form of abstraction which can be used in a variety of ways to develop specifications and designs for software systems. The method avoids complex notations, at least at the specification stage. The origins of the ideas began with a multi-national company which had a very diverse set of software solutions implemented in similar businesses world-wide. The ideas have been refined and adapted in the functional specification of a system to support elderly care planning in the European Community, and some aspects of that project are reported in brief in this paper.

The business activity perspective has a number of potential uses. At a strategic level it is a good framework for comparing total IT solutions in similar business environments, and consequently can be used as a support for strategic planning of systems. In the procurement process, it provides a good framework for scoping and defining functionality of a required system, and for comparing proposed solutions. In the business reengineering phase, it can be used as the basis for the terminology in describing actual processes and quantifying aspects of changes to business operations. In the software specification and design process it can be used in an object modelling process as a framework for driving the dynamic modelling in a way similar to the event-trace methods of OMT.

The author has used the techniques briefly described here in a variety of consultancy projects. The common characteristic of these projects have been:

• A number of business environments with similar but non-identical needs wishing to share software solutions.

• A need to communicate to senior management, often with no computing background, the scope and functionality of computer systems.

• A need to compare at a gross and at a detailed level the functionality of different computer solutions.

• A need to relate computer systems to business operations.

• A need to quantify the effects of system changes (of both computer and business operations) for the purpose of assessing financial returns and quality improvements.

• A need to involve non-IT staff in the analysis and design of systems.

Although no panacea, the business activity approach has proved to be very effective in communication, obtaining consensus, and co-ordinating group activities. By removing temporal and information flow considerations, which are often a source of confusion and disagreement, it enables a comprehensive map of a business to be constructed; it can be used later to introduce information flow and time dependencies for the purposes of deeper analysis and design.

The approach described here has been pragmatic and driven by the needs of applications. However, a common theme is emerging, and hopefully through the broader application of the techniques they can be related to and/or integrated with established methodologies. The use of the approach in PLANEC has begun to open up the integration into object modelling in a way which appears consistent with and complementary to established approaches.

The PLANEC application

The PLANEC consortium has undertaken the ambitious task of producing a demonstrator computer system which can be used in all member states of the EC; it will support the strategic planning of elderly care provision by a broad range of organisations from municipalities to hospitals and other service providers. The consortium is led by the Stakes Research Institute in Finland, and has partners in Holland, Spain, Germany and the UK, and consists of research social scientists and practitioners in the field of elderly care; a software house has been contracted to construct the demonstrator system, but the responsibility for specifying functionality rests with the social scientists. The author has been facilitating the specification process, firstly by teaching the rudiments of object modelling, and then by introducing and developing the notion of activity modelling.

Although the basic needs of the elderly may be similar in each locality, the provision of services to meet those needs varies widely in type and organisational structure. Each country has different legislation, different infrastructure, and different policies. The greatest challenge, from a software design perspective, has been to devise a suitable abstract description of the problem in a way that can be understood by the social scientists who are steering the development, the software house which will be producing the demonstrator, the potential users of the system, and other interested third-parties.

Object modelling was chosen as a design method for the following reasons:

• it is a good basis for prototype-driven, iterative methods of development;

• there is a good correspondence between some aspects of the modelling and social science methods;

• the methodology is easy to teach at an abstract level;

• the resulting designs are clear and easy to communicate to non-computing personnel.

The project found early-on that the greatest challenge was providing a common framework within which to describe the differing approaches to elderly-care provision. The solution adopted was to introduce ideas from Business Process Re-engineering, using an activity (or process) model. This model was then mapped back into the object-modelling. This method is a novel extension of object modelling, and serves as a useful contribution to computer science in its own right.

A Three-Level Business Activity Model

A business activity is a logical grouping of events which can be agreed as a fundamental element of a business. Although some implicit ordering may emerge, the intention is to describe a whole business as a set of about 200 to 300 activities without concern about the order or the interactions of the individual activities. These activities are grouped on three levels. The top level should be no more than about ten activities. For a manufacturing company, these activities may be:

• PLAN - develop the tactical and strategic plans of the company

• BUY - all purchasing activities and the recording of these activities, including payment

• SELL - all selling activities and the recording of these activities, including revenue

• MANUFACTURE - all manufacturing activities and the recording of these activities

• DEVELOP / DECOMMISSION - all construction and decommissioning of plant

• FINANCE - monetary flow and control activities, including investments, etc.

• RESEARCH - all research activities

It can be seen that at the abstract level these are very gross divisions of the company behaviour, which may be considered too obvious and simplistic. However, experience shows that it is easy to obtain broad agreement on these. Using a group of experienced researches and practitioners in the field of elderly care, a workshop produced the following breakdown of elderly care provision into:

• POLICY - Setting of national policy, regional policy, local policy. Setting of voluntary organisation policy. Identification of cultural norms. Commercial organisation policy (e.g. health care, residential homes, sheltered houses). Negotiation with providers, planners, financiers, and with different policy makers.

• PROVIDE / CONSUME - Activities involved in the provision and consumption of care at the organisational and individual level. Organisational planning. Purchasing, provision. Developing of the service. Personnel and day-to-day management. Negotiation with planners and financier. Business plan and implementation. Cash management and financial management. Assessment of needs. Allocation of care.

• MONITOR / EVALUATE - Estimation of demand. Creation of information services. Identification of goals. Setting evaluation criteria. Collecting information. Analysing information. Identifying and reporting successes / problems / failures.

• FINANCE - Raise funds (e.g. taxation, fees, statutory and private insurance). Budget setting. Control of spending. Forward projection. Allocation of funds. Release of funds.

• PLAN - Strategic and tactical planning activities. National, regional and organisation levels. Estimation. Negotiation. Goal setting. Implementation planning. Realisation of goals. Purchase, sell provide. Identification and realisation of policy. Developing of provision.

Agreement on these took less than a morning, and the breakdown has survived six months of scrutiny.

The activity model is intended to hide organisational structure, and simply to describe the functionality of the organisation. Activities may be implemented in many different ways, sometimes even within the same company; for example there may be many types of manufacturing plant within a company, producing different goods, or producing the same goods in different ways. Having obtained the common abstraction it is possible then to map it back onto organisational structure.

Характеристики

Список файлов учебной работы