Ecosystem excercise

5 118 0
Ecosystem excercise

Đang tải... (xem toàn văn)

Thông tin tài liệu

thiết kế

Use class diagrams to make the design. The classes must contain also relevant methods. Write code where needed to express your design ideas. Exercise #1: Creational Patterns You are designing an ecosystem simulator that enables to set up different environments (ecosystems) containing animals and plants that move around and interact with each others. All simulations will have just one carnivore species and one herbivore species, as well as one plant species. There may of course be many individuals (instances) of any species in one simulation. You decide to build a framework that will provide the basic “wiring and engine” for the simulations. The simulations are specialized by changing the set concrete animals and plants, but the framework will know all creatures as one of the three abstract types, Carnivore, Herbivore or Plant. You need to run simulations on two ecosystems, African jungle with creature-set e.g.(lion, antelope, grass) and Finnish forest with creatures (wolf, rabbit, willow). Task 1. How would you design the creation of creatures in the two ecosystem simulations so that you could change the simulation at from Finnish to African at run time, an you could ensure that a careless programmer could not by accident make a lion wander around in the Finnish forest simulation (so called “Ruokolahden leijona”) ? (hint: abstract factory might help). Task 2. Next you would like to easily change at runtime (for instance according to what software user requests) the concrete species of the carnivore, herbivore and plant in a particular simulation, e.g. run Finnish forest simulation with (wolf, rabbit, willow) and then with (wolverine, reindeer, moss). How could you use prototype factory to achieve this? Would there be any tradeoffs regarding the requirements stated in task 1? Task 3. The framework takes care of moving creatures around by asking them to move as simulated time elapses. The creature itself decides whether it moves or not and how much. The framework is also responsible for detecting if two creatures get close enough in order to interact. Whenever this occurs, there are four different cases depending on the type of the interacting creatures: 1. If a carnivore meets a carnivore or an herbivore meets an herbivore either fighting, breeding or nothing takes place depending on many factors like the time of the year (global resource in the simulation) and the state of the animals (opposite sexes or not, starved or not …). 2. If carnivore meets an herbivore, a chase or nothing will take place again depending on the state of the animals (hungry or not…). 3. If an herbivore meets a plant, eating or nothing will take place. 4. If a carnivore meets a plant, nothing will take place. The behaviors above are so complicated that they are implemented in four separate classes: fight, breed, eat and chase. However the framework must not be aware of these different interaction types; it only requests for creation of a new object that takes care of the correct interaction. The framework has a class InteractionFactory that has three different methods c``chh_interaction, ch_interaction and hp_interaction all taking the interacting creatures as parameters and returning a suitable Interaction object for the cases 1-3 correspondingly. Case 4 trivial and is handled in the framework. The returned objects have a method interact() to be Trang 1/5 called by the framework consequently. As a result of calling this method creatures may be added or removed from the simulation. Additionally the internal states of interaction creatures may change, but the framework does not care about this. Note that calling e.g. cchh_interaction may create an object from class fight or breed. Show the design that is sketched above. Task 4. Explain what would you have to do in order to add a third ecosystem, e.g. High Mountains (eagle, alpine ibex, rhododendron). How about the changes required when adding a fourth type of creatures in all simulations, the fungus (mushrooms)? Exercise 2 Task 1 Give descriptions of specialization interfaces of the EcosystemSimulation framework, that is, write sufficient ‘manual’ for the specialization author describing what is required from the classes that any specialization must contain, guidance on how to make a working simulation using the framework. There are three obvious specialization interfaces: one for creating creatures, other for handling interactions, third for moving animals. Task 2 a) The current design is far from being flawless, e.g. the way how creating new creatures or removing them as a result of an interaction is handled is a clumsy design. What are the problems in the design? What other ways could be applied to handle this? b) Explain how the design of handling movement of creatures is in fact an application of Template Method pattern. c) Can you spot Strategy pattern somewhere in the design? Task 3 Give a default implementation for interaction type ‘Chase’ that can be either used directly in a specialization, or redefined only in a way that the redefined implementation contains the phases of ‘sneaking closer’, ‘chasing’, ‘killing’ and finally ‘eating’ in that order. Task 4 We want to be able to support herds of creatures as well. The interesting property of a herd we want to model is the social structures between members of the herd. The relationships between herd members that make up the social structure are herd leaderrival, parent-child, male-female (‘married’), and a general alliance between any number of individuals. Since how creatures are stored is a responsibility of the framework, the specialization author will not know (and does not want to know) how these relationships are represented either (a table stating all relationships, direct references between creatures, …?). The specialization author wants to be able to specify the structure of a herd ‘logically’ and let the framework create the creatures and the social structure, or to change the herd structure in interactions between creatures. One of the intents of the Builder pattern is to separate the construction of a complex object from its representation. This might give you some inspiration in your design. To keep things simpler, you do not have to mix the solution too much with the workings of the EcosystemSimulation framework. Trang 2/5 Exercise 3 Task 1 Show how Observer pattern can be used to implement behavior where one or more creatures can e.g. act as guards giving an alarm to all members of a herd when it sees a danger. You do not have to link this design to the framework, nor assume any implementation of a herd. How would you support many different types of ‘messages’ form the guard creature to the members of the herd? Task 2 How would you add the design in previous task into the simulation framework? Issues to consider: - what part of Observer is included in the framework? - how to offer “observer functionality” to specializers? - how to register the observing creatures to event producers (who registers them, when)? - should the “observer functionality” be implemented at the level of individual creatures or as a part of a ‘Herd’ abstraction that was sketched in exercise 2. Adding Observer support is not a straightforward task and there is no single good way of doing it. Task 3 Suppose you have implemented a class for sophisticated simulation of two breeding ammals. The class ‘MammalBreed’ implements the interface ‘Interaction’ from the previous design. However using method ‘int getNewCreatures()’, where the returned value is the number of new creatures that the framework should create, is too restrictive. A new version of interface ‘Interaction’ is thus created with the following change: the method ‘int getNewCreatures()’ is replaced by ‘CreatureInfo getNewCreatureInfo()’ that the framework calls after calling ’interact()’, as before. The return type CreatureInfo is a class containing needed initialization information and the number of new creatures. Its internal design is not relevant in this exercise. Unfortunately ‘MammalBreed’ class is already used elsewhere and you can not change it to make it implement the new ‘Interaction’ interface. Show how you can still use ‘MammalBreed’ with the new ‘Interaction’ version. Task 4 The creatures need to be able to observe and affect their immediate surroundings, thus we need methods like lookAround(), smell(), makeWarningNoise(), searchFood(), …, i.e. many different types of behaviors for different animals to interact with the surroundings. We do not want to put all these methods in the ‘Creature’ class, nor in the ‘Herbivore’, ‘Carnivore’ and ‘Plant’ classes either. This would fix the set of behaviors that all animals can have and pollute the class hierarchy with methods that all concrete classes do not need. Use Visitor pattern as an inspiration to a design where new methods for interacting with the surroundings is easy to add. What are the tradeoffs of this design (what gets very laborious to change?). Again, to keep things simpler, you do not have to add this design to the framework. Exercise 4 This exercise may be somewhat laborious, but if you work on it a few hours, it should teach you a lot. Designing applications is often hard. Designing application frameworks is much harder. Most of the time, a framework is be designed correctly in the first attempt. This appears to be the Trang 3/5 case with our EcosystemSimulator also – adding behavior to the framework turned out to be very difficult. Some of the problems we encountered were: - Since the framework had full control of adding and removing creatures, the interface provided for specialized creature behavior to create or remove creatures as a result of interactions was very restrictive. A concrete example of this was the ‘SofisticatedMammalBreed’ class that required the addition of a new interface in the framework to give more control on creating offspring for the specializing code. - It is very difficult to add any kind of support for creatures that is not implemented in Creature-class hierarchy. An example of this was the difficulty of adding observersubject behavior that could have been used in a particular specialization if it was required. - Creature-specific behavior is not supported well. The framework knows when and how to call Move() and Interact() of creatures, but adding any other concrete animal specific behavior is not supported. An example of this was the need to add anilamspecific ways of interacting with their surroundings (like lookAround(), searchFood()…). We tried Visitor-pattern as a way of overcome this, with poor success. The problem was solved only by compromising LSP. Again a clear sign that the design of the framework is more a hindrance than help to specializers Taken together the framework as it is now provides the following features for the application writers (specializers): - The world, a place where creatures can live, move and interact - Creatures are created automatically based on specializers ‘configuration’ of the simulation (how many of each animal type). - Creatures are moved around as simulated time elapses. The specializer can define each creatures way of moving. - The framework takes care of detecting when two creatures should interact, and initiates the interaction. The restrictions imposed by the framework are: - All creatures must be either carnivores, herbivores of plants - Creatures can not be created or removed in specialization code. - It is possible to have only one concrete animal of each type - The model of movement is simple and fixed in, each creatures move() method is called regularly. - Interaction can only take place when the animals are close to each others. Other triggers for interaction between creatures can not be implemented. - Only place where animal-specific behavior can be implemented is move() and various implementations for interact(). This is not sufficient. - The creatures can not adjust their behavior based on the environment, e.g. weather, time of the year, etc. since there is no way of accessing these world properties. Task 1 Make a new design of the framework to alleviate the restrictions above. You should completely redesign the framework. As a hint: it is probably wise to make creating new creatures a responsibility of the specialization. To make the design - analyze and decide what common behavior is sensible to provide for all specializations from this framework (these are commonalities) - identify the ‘points of variability’, i.e. what properties or behavior is different in different specializations (these are variabilities). - design how to implement the commonalities (one at a time) and the corresponding variabilites. Trang 4/5 • This produces specialization interfaces, commonalities should go to framework, variabilities are left to specialization. • Patterns should be useful here. As an example, I find a commonality that the creatures should move around. I have analyzed the needs of different simulations and found out that there are two variabilities here: both the way of moving and decision on when to move should be left to specialization writer. However, most of the simulations will have a regular movement of all creatures, as we had in the previous version of the framework. This gives me enough information to make the design, yielding a layered specialization interface for handling this commonality-variability. The move() method is overridden by concrete creatures as before. It is called by the framework regularly for most of the simulations. However this property is provided in a more specific layer of the framework, an it can be bypassed if some other implementation of movement logic is needed. Making the design for this is left to you. Task 2 Write a brief document describing the thinking behind your design. Describe especially the specialization interfaces in your design. I.e. what is the commonality, what is the variability, how the specialization is meant to be implemented. Identify patterns if you were designing based on them. Task 3 (optional). Would it now be easier to provide support for modeling herds in the framework? If the creatures are created in specialization code, how would you provide e.g. guard-warning behavior so that it would be easy to use in a simulation if it was needed? Trang 5/5 . #1: Creational Patterns You are designing an ecosystem simulator that enables to set up different environments (ecosystems) containing animals and plants. abstract types, Carnivore, Herbivore or Plant. You need to run simulations on two ecosystems, African jungle with creature-set e.g.(lion, antelope, grass) and

Ngày đăng: 20/06/2013, 20:04

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan