BenjaminTaylor Previous Design Work

Latest revision as of 03:05, 25 November 2010

Design (1)

Figure 1 : Commander Project Class Diagram

Figure 2: Implant Project Class Diagram

Description

The application can be divided up into a number of separate projects. The Commander project in Figure 1 manages connections with Implants and provides an interface for services (for instance a KeyLogger) running on the Implants. The Implant project in Figure 2 contains the logic for each service and also manages its connection back to the Commander. There is also a project named CommanderConsole and another named CommanderGUI which handle the console and GUI elements of the Commander interface. I have chosen not to show these projects in diagrams in this iteration. The following sections outline the design decisions made for each project.

Commander

A Proxy pattern provides an interface to services such as KeyLogger and ScreenGrabber. This simplifies GUI and Console interface code by providing interfaces to services that are likely to exist on another machine. It also will hide the way the Commander and Implant communicate by wrapping this up in an interface.

An Observer pattern was used to avoid the Connection having knowledge of the services utilising it. Such knowledge would make the design hard to change if extra services were to be added. During development Doug and I considered the data arriving from the Implant to be analogous to baggages on the conveyer belt at the airport. Utilising this pattern allows the connection to act as the 'belt' and the services as the passengers that collect their luggage. In this way the Connection also avoids having to even understand the data that is being recieved. This is in line with the Single responsibility principle.

In practice a Commander is expected to have a large number of connections. Each connection will have a unique IP address and port number. The Flyweight pattern is used to maintain all the current connections. This encapsulates the task of managing connections and ensures only one instance of a specific connection exists at a given time.

Implant

The Implant also utilises the Observer pattern described above which provides many of the same benefits.

Critique

The primary issue with this design is that it is incomplete. Many of the services are not yet implemented. It also does not yet address how the services are to use the connection to send data. This would seem to require the connection to be associated with the service. It is likely this is how I will approach the problem but I have yet to make a decision on this. Some of the requirements are not met in this design. For example, there is no way to analyse data that is recieved - or even process the data in the first place! These issues will be amended in later iterations of the design.

There is also no obvious means of knitting together the services to their connection. At the present moment I am assuming that the GUI or Console interfaces will be responsible for this task but would break the Presentation separation idiom. I would like to explore other possibilities such as using an Abstract Factory which could create the services and register them as observers at the same time.

I am not sure whether Flyweight is an appropriate choice of pattern in the project. It appears to be a tidy way to maintain the list of connections but I need to do further reading on the pattern to make sure it is what I want.

Summary and Learning

I have made a start on the design of the system and need to elaborate further. I also need to clarify my understanding of Flyweight to ensure it is being used appropriately in my project.

Design (2)