Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chapter Five: Bend, or Break

  • Briefly state the Law of Demeter. How does adherance to this "law" ensure that a software system is minimally coupled? Why is coupling a "bad thing" for software systems?

The Law of Demeter says that methods should only call other methods in the same class (including itself), methods belonging to a parameter, methods of an object created by the method itself, or methods of any directly held component objects. This ensures that a system is minimaly coupled (meaning methods depends on a minimal amount of other classes) by reducing the possibilities of interacting with more classes than needed. We don't want interaction with unecessary clases. Some reasons why coupling is 'bad' for software systems are that coupling can increase risk that changes in other parts of the system can negatively affect code. Coulping can lead to unstable and/or hard to maintian systems.

Richard Geary

The Law of Demeter states that an object's methods can only call methods in the same class, the methods of an input parameter, the methods of an object created by the current object, or any methods of directly held objects. By conforming to this "law", a software system can ensure that change is not far-reaching; that is, change remains relatively local to a class, and therefore the system remains minimally coupled. Coupling is considered to be bad for software systems because a change in one area of the system might break an entirely different part of the system – this makes it tough to track down problems that arise because the code that seems to be failing might not be failing at all. bps

  • What is a response set for a method? What are the strengths and weaknesses of writing methods that have small response sets?


A response set of a class is the total number of methods that are called from within the class's own methods. Strenghts of writing methods with small response sets is that systems tend to have fewer errors and code will be more mainainable. Weaknesses are that when following the Law of Demeter, and hence wiritng code that produces smaller response sets, a programmer may have to writre several wrapper methods or other extra code that which can cause extra runtime and space costs.

Richard Geary

A class's response set is the list of functions that are called directly from methods inside that class. The benefit of writing code with smaller response sets is that when something goes awry, it is much easier to find the problem in a smaller response set. However, writing code that focuses on having a small response set may appear to restrict functionality or incur more overhead in the form of wrappers and the like. bps

  • What is the hungry consumer model? How does this approach enable you to easily achieve load balancing? What technologies could be used to build a system that adheres to this model?


The hungry consumer model allows for 'temporal decoupling' of software system components. By seperating components into independent concurrent entities, and creating a work queue, we can achieve load-balancing. Each component takes work from the queue when it is ready, processes the work, and returns to the wueue for more It does not matter if a component gets tied up with a certain job, the other components will take work from the queue when they are ready, so that the job will alwasy go to the component that is 'most-ready' (Is this really load-balancing, or is it more load-sharing?) This model could easily be implemented usuing Jini, a framework for distributed computing in Java, and JavaSpaces, which could be used as the work queues. See Kapfhammer's Joshua.

Richard Geary

Just as a note: Joshua is one example of a system that adheres to the hungry consumer model. Joshua distributes the execution of test cases that adhere to the JUnit testing framework. In general, I like to use the term "master/worker paradigm" instead of "hungry consumer." Greg

The hungry consumer model consists of a queue of work needed to be done, and any number of consumers available to do the work. The consumers each take a task from the queue and work on these tasks concurrently. The time each task takes may vary, but this fact does not affect the hungry consumer model since the consumers work concurrently. Load balancing is therefore easy (assuming that the tasks are of relatively similar complexities, i.e. there is not one task that takes 20 minutes of computation while the other 99 tasks take only 3 seconds): the consumers need to be allocated wherever the most resources are, and load-balancing comes for free. This can be achieved through thread programming, where each consumer spawns a new thread and the queue is controlled by some kind of semaphore, or on a larger scale by using a distributed computing framework such as Jini. bps

Beyond just using Jini, it would also be useful to use the JavaSpaces Object repository. But, your approach with the queue could also work. Using JavaSpaces essentially elimiates the need for a semaphore solution because you get this "for free" when you use Jini and JavaSpaces. Greg

  • What is a blackboard software architecture? Why does the blackboard architecture lead to a software system that is able to "bend, not break"?

A blackboard software architecture is a model in which there is a central 'place' in the system that is shared with other parts of the system. Any type of object/code/data can be stored in this blackboard area. Many different parts of the system may access the blackboard, and the various parts of the system do no have to know about each other, only how to interact with the 'blackboard area'. Rather than system components interacting with other system components, which may force the need for many interfaces among the various components, the blackboard architecture makes it easier, allowing for there to be just one interface to the blackboard. The components simply interact with the blackboard to 'communicate' with each other. This makes the system easier to maintain, less confusing, and less brittle than other alternatives.


Richard Geary

A blackboard software architecture is one where each part of the system revolves around a "blackboard" where all of the pertinent information about the system is kept. The blackboard architecture allows each component to add or remove information to/from the shared blackboard. The components then only need to communicate with the blackboard, and do not communicate with each other, allowing the system to "bend". Each component is then only responsible for itself: changes in a single component remain local. bps

For both of you: from your description of the blackboard it seems like a solution to many of the problems associated with software. If a blackboard architecture will enable software to "bend and not break" why don't we use it more often. Are there situations in which the blackboard architecture are not particularly useful? Greg

Link to this Page

  • Software Design last edited on 14 October 2004 at 2:29 pm by aldenv28.allegheny.edu