PeakFromBasics/LessonOne

UserPreferences

Lesson One: Component Based Design

Contents

1. Lesson One: Component Based Design
1. Component Based Design
2. What does it look like?
3. Protocols

Component Based Design

The first thing we need to do when designing an application using PEAK is to think in terms of components. Applications in PEAK are essentially sets of components, linked together by the framework. So let's look at what components make up our sample application.

We are monitoring a number of systems. So the first thing we need is something that lists out the systems we want to monitor. We'll call this component the "Repository". It could be a simple list of systems, or a database containing all of the details of our complete corporate infrastructure. At this point we don't care. From our perspective, the repository is just a "thing" that we can ask for a list of the systems we want to monitor.

OK. So far, so good. Let's see what other components we might need. Well, we'll need something to actually do the checks. Again, we don't really care about the details at the moment. Call this a "tester", and assume we can give it the details of a system and get it to do the necessary test.

And we wanted a report at the end, didn't we? Right, that's a "reporter" component, which takes the results of the tests and produces our report. Again, we don't worry about the details. The report could be a simple printed listing, an e-mail alert of systems which aren't responding, or anything. What the reporter does is something we can think about later.

And finally, we need a "controller", to tie these bits together. It takes the system data from the repository, sets a series of testers running, and passes the results to the reporter at the end. The controller could just run everything in sequence, but I'm looking ahead here and assuming that we will need to scale things up later, and may want the controller to run testers in parallel, using threads, or as separate subprocesses, or whatever. Again, the key here is to defer that decision. All we care about for now is that the controller component encapsulates that detail, for us to consider later.

What does it look like?

The descriptions above were a little wordy. A diagram would probably clarify things here. Ideally, this diagram would be in something like UML, capturing the system design. However, as I don't know UML, we'll stick with a simple picture.

Protocols

This is all very well, but what does it gain us? As we've said, by thinking in terms of components, we can defer worrying about implementation details for now. But we need to capture this high-level picture in code. This is where protocols come into the picture. We can define the interfaces for our components in terms of protocols, and then write our application in terms of those protocols. That gives us an executable form of the "big picture" above.

So, we start by defining some protocols. For now, these will be a "first cut", as our design is still pretty vague. But let's see how far we can get.

    1 from protocols import Interface
    2 
    3 # Our repository component
    4 class IRepository(Interface):
    5     """A repository of systems to monitor"""
    6 
    7     def get_systems():
    8         """Return a list of all the systems we want to monitor"""
    9 
   10 # Our tester component
   11 class ITester(Interface):
   12     """An object that runs a single test on a single system"""
   13 
   14     def test(system):
   15         """Test that the given system is alive"""
   16 
   17 # Our reporter component
   18 class IReporter(Interface):
   19     """An object to produce a report of test results"""
   20 
   21     def add_result(system, result):
   22         """Add a single test result to the report"""
   23 
   24     def generate_report():
   25         """Generate the final report"""
   26 
   27 # Our application controller
   28 class IController(Interface):
   29     """The controlling application logic"""
   30 
   31     def run():
   32         """Run the application"""

That was easy enough. It really just gives names to the things we are expecting to do. Our next step will be to start putting all of this into action, with working code. We'll look at that in the next lesson.