dtu-imm / tnm consult exams project 2008etd.dtu.dk/thesis/259767/dip08_59.pdf · ·...

Exams project 2008

Farmguard Clienta rich client application.

By Christian James Tengberg Hansens032699

______________________________________Date Signature

of 81

DTU-IMM / TNM Consult

PrefaceName, Christian Hansen – IT diploma engineering student at DTU (Danish Technical University). This is my final exam project before finishing my engineering studies. Through out my studies at DTU I have covered a lot of ground in the field of computer science with great interest, some more then others of course but nevertheless, very interesting in general. The huge variety in computer subjects has one drawback though, choosing one for the final project is not an easy one because there are so many subjects and they all have their own fascinating thing going for them. One thing though, that has always drawn my attention with is the visual appearance on the screen, whether it is pure display or an interactive visual. So this type of application has always been a strong candidate for my specialization / final project. Another strong interest of mine came later on and a bit by surprise. During the various courses, we learned to program a little bit of this and a little bit of that. Most of these tasks had one thing in common. They were small scale. When doing larger (in respect that a course lasts 13 weeks) course projects, it annoyed me that I could never really find a satisfying way to structure my projects, when I had to put all the different bits together. The code was often written so tight that even the smallest of changes required a lot of rework. Frequently used objects would entangle the whole application in references, making it very confusing. This frustrated me a lot and lead my attention to design patterns. Though design patterns were introduced during an OOP1 course they were generally not given that much attention. While searching for a book on the pattern subject, one phrase came up again and again, “A MUST HAVE! for every application developer”. Especially one book named Design Patterns (also known as 'gang of four' 2), is described as the bible within object oriented programming. Digging into the subject, I realized that I had found what I had been looking for all along. A proper way of structuring code. Of course my application code/structure did not suddenly change from bad to world class. But slowly, step by step I got more structure into the applications and made them less tight. In this way I become very interested in how to structure OOP.

1 OOP referees to the concept of Object Oriented Programming.2 Gang of four because it was written by four people, Erich Gamma, Richard Helm, Ralph Johnson and

John Vlissides. Also often refereed to as GoF

of 81


Index1 Introduction.........................................................................................................................5

1.1 TNM Consult................................................................................................................51.1.1 The Agricultural Sector.........................................................................................51.1.2 Farmguard............................................................................................................6

1.2 Problem Statement......................................................................................................71.2.1 Problem................................................................................................................71.2.2 Audience ..............................................................................................................91.2.3 System Requirement Specifications..................................................................10

1.2.3.1 External interfaces......................................................................................101.2.3.2 Hardware/Software.....................................................................................101.2.3.3 Human.........................................................................................................101.2.3.4 Functionality................................................................................................101.2.3.5 Performance................................................................................................111.2.3.6 Portability ....................................................................................................12

1.2.4 Constraints.........................................................................................................121.2.4.1 Interfaces.....................................................................................................121.2.4.2 Visual appearance......................................................................................121.2.4.3 Data storage................................................................................................13

1.3 Project management..................................................................................................131.3.1 Unified Process..................................................................................................131.3.2 Subversion..........................................................................................................13

1.4 Chapter guide............................................................................................................142 Analysis.............................................................................................................................15

2.1 Risk............................................................................................................................152.2 Technology................................................................................................................16

2.2.1 .NET....................................................................................................................162.2.2 QT & GTK...........................................................................................................162.2.3 WPF....................................................................................................................172.2.4 WinForms...........................................................................................................18

2.3 Mobility and Porting ..................................................................................................182.4 Audience....................................................................................................................19

2.4.1 Actors.................................................................................................................192.4.2 Ethnographic Interview.......................................................................................20

2.5 Actors and use cases................................................................................................202.6 Application architecture.............................................................................................23

2.6.1 Enterprise Application........................................................................................232.6.2 Application layers...............................................................................................23

2.7 Design patterns..........................................................................................................242.8 GUI Model..................................................................................................................24

2.8.1 Model View Controller........................................................................................262.8.2 Application Model...............................................................................................282.8.3 Model View Presenter........................................................................................282.8.4 Supervising Controller & Passive view...............................................................302.8.5 Conclusion..........................................................................................................30

of 81


2.9 Summery....................................................................................................................303 Case study and test of Farmguard Client.........................................................................31

3.1 Technology Choice....................................................................................................313.2 Design .......................................................................................................................31

3.2.1 Domain model....................................................................................................323.2.1.1 Domain data................................................................................................323.2.1.2 Dynamic data..............................................................................................343.2.1.3 Cache..........................................................................................................353.2.1.4 Domain structure.........................................................................................36

3.2.2 Presentation layer..............................................................................................393.2.2.1 UI Communication.......................................................................................393.2.2.2 Widgets.......................................................................................................403.2.2.3 Presentation diagrams................................................................................45

3.3 Use case test.............................................................................................................473.4 User test.....................................................................................................................493.5 Summery....................................................................................................................50

4 Conclusion........................................................................................................................504.1 Personal thoughts......................................................................................................504.2 Farmguard.................................................................................................................514.3 Future perspectives ..................................................................................................52

5 Appendix ..........................................................................................................................545.1 Glossary.....................................................................................................................545.2 Use case diagrams....................................................................................................565.3 Use cases..................................................................................................................575.4 Use case tests...........................................................................................................725.5 Farmguard screen shots............................................................................................77

of 81


1 Introduction

1 IntroductionThe purpose of this chapter is to introduce the company that proposed this project, the projects actual problem and the desired solution. Furthermore it will explain a little bit about the projects market segment (the agricultural segment) and what project methods and tools I have used to manage the project.

1.1 TNM ConsultThis project is done in collaboration with TNM Consult, which is a software engineering company which develops software solutions, primarily to the agricultural sector. TNM Consult originates from it's sister company TNM IT who sell and maintain IT installations on site in the agricultural sector. While TNM IT was up and running, the next step was to develop their own software which lead to the existence of TNM Consult. TNM Consult has over the last 4 years developed different applications dealing with data collection, support systems , statistic optimization and more. As mentioned their target audience is primarily the agricultural sector but applications for other business have also been made. Their current projects range from small to medium size, with one to four people assigned to them. The company has working relationships with other companies in the agricultural sector and universities (like this project for instance). Other than software expertize, TNM Consult has an in depth scientific knowledge about the agricultural sector, especially pig breeding, which combined with software can give the farmer the upper hand and squeeze that extra profit out of his production. This is of course why TNM Consult focuses on the agricultural sector. To date TNM Consult consists of four developers but is growing in size with increasing rate.

1.1.1 The Agricultural SectorWhen asked about the agricultural business people typically picture a little farm with a

pig pen, a stable and x hectare cultivated land. This was not far from the truth 20 years ago but nowadays the little farmers are slowly disappearing and replaced by so called 'mega farms' or at least larger installations capable of containing enormous amounts of cattle. Also there is an increasing tendency for farmers to run businesses in foreign countries, leading to agricultural enterprises that stretch world wide. As we go on it becomes clear that todays agriculture business looks more like a modern factory production line, where production is automated and moved to the eastern countries like China. Though China probably isn't the first choice for agricultural business the resemblance is clear, however there is a fundamental difference in the industrial and agricultural sector. The industrial sector has constantly been updated with the newest computer technology for optimizing production. The working man in the production hall has nowadays, more or less, been replaced by machines controlled by computers, while humans monitor the production status from a control room. In the agricultural sector it is a different picture, were the presence of computer technology is little to nothing and when computer technology appears, it typically dates back to the 80's. On top of that add the general growth of computer technology and you have a rather big technology gap to fill.

of 81


1 Introduction

It is this gap TNM Consult is trying to fill with software applications that help to optimize and cut production costs. This can be all sorts of applications like data collection of pigs, remote accessing electronic components, managing time schedules etc. Some of the problems that TNM Consult has identified, is the troublesome task of accessing devices installed in, for instance the stable. Often the farmer needs external support to get his head around this process which is another bill to pay. But what is worse is what the farmer can not see which is how vulnerable his equipment is for intruders. There are many many other areas were IT technology can provide assistance for the farmer and these examples are just a few of them. This makes the agricultural sector very exciting for software engineers because there so many holes to fill and this can have a big impact on the way a farmer runs his business.

1.1.2 FarmguardOne of TNM Consults latest software projects, called Farmguard, is an application that

provides access and security to electronic components in a agricultural installment. Farmguards background was as above mentioned, the lack of security and accessibility. Security because components typically relied on sparse protection often in form of a discount router from the local super market. Having a million kroner business relying on such security measures was clearly unsatisfactory. The accessibility problem came in form of establishing connections to components, especially behind routers. Often the farmer had to access components by their IP addresses, which are unnatural identifiers for humans to remember and easy to forget. Worse was when it came to accessing components from outside the local network. Setting up correct port forwarding can be an annoying or impossible task for the average computer user and outside support is often needed to perform this task, which makes remote access possible. But by port forwarding the security got yet another knock on the head since the farm now had a partially open firewall. Clearly a system was needed to handle these problems and thus Farmguard was born.

The general idea with Farmguard is to have centralized server that manages access to components installed on various agricultural enterprises, whether it is from a local or remote location. When connecting to a component through Farmguard there are essential four obstacles that it handles for the user.

● First of all, a user has one account in the system which means one user, one password regardless of how many components are installed. ● Second, security – Farmguard acts as a gateway, meaning access to components from a remote location is only possible through this gateway which again provides security with it's various security mechanisms. ● Third, accessibility - easy access to components through a graphical interface. Farmguard contains all the necessary information such as IP addresses, ports, gateway etc for all components, so it is capable of establishing a connection from the user to the component. This relieves the farmer from the administrative work of keeping track of what is connected to the network and the necessary attributes (such as IP address and port number) needed to establish a connection. The different services provided by the components does not always just relay on the connectivity between the two endpoints but require log on procedures or other parameters. Bottom line is that there can be a lot of information about how to

of 81


1 Introduction

connect and log on to these components and this burden is now overtaken by Farmguard.● Last is the ability to administrate access rights to users of an enterprise. While it is convenient for the farmer himself to access his installations, it is just often the case, that his staff or support service needs access as well. Because of this, Farmguard provides a user and group bases access system that dynamically can add and remove users to groups or grant them special roles in the system. This way the farmer can fine grain access from hole groups to a specific user.

In addition to the above mentioned, Farmguard can play a useful role for others then just the farmer and his staff. The components installed on a farm are typically hardware components like, milking robots, content indicators mounted on silos, temperatures sensors etc which provide some kind of Ethernet interface to control it. These devices are provided by different manufactures which need remote access in order to provide on-line support. If the manufacture registers with Farmguard, the individual farmers can quickly grant manufactures access to the specific device which they provide support for.

So far we have seen how Farmguard can solve technical obstacles but there is an invisible problem that it also solves. This problem is not of technical but legal issues. An action like providing manufacture access involves legal agreements between the two partners which take time. This is due to the fact that these components sometimes are responsible for sensitive parameters that are critical for successful production. A screwup here can spell disaster and worst case cost the farmer millions of kroner. With Farmguard this agreement is accepted only once when register with Farmguard. Farmguard monitors and logs all access making it possible to trace back, who and when the connection was made.

1.2 Problem StatementThe next three subsections is a description as to why this project exists and should

answer the following three questions:1. In general, what is the problem and why is a solution is needed ?2. Who is the solution intended for and who will be using it ?3. What is required for the problem to be solved satisfactory? This explains the resolution of the solution by compiling a system requirement specification.

1.2.1 ProblemFarmguard is split into different parts. 1) There is a server part (FarmGuard Server) that

sits on top of the database so it can provide data when requested. Furthermore, it handles the main security in the system. 2) A router part (FarmGuard Security Gateway) that establishes the connections between the client and component, for instance a web cam.

For the FarmGuard Server and FarmGuard Security Gateway to have any meaning there needs to be an interface that links them to a user. This makes it possible for a user to interact with the system, requesting connections, data and such. For this, a visual

of 81


1 Introduction

interactive client is needed which makes up the 3. and last part of the Farmguard system. The type of client needed is a rich client application, which means a stand alone desktop application. This client is what this project is about.

Since the client is the last of the three parts in the Farmguard system, some work has gone ahead of the client. Many of the data object have already been defined, such as what an agriculture installation consists of. At the top you have an enterprise and underneath is a hierarchical structure that contains farms, locations and components, as pictured in Figure 2.

First of, the client needs to provide a visual overview for the user. This visual consists of several things such as:

● Entities existing within the enterprise. This can be anything from a house to a web camera.

● Log entries that trace actions. When user A connects to a remote desktop. This is recorded so it is possible to go back in time and see what events have happened.

● Access relations can administrate accessibility to entities. So who has access to what and who belongs to which group.

Because there are different user roles in the Farmguard system that have different privileges, so the client needs to differentiate between these and provide the necessary functionalities. The functionalities are divided into three basic client modes:

● Technician mode – this mode is used to create and setup enterprises which is only necessary when the enterprise is created, when additional components are added. Or an existing component has its parameters changed.

● Administration mode – access panel should be provided for an owner, so he can control the access rights.

● User mode – Ordinary use of Farmguard. View components and access them.

Though visualizing the enterprise provides a nice over view, the users still need at way

of 81


Figure 2:Enterprise structure

Enterprise

Component

Farm

Location

Component Component

Location

Farm

Figure 1:Farmguard system

FarmGuard Client

FarmGuard Server

FarmGuard Security Gateway

1 Introduction

to establish a connection to the component which the client needs to provide. These are the reasons as to why the client is needed. People have grown accustom to

the use of rich client application and would never consider using a console application for the above mentioned problems, though it is possible. People want a nice clear graphical interface.

1.2.2 Audience The client has two groups of end consumers. The biggest of the two are the farmers.

They will be using the client on a daily basis to access different components belonging to the enterprise. You can generally divide people into three classes when it comes to using a computer and its software.

● First you have the novice users, they do not know were to start, unaware of file and folder structure. I.e. never used Windows Explorer and probably do not know how to print. These are some examples of what you can expect from a novice user to know or not know.

● Second, you have the intermediate users, this class is quite big and includes the majority of users in general. They have a good idea of a computers scope and what it can help/do for them. They know the the most important functions and thus just needs to be reminded of were or how to perform these functions when they forget. They are curious about upgrade patches, what new features do they bring to them? This is the type of behavior you can expect from an intermediate user.

● Third you have the expert users, these are the keyboard warriors. They want a hole arsenal of functionalities at their hand mapped via short cuts. They seek ways to automate functions in order to optimize their work. They want to customize setup and appearance for them specific, just like people organize their desk so it suites their style.

The thing with people though, being novice, intermediate or experts, is that they rarely stay in one group permanently. Novice users normally move on quickly as nobody likes to be incompetent. Therefore they tend to push hard to 'level up', if this fails they will rather quit then be humiliated by continuing being incompetent. In the other end for the scale the experts can equally, as fast as the novice users, drop to intermediate level if they don not follow up on updates and changes. Software and hardware evolves so quickly these days, that what was cutting edge 2 years ago is almost antique today. So if an expert user have been out of the loop for a while he will most likely find him self as intermediate user again.

The farmers, who are the primary audience in this project, generally range from novice to intermediate. However the majority are more towards the novice end of the scale. This is an important fact to be aware of then developing a client application. Special care must be taken in order not to scare them away when using the system. So design wise the keyword has to be 'keep it simple'.

The second group of people to use the Farmguard client are the support guys. They are the ones that will be setting up farm enterprises, configuring the components and ensuring that the client gets the correct information in order to establish connections. These people are most towards the expert category. As long as the client application follows the basic window layout, these people together with a short introduction to the

of 81


1 Introduction

system, should not have any problems figuring out the functionalities them selves.

1.2.3 System Requirement Specifications

1.2.3.1 Hardware/SoftwareThe Farmguard Client requires two interfaces to hardware/software components. One

to a server (Farmguard Server) and one to a router (Farmguard Security Gateway). Interfaces to these two components are provided in form of dll files and contain method calls to their respective component i.e. server or router. The server interface proves authentication and authorization to the system as well as indirect database access. The router interface provides communication to installed components such as cameras, remote desktop etc.

1.2.3.2 HumansThe human interface to the system is done traditionally through the user interface and

uses mouse, touch pad and keyboard as input devices. Human interaction is divided into different roles in order to differentiate authority among different roles. The role system is dynamic so the access levels depth can variate depending on the system setup.

1.2.3.3 FunctionalityThe Farmguard client has a core set of functionalities that are required for the

application to function. These functions are divided into three categories. Security, Administration and Enterprise accessibility. Below is a list of all the functionalities together with a paragraph number. The purpose of the paragraph numbers is to have a clear reference to the specifications throughout the project. This also prevents the specifications from drafting into new specifications as the project progresses.

§100. Security§101. User must be able to log in using his user name, pin code and one time

password.§102. Access restrictions. Differential between users. Hide controls which users does

not have access to so they do not get confused with controls that they can not use anyway.

§103. Access control panel that deals with access relations must be watched carefully to avoid any relations not being removed or worse, added by accident.

§104. Administration§105. Creation of user groups. When an owner logs into his/her enterprise, provide a

mechanism to create a user group that is unique to his/hers enterprise. These groups are used to classify different access groups.

§106. Remove/delete a user group. A group can only been removed if no relations point to that group.

§107. Access administration. Provide a panel to set access relations between users

of 81


1 Introduction

and groups. Users are not added/created in the client but pulled from the server. Users can belong to none or several groups.

§108. Access administration. Provide a panel to set access relations between entities and groups. These relations are bound by the rule of a hierarchical structure meaning that in order for an entity to have a access relation, its parents need to have as well all the way to the root of the structure. For the Farmguard client the root element is a farm.

§109. Provide a list of external users for the owner to pick and add them to their enterprise (and of course remove it again). External users exists in the system for support purpose and can easy be granted access to entities in the system.

§110. Access administration. Provide a panel to set access relations between entities and provider. External users exists in the system and are pulled from the server. An owner can then grant external users access to his different entities for support issues.

§111. Enterprise accessibility§112. Activity log. A list view to browse log events. These events include connections

made to components and display data such as user name, time, accessed component etc.

§113. Print support. Print activity log in a custom template to add logo, page number, header etc.

§114. Graphical display of an enterprise. This takes form as a map were a hierarchical structure of farms, locations, component and connections are displayed as containers each containing children, all the way down to the connections. This map must be interactive, providing navigation and accessibility to the entities3

§115. A tree view control that what provides an alternative structure of displaying and organizing entities. This control must also provide an a way to execute their connection.

§116. Custom component list. A control were components can be stored as a form of bookmark. This way a user can gain access to frequently used components without having to browse through different entities.

1.2.3.4 PerformanceThere are no CPU heavy calculations involved in the Farmguard client other than what

is required for the window framework it self. Nor are there any time critical operations that can result in dangerous situations. Since the client relies on network communication user experience might be affected by quality of the network connection but this is not part of the clients responsibility.

However the client appearance is highly customized which potentially would require heavy CPU/GPU usage. Client wise the content must appear smooth on the screen, which could be a problem with for an example, heavy use of drop shadows. Time consuming tasks such as loading or retrieving content via network should not block the interface but make the sure to somehow notify the user that the client has acknowledged

3 Entities refer to a unit whether it is a connection, component, location or farm.

of 81


1 Introduction

the users request and working on it.Performance wise there are two things to remember in regard to this application. One,

graphical eye candy must not compromise the user experience by being slow. Two, every action should have a immediate response. If the task requires a little time to finish, give the user an acknowledgment of his request and notify him/her when done.

Hardware wise this should all be possible to run on what is considered an average standard desktop PC, dated three years back in time, I.e 2005.

1.2.3.5 Portability The initial client is targeted as a rich client application. However, future improvements

have been considered and porting the client is one of them. So while developing the client, solutions that make porting easier should be preferred as long as it does not add complications to the main client application. Porting platforms that have been up for discussion are web based application so you can access your system from basic any computer in the world. Another platform is hand held mobile devices. These devices would be ideal for people on the move most of the time.

1.2.4 Constraints

1.2.4.1 InterfacesThe interfaces to the server and router are already implemented and thus unlikely to

change. The server interface in particular, because it provides all the data objects which are sealed. This constrains the client with it's data types. However, if the the data types does not work for the client it can reinvent the same basic data types with the addition of the it's desired properties. So it is not a constraint which I can not work around but it would of course be preferred to use the existing.

All communication from the client to the components have to go through the router interface. The Farmguard client can not bypass this constrain by making its own connection. This is not possible because the router software does not allow any other way to the components other then through the interface. Though this is a constraint for the client it only makes it's life easier since it does not need to handle the connections. This is done by the interface which only needs some Id's from the client to identify what to connect to, then it handles the rest.

1.2.4.2 Visual appearanceThe client has been sketched by a design artist and used for promotion which means

that the client has a visual constraint that it needs to follow. The sketches are of course not final but the theme should be followed. Because the sketches are made in Adobe Photoshop some effects might not make it into the client but that all depends on the capability of the technology and framework used for the client. Also performance could have a say in this matter. Requested effects might be possible but with too big a performance cost.

of 81


1 Introduction

1.2.4.3 Data storageThe client is not allowed to store any data locally on a machine that contains

information about an enterprises content. First of this is done for security reasons but also to prevent having inconsistent data located two different places. The exception to this rule is having graphical data cached locally. This minimizes the pressure on the servers connections and helps people calling via poor connections by reducing amount of data to be fetched.

So bottom line is that the client is an empty shell that needs to fetch content from the server every time it is started. Graphical objects can be cached for improving the performance.

1.3 Project management

1.3.1 Unified ProcessThe development model used for this project is Unified Process. A short description of

this model and how it is use in this project goes as follow. Unified uses 'use cases' to identity functional specification which again is use to drive the project forward. The process divides the available time in to several time slots, that the developer iterate through. The end of each time slot is considered a mini milestone where you elaborate on the work done so far. Any new risks, errors since last mini milestone are dealt with and new functionalities (or use cases) are added to the work list. High priority tasks are of course dealt with first and the rest follow slowly as the iterations passes by.

For this kind of process to work you can not rely on finishing one phase of the project after the other as known in the waterfall model where you for instance complete the design phase before moving onto the implementation phase. In Unified Process all work phases are worked on simultaneously in parallel. Of course the relative effort and emphasis will change over the course of the project.

1.3.2 SubversionTo manage the project data, a version control application called Subversion is used.

Though this project is done by one person, work is done from several computers, including home PC, laptop, school PC and work/job PC. Migrating data from one PC to another is a annoying task and risks the danger of overwriting files by mistake. This is were subversion ensures that there is only one copy of the project that is accessible from the Internet and committing changes never endangers existing data from being lost. Secondly it provides an easy way to make backups of the project, minimizing the risk of loosing data.

of 81


1 Introduction

1.4 Chapter guideAt this point you should have got an introduction to the project and the problem it is

going to solve. This little chapter guide will give a quick introduction to what the read can expect to find in the different chapters throughout the report.

• Chapter 2 - AnalysisThe analysis will look into the different solution alternatives. It is not meant to be an in depth description of all alternatives but rather a brief description that highlights the pros and cons. Special considerations are also mentioned as it is important to be aware of these.

• Chapter 3 – Case study and test of Farmguard ClientAfter considering the different alternatives, a solution is realized in form of a case study where a concrete implementation is made. The case study will describe the solution method used and an in depth view on how it has been implemented. Note, that it does not include a code level description of the implementation. Small selected code blocks might be included, to demonstrate certain parts of the application but in general I will try to avoid using large code snippets. Instead I' will refer to the source code.To finish of the case study the application will under go some testing in order to judge the result. The first test will reflect the initial system specifications in order to verify that the client solved the problems it was intended to solve. Lastly the client undergoes a subjective test in the form of a user test.

• Chapter 4 – ConclusionA summery of project as a hole. What went wrong and right. Personal experience gained during the project and what have I learned. Finally did the Farmguard client solve the problem to satisfactory?Some final thoughts on where and what Farmguard could be in the future. What paths can and should it go ?

• AppendixIt might be a good idea to take a look at the glossary that is placed in the appendix. There are some words or terms that have a special meaning in regard to Farmguard. Knowing these terms should clarify any confusion.Other then that, the appendix contains all the documents that did not fit well into the report.

of 81


2 Analysis

2 AnalysisThis 'analysis chapter' will look at potential problems that can arise doing the project.

This way it is possible to plan ahead and have backup plans on how proceed should a problem occur. Besides the risk management, I analyze various solutions to how the project can be realized. This ranges from different technologies, application models, architecture and the target segment (user of the application). Therefore, not all of the content in this chapter will necessarily make in the final solution but are considerations that have been made upon choosing the final solution. After all, that is what application development is all about, looking at alternatives and judging the trade-offs of using one solution over the other.

2.1 RiskAs with everything there is the risk of something going wrong throughout the project.

Therefore a list is created that describes possible obstacles that could delay the project and what actions to take in such an event.

● Illness.In such a case, depending of the severity and duration, work can slow down or come to a complete stop. If the later, a time wise extension would be preferred. If that is not possible, some tasks needs taken out in order to finish the project on time.

● Project scope.Since this application is intended for the live project, it contains more content then there is time for in a project like this. Therefore the content has been limited to a more appropriate size for such a project. However there is still the risk of a wrong estimate which can end up taking too much time.The only way to tackle this is to reduce the tasks if too much work piles up.

● Technology difficulties.Some task might require more work then first estimated. There are different reasons to why this happens. It can be a bug in the framework which stops production. It can be a, technological, unrealistic system requirement that has slipped through the filter. There are three options for these types of setbacks.1) Take the time required to finish the problem. 2) Review the specification related to the problem and see if a compromise can be made by changing it a bit. 3) Skip the problem and schedule it for future work.The decision made will depend on the tasks priority. The first option would be the best, but since the project is on a schedule there is limit to how much you can stretch time, and you would like to allocate some of the time for bug fixing before release. The second option is probably the most realistic one because it is a compromise between getting work done and keeping schedule.

● Requirement changes.These are likely to happen and would most likely provide the biggest risk of them all since the likelihood of it happening is rather big. These problems will take extra time

of 81


2 Analysis

no matter what, one can only hope that these changes come as early as possible, since the time required to change them is far greater the longer into the project you get. A well structured design will also help a great deal on handling these problems because a good design decouples the majority of an applications components and there by making it easy to apply changes.

● Data storage.The project data cannot be lost. If this happens it is game over. Therefore there are several copies of the project. A server running Subversion holds the working copy of the project. The server uses raid 5 giving it a chance to recover in case of a disk failure. Although raid 5 gives one a the ability to recover there are other risks, for instance if the computer got stolen, virus destroys data, a fire burns down the computer, two disks crash simultaneously etc. If the unlikely should happen and data is lost, there is taken a backup from that computer every night to a different location that insures that the project is not lost. Finally there should always be an up to date copy on the working computer from where the last commit was made. This setup will secure the reliability needed for the project content.

2.2 Technology

2.2.1 .NETA lot of the Farmguard is already done in .NET 3.0, including the external interfaces.

This means that the client has to be based on .NET 3.0 platform as well. The end user audience use windows XP and Vista exclusively so the decision of using the .NET platform fits well with the target audience. Vista users will be able to use the client 'right of the bat' while XP users need to upgrade to version 3.0 of .NET. This however is not a problem since deployment solutions can ensure or force the required components before installing Farmguard. The .NET 3.0 also shows many new and very exciting features compare to the 2.0 version. The communication in Farmguard already make use of Windows Communication Foundation and an interesting package for the client is the Windows Presentation Foundation.

2.2.2 QT & GTKAs mentioned the client has a visual requirement that lies quite a bit from the standard

windows look and feel. What is needed is a graphical development framework known as a widget toolkit. These provide a much more free and capable components then a standard Windows application and equally important, they support hardware acceleration which for instance GDI does not. Two popular toolkits are QT by Norwegian Trolltech and GTK that is free software and part of the GNU Project. Both of these are good candidates for Farmguards UI layer. When evaluating some of their main features the conclusion is as listed.

● Cross platform – This is supported by both QT and GTK. However the end users targeted for Farmguard, are pure Windows users. While it is a nice to be platform independent it is not a requirement for Farmguard. In relation to a possible future porting, this feature is relevant but it still seems unlikely that our type of audience will shift to other platforms then Windows. So for Farmguard this is rather irrelevant.

of 81


2 Analysis

● License – Since GTK is part of GNU Project it is free to use for both (non)commercial. QT on the other hand is not free to use in a commercial product. A free product is preferred unless the product provides a substantial advantage in productivity and what sort of customization it offers.

● Language – Both QT and GTK supports the .NET platform. But differs in the languages it supports. With QT you will be force to write in C++ which is not really a problem. But with C# as the my preferred language it would be nice to have consistency in the programming language and therefore C# support is definitely a plus. And this is what GTK provides.

● Web porting – Both QT and GTK support Java but are restricted to desktop applications thus can not be run in a browser via an applet. Again this is not a requirement but a consideration of future possibilities.

2.2.3 WPFWindows Presentation Foundation is Microsoft's latest application framework. This is

not a widget toolkit like QT and GTK, it is a complete framework for developing applications but at the same time provides a mechanism similar to GUI toolkits for making the user interface. It is primarily base on the .NET Common Language Compiler which means that it inherits all the existing libraries making it possible to make use of old libraries and import them into a WPF application. But WPF is not just a wrapper for existing technology, it has a new component (called milcore) that provides a tight integration with DirectX. This means that all (that is, almost all) display is done through hardware.

The similarities between WPF and QT/GTK is that you have a very clean cut between the visual view and the logic that drives them. They all use an XML base language to define the visuals just like it's done when making web pages via HTML. These files are then plugged into the application code without any tedious merging of the two and the framework (or API if using QT or GTK) will handle the dirty work of creating all the graphical objects. WPF's equivalent to HTML is called XAML but in reality XAML is much more then just mock up language for the visual components. XAML can work with .NET object properties (dependency properties to be correct, which in short, are ordinary properties, just on steroids ) and by defining these property states via triggers (which also, is a new thing in WPF) can create a fully dynamic application without writing one line of code.

As mentioned this project requires quite a graphical makeover. This is also one of WPF's strength. Not just because it is possible but that it is relatively easy to do. The possibilities are almost endless, so developers are no longer limited to the traditionally controls but can truly let their creativity flow and come up with new, more exciting and better controls that people are more familiar with.

WPF is by definition not platform independent because it requires the .NET runtime to execute. However there is a project called MONO that is a CLR4 clone which enables one to run .NET applications on a UNIX systems which now includes WPF as well. But there is another way around with WPF. At this point one might ask why I am discussing this platform independence feature when is not a requirement. Well, because it leads us to a neutral platform that is used by every computer owner and is accessible anywhere in the

4 CLR stand for Common Language Runtime is the drive force behind all .NET applications.

of 81


2 Analysis

world, which of course is the web browser. If Farmguard is to be ported, the web browser is a prime candidate. Silverlight is Microsoft's answer to Flash and Java applets. It is a plug in for browsers to execute WPF applications within the browser. One has to remember though, that Silverlight only includes a subset of WPF so you can not take any WPF application and smack it onto Silverlight and expect it to work. But with some tweaking here and there it is possible to port the Farmguard Client to the web browser without having to create a second client application.

Besides of the graphical advantages you get with WPF there are also a range of new features, primarily from the subject of design patterns, incorporated in WPF that makes it much faster to write applications. This is because many of the regular designs are already there ready to use. These are features like improved bindings, routed events, templates, styles, element tree and the list goes on. And should one like to use components from existing technologies like WinForms, then it is possible to mitch match the two, via interop support.

Overall WPF looks like a very promising framework and has all the technical requirements needed for the project. It provides clean GUI separation, impressive visual presentation, rich feature set that opens up for new structural designs, porting via WPF /E5 and much more.

2.2.4 WinFormsWinForms has become Microsoft's legacy. It has stood the test of time so in terms of

reliability it is the obvious choice. But it quickly becomes evident that WinForms will have a hard time living up to the presentation level required for this project. If WinForms is the choice for this project then it must be assisted with a GUI kit such as QT or GTK. An alternative is using directX but that is a project in it's own and I do not have time for that. Other then the graphical limitations WinForms is suited for the job but with a little more work to do then with for instance WPF. As mentioned above WPF has many design structures built in which WinForms does not, and will have to implement them your self. Some of them might be easy enough to do while others can be a pain to realize.

2.3 Mobility and Porting We have discussed technical possibilities in regards to porting the client to other

systems or platforms. To follow up on that note, it is not entirely up to the client what technology it uses. Currently the only server interface provided is written in .NET 3.0 so the client is limited to .NET languages. But lets have a look at why I am even considering this porting when it is not on the list requirements.

Currently the application is targeted the agricultural sector. Base on our initial knowledge about these people I know that they are pure windows users and will almost certainly not change platform any time soon. With respect for these people, the little knowledge they have about computers is based on Microsoft Windows which means the .NET platform. This is the reason to why platform independence is not a requirement. However when looking into the crystal ball and think about where Farmguard stands in the future I can see it being used in other industries or sectors then the agricultural. Farmguard acts as a security barrier and it can be applied to any type of product that is

5 WPF /E the E stand for everywhere and indirectly means Silverlight.

of 81


2 Analysis

somehow connected to the Internet. These products can be anything from being stationary components installed in a house or production hall to mobile devices roaming the earth. This also means that the audience can change when applied in a different business or maybe even private consumers. Some businesses tend to use UNIX system, some Windows. Others might want to use hand held devices that again run wither Windows CE and others a UNIX based system. While this is not the current situation it is wise to at least give it some thought of where Farmguard could be in say three years time. If the ability to port the system can be ensured by just choosing the right technology, well then I think it is worth spending a moment of investigation into this matter.

For the moment it looks like that WPF /E (Silverlight) is the one that can bridge between the original .NET platform, to any other system that is capable of running a web browser. But if I have this wonderful WPF /E technology why don't I just build the initial system to run in Silverlight? Well the first version of Silverlight was terrible and had far from the needed features to realize Farmguard. Silverlight 2, which have just been released, looks a lot more promising and from a quick overview it looks like it has the necessary features required for Farmguard. But as with all technologies they need a little time to mature and basing Farmguard on a such a new platform is pushing it a little too much. And I have to remember that currently, there is no need for a multi platform client. Porting the client is plausible but earliest a year from now so by then Silverlight 2 will have had some time to mature. Silverlight 3 is already in development and has been for a little while. So it looks like Microsoft means business with their rival to Adobe Flash.

For hand held devices I will have to wait and see how much Windows Mobile includes of .NET 3.0 (WPF, WCF) or if Silverlight is able to install on their built in browser which they more or less all have today.

As for now it is satisfactory with a desktop application client base on .NET. And as a bonus I have the future possibility of porting it to the web browser with a minimal of work.

2.4 Audience

2.4.1 ActorsWhen designing the client application is it crucial to capture the minds around the

project. This includes everyone form the stakeholders to Subject Matter Experts (SME) and down to the end user. Though the core functionalities are defined, it is still unclear to how they are best solved. Different types of users usually think differently about things and their motive will most certainly vary from each other. Here is a short list of general tendencies among these groups.

• Stakeholders - are usually focused on market analysis, how wide can they hit with their product getting as many costumers as possible. They are business people that and is how they think.

• SMEs - have hand on experience and knows the daily routine. They will no doubt have many good suggestions to how a system can solve the tasks but some might be unrealistic or compromise areas such as security, data structure or end usability.

• End user – S(he) is the person that needs a problem solved. There can by other actors that can gain from the product but first of all you need to have to focus on the

of 81


2 Analysis

end users problem and solve that. End users are the ones that provide the most valuable data needed to build the application (from a design perspective of course not technical). They know exactly what the problem is and how they want it solved. But again, as with SME's these people lack the technical knowledge and do not know if some of their requests compromises other areas.

2.4.2 Ethnographic InterviewTo capture minds of the different users I will conduct a set of interviews that should

provide enough data to give a clear idea of what shape and form the client should take. The type of interview used is called ethnographic interviews. What it basically means is that instead of sending out questionnaires or calling people on the phone, you want to be in the environment where the product will be used. Here you can not only ask your questions but also observe the environment which can be just as rewarding as your questions. There are usually loads of pointers to pickup that can reveal useful data which the user did not think about. This can be things such as what other applications are running in the background and do they play a role in solving the problem, what kind of information does he need ( papers on the desk or yellow notes sticked to the screen), work flow in general, frequency of performed tasks etc. All this can be picked up while conducting the interview. When doing ethnographic interviews it is also important not to use fixed questions. Instead it is better write down topics that you want to cover. Having fixed questions risk the danger of directing the interview and miss out on valuable data. Also, one of the principles in this type of interview is that the interviewer is the 'apprentice' and the interviewee is the 'master'. Thus the interviewer knows very little on the subject and must collect data from the interviewee that is considered the expert (within their domain that is). Having fixed questions goes against the apprentice-master idea and is therefore avoided.

While giving the interviewee freedom to explain their goals and what would make their day easier, it is important that you do not make them the designer. Letting the interviewee propose concrete solutions should be avoided, but of course if s(he) is eager to present a concrete solution you can hear it out. One just have to remember that the interviewees solution might be very specific for him/her and not ideal for others.

2.5 Actors and use casesFarmguard consists of several different actors being application components and

humans. These are again divided into different actors that can perform different actions. Some are available for various actor and others for specific actors. Here is a list of the actors involved in the system.

● Owner● Staff● Farmguard server● Farmguard Security gateway● Farmguard ClientIt is important to know how the application is going to be used. Therefore use cases are

of 81


2 Analysis

created to capture different scenarios when using the application. A use case consists of a use case diagram plus a table with information such as who is involved, success criteria, main and alternative procedure etc. Because the use case diagrams provide a more coherent overview of the system when seen together, the use case diagrams are shown together instead of showing the individual use case diagram by its self.

One thing to notice in the use case tables is the reference field. These can be other use cases as well as function specifications. The purpose of this is to maintain traceability throughout the report and project. Below is an example of the use cases to demonstrate how they look. The complete collection of use cases and use case diagrams can be found in the appendix 5.2 and 5.3

of 81


DTU - IMM

Use case §201: LoginPurpose Provide a login formula for the users, enabling them to

enter the Farmguard system.

Preconditions None

Success end condition

The entered information is correct and the user is logged into the Farmguard system.

Failed end condition User is denied even if the information is correct.

Primary actor User

Secondary actor Farmguard Server

Motivation and interest

In order to use the system users need to be logged in. This login formula provides an easy way of entering the system.

Trigger The use case is triggered by the user.

Success procedureMain procedure Step Event

1 User clicks 'login'

2 The client provides a formula to fill out. This includes a user id, pin code and a one time password generated by a token.

3 The client forwards the input to the server that returns with a response.

4 The server responses with a success message.

5 User is logged in and can proceed using the system.

Extensions 3a Server does not respond with a success

4a There are many different kinds of responses other then success. The used is not logged in and notified of what went wrong, incorrect input, no connection etc. and is prompted to try again or contact support.

Priority High

Frequency High

References §101

of 81

TNM Consult

2 Analysis

2.6 Application architecture

2.6.1 Enterprise ApplicationPeople tend to think of enterprise applications as a huge programs. But enterprise

applications can also be small applications that, typically contribute to an enterprise system. According to Martin Fowler (although he does not have a precise definition), an enterprise application is an application that works with persistent data, modifies it according to input and presents it to a user. Although I would not entitle the Farmguard client as an enterprise application, but the nature of the application, it could easily make it a puzzle in an enterprise application. In fact, as the report is written, it is actually being discussed that Farmguard should be part of an enterprise system.

Whether or not, Farmguard is an enterprise application, it has many similarities such as working with persistent data. And therefore it is well worth looking at enterprise applications architecture.

2.6.2 Application layersA common way of structuring an application is the split it into

different layers. The first applications to follow this path, use a two layered cake model and were the client-server applications. The two layered model was very popular because it usually splits the application at the data storage. This way the application became more independent of the data storage, and as long as it was a relational database it could be swapped out at no cost. However this approach still has one problem. Applications usually have some sort of businesses logic and this was usually implemented in the UI layer or as stored procedures. Mixing it with the UI layer was not very flexible and lead to a lot of duplicated code. Stored procedures have limited structural mechanisms which led to awkward code. Despite its flaws, two layered application continued on as the way to go.

It was not until the arrival and rapid popularity of the web before developers realized that a separate UI layer (that contained nothing but UI logic) and domain layer was needed. With this approach they could have made new UI layer (for web browser) and be done with it. So with the three layered model, what do they represent? Starting from the bottom; a data layer, domain layer and a presentation layer (UI layer). This makes it much easier to swap out the UI layer without having to change or reimplementing your domain logic.

By now the advantages of layering the application should begin to show them self. But there are many other advantages. You gain small to full independence between the layers. Sometimes layers do not even need know of each others

of 81


Figure 4:Three layered model

Presentationlayer

Domain layer

Data layer

Figure 3:Two layered model

Application layer

Data layer

2 Analysis

existence. Only layers sitting next to each other do is some occasions need to know of its neighbors existence. Some times interfaces are put in between layers so layers need only to know about the interface and not the actual components in the layer it wants to talk with. This independence also allows developers to work independently of each other when working in different layers, provided that there is a mutually agreed interface between the two layers (should they be next to each other). Dependent on how good the layers are made developers can swap out entire layers.

With all these nice advantages it is also important to know that it comes with some disadvantages. For instance, adding new fields to the database has a cascading effect throughout all the layers all the way up to the presentation layer. Data usually needs to be represented in all the layers meaning that you have to be very careful when synchronizing the data between the layers. Layering can also have a performance hit on the application, typically when transforming data between the layers.

2.7 Design patternsA design pattern is a formal documentation on how to solve a particular type of problem

and originates from architecture. In computer science, design patterns describes a solution to commonly occurring problems when writing applications. To save others and future developers from reinventing solutions to these problems, developers have compiled a best practice solution base on years of experience. It is these solutions that are known as design patterns. While the patterns often present a concrete way of using them, one should not think of them as the perfect and the only solution. I prefer to look at design patterns as half baked cookies. They give you the general structure of how to solve the problem, but there can many reasons (programming language, limitations etc) that your problem differs a little bit from what a pattern describes. In such case you need to tweak the pattern (and do the final baking) so it fits into your application. There are two main benefits by using the design patterns which are cleaner code and reusability. The way patterns achieve reusability is by decoupling classes. This also allows one to easily extend or swap out parts of the application at a later time without tearing apart existing code. The clean code, that is a result of patterns, helps the developer keep an overview of the code and thereby productivity. Also it might not be you but another developer working on it in the future. With clean code it will be much easier to figure out how it works and since design patterns are common knowledge among developers it is much easier to pickup on existing code.

For small applications however, it might be overkill to force patterns down upon them. But for anything bigger then small applications, patterns are usually a huge benefit. Farmguard is (or will be over time) a fairly big application, of course nothing compare to programs such as Photoshop, Microsoft Office applications etc. but still, Farmguard has fair amount of complexity and can clearly make good use of design patterns.

2.8 GUI ModelA big part of the Farmguard client application is the graphical presentation (UI layer).

Designing the graphical presentation can be a quite a challenge by its self. One of the reasons for this is that most of the actions are event based, often by the user, and

of 81


2 Analysis

therefore very difficult to predict which actions will accrue and in what order. Of course you can block out / disable actions that are not possible in a current state and run validation check on user input. But even with these precautions it is still a tricky job to design a graphical interface when you have arbitrary events going off, especially when it involves communicating with other parts of the program.

Luckily there are different models that provide a helping hand when building graphical interfaces. Unfortunately, in my study of these models there appears to be a lot of confusion between these models. The reason might be (at least that is my guess) that all the different ideas are spun of the Model View Controller (MVC) model and are therefore all closely related. So close that it sometimes can be hard to tell the difference between them. MVC was the first attempt on a GUI model and dates back to the late 70's, never models have popped to the surface since and are typically a result of modern technology. Below are some of the most interesting models.

Before going on with the description of the different models it should be said that all of them have one common goal. The overall goal is to separate the presentation logic from the domain logic. The advantages of separating the application like this are many, but here are a few of them.

• Work on the presentation layer can be done independently of domain layer• Changing the presentation needs no changes in the domain layer.• The possibility of making multiple and simultaneous presentations of the same data.• And as with all other OOP designs, the presentation becomes reusable.

With that said, lets have a look on the models.

of 81


2 Analysis

•

2.8.1 Model View ControllerMVC is probably the most common. It is also the oldest model developed by Xerox

PARC back to the late 70's. As mentioned above MVC is the first design pattern for making GUIs. Many other models (most of them I have seen) are based on the MVC model. The idea of MVC is pretty simple and consists of three components as shown in Figure 5.

• The Model is the domain data that you want to display on the screen. It has no knowledge of either the view or controller. Since it is placed in the domain layer it contains normal domain logic that is is meaning full for its data, this could for instance be logic to calculate the mean and variance of its data. Though it does note know of either the view or controller it has an indirect way of communicating with these other two components. This is done via events so it can notify other objects when changes are made to its data. The model does not care or know who is listening to its events but only knows that someone is interested in its data changes and therefore provide the events.

• The view is the graphical component that takes the data from the model and presents it on the screen. Normally it is direct associated with the model so it can pull the data from it. However, some developers prefer to skip this direct association and send the data along with the event arguments fired by the model.

• Last you have the controller. It has a direct references to both the model and view, plus an indirect association with the view, which it uses to detect input gestures from the view. When an event is detected by the controller it can access the view data and determine how it affects the model (typically it just updates the model with the new view input). The model reacts on the changes made by the controller and notify the view which again updates its data.

One of the mistakes often made when people talk about the MVC (at least the original

of 81


Figure 5: Model View Controller

Model View Controller

Model View

Controller

Indirect association(event notification)Direct association

2 Analysis

one) is that MVC is quite low level in comparison to modern graphical controls. An example of a complete MVC component is a label. Today when I want a label I just create a label object has some properties and that is all I need to know about it. Updates, events, input gestures etc are all wrapped up by this single object. In the early days you had the model that represented all your domain data and the UI consisted of a view, controller pair for each widget on the screen. At that time MVC was an efficient way to structure the UI because of its rather low level nature. But it simple does not fit well into modern frameworks.

Even before the arrival of modern GUI frameworks MVC had one major problem. Sometimes the presentation needed additional data and logic then what was present in the domain model. The big question was where to put it. For an example, a developer comes up with a user friendly idea to color code some numbers. To better attract the users attention when critical conditions arise the GUI should paint the numbers in red, and green when everything is okay. The answer is that there is no suitable place to put it. Clearly it has nothing to do with the domain/business logic. The view does not contain any data to perform the required logic and it is also out of the views scope since its responsibility is to present data and nothing else. And the controllers job is only to synchronize the model and view.

The solution came with the addition of an intermediate domain model called application model.

of 81


2 Analysis

2.8.2 Application ModelAs just mentioned, the application model is a result of the limitations of the MVC model.

The application model (sometimes also called presenter model) solves this problem by making an abstract copy of the domain object. The main difference between the application model and the domain model is first and foremost that the application model is part of the presentation layer and not the domain layer. The application model is placed between the domain model and the controller/view pair as shown in Figure 6.

The application model is a copy of the domain data so the view can fetch domain data as usual. However, to avoid redundancy some developers choose and forward the calls to the domain data instead of keeping a copy.

All presentation logic and data is stored in the application model and nicely separated from the domain layer. But problems seldom come alone. With the addition of the application model as caretaker for the presentation logic, how does it communicate its data to the view when there is no direct association with the view. One possibility is to add more notifications that reflect new presentation data. But as the application model grows in complicity the storm of notifications can spin out of control. Alternatively, new associations is a possibility but this will ultimately break the structure of the MVC model. The 'solution' has been up to the individual developer to find the best compromise between breaking the communication rules in order to push data directly onto the view and the complexity of notifications. Though the application model solved a big problem of placing the presentation logic, the solution was not completely satisfied.

2.8.3 Model View PresenterThe final solution came with Model View Presenter (MVP). This model is one of the

more popular even though Martin Fowler, unofficially has retired this model in favor of the Supervising Controller and Passive view. It might be a little daring to disagree with a guy like Fowler that has so much experience and dedication to object oriented design. However I still think that retiring the MVP model and introducing Supervising controller and Passive view as two new models is pushing it a bit, and only adds to the confusion among graphical design models. Ill explain why when reaching the respective models but for now lets see how the MVP works.

of 81


Figure 6: MVC, Application Model

Model View Controller, withApplication Model

ApplicationModel

View

Controller

Indirect association(event notification)Direct association

Model

2 Analysis

With modern GUI frameworks the existence of the controller has become almost obsolete and is therefore removed. The general idea of the 'Application Model' fitted the GUI model very well, it just had some communication problems with the view. The MVP solution is to take the MVC controller logic and hand it to the view. This also fits modern GUI frameworks because that is basically what they done with their widgets. The MVC model is then turned 60 degrees, which gives the application model a new position and is now called the presenter. Figure 7 Shows this.

• The Model; compared to MVC's application model, it is now pure domain data and has no presentation logic. It has no awareness of either the presenter or view. However it has preserved the notifications from the MVC model which provides the view a way to update on changes made in the domain layer.

• The presenter is the real workhorse in the MVP. In comparison to the MVC application model, it plays a similar role to the application model (with out the notifications which are now moved back to the real domain model). But with the difference that it is directly associated with the view which was the main problem with the MVC application model. Now the presenter can take the results of presentation logic and apply them to the view directly.

• The view in MVP plays the same role as in all the previous models but there are small changes in its role. It is expected to handle all the raw input gestures previously handled by the controller. Because of the greater responsibility it is now directly associated with the presenter.

In figure 7, it is clear how the associations work between the components. Compared to the MVC, the Application Model has been redefined and twisted the it 60 degrees.

of 81


Figure 7: Model View Presenter

Model View Presenter

Presenter

ViewIndirect association(event notification)Direct association

Model

2 Analysis

One of the advantages with this model is that it leaves a lot of flexibility when it comes to updating the view. If the UI has very complex presentation logic it is strongly suggested to let the presenter handle the UI manipulation. On the other side if it is simple data that need no manipulation, the view can read the data directly from the model with out the assistance of the presenter and at the same time make the presenter aware of the update should it need awareness of this.

Before finishing off with the MVP model there is one last issue with the communication which leads us to the last two GUI models. Within the last couple of years GUI developers have focused their attention to testability. And that is the reason for Fowlers retirement of the MVP model. MVP is divided into two 'new' models. But lets see what these two 'new' model are about.

2.8.4 Supervising Controller & Passive viewThese two models are still MVP models. The difference is that they are more specific in

terms of how they handle the communication. With MVP the developer can layout the communication to his likings.

With Supervising controller it is determined that the communication should be handled by the view as much as possible which means that updates are handled by events. Code wise this is the quickest and less tedious solution. The disadvantage is that it is very difficult to debug because event are arbitrary and thereby hard to trace.

Passive view is the opposite of Supervising controller. The view does nothing else the project the data that is passed on by the presenter (controller). This can be a tedious coding because every update must be implemented manually via method calls, from the domain data to the view via the presenter. The upside to this is that it is very easy to debug because you can trace the method calls. And lastly it is less complicated to produce a testing object to act as view/user because all inputs are well defined methods. So if testability is a big concern this might be best approach.

2.8.5 Conclusion

2.9 SummeryA lot of ground have been covered during the analysis. It started out by identifying the

risks involved with the project, everything from illness to loss of data. Next up was the big technology question. Different frameworks were discussed and weighed up against each other. Following the technology discussion was a brief look on porting abilities which was a natural thing since the technologies play a big role in portability.The audience were investigated and a method called Ethnographic interview was proposed to capture the mind of the user, which again would provide great input on how the Farmguard Client to be designed. Next up were the more programming related topics. How design patterns could play role in designing the application and lastly a thorough study of the GUI models that could be used in the Farmguard client.

of 81


3 Case study and test of Farmguard Client

3 Case study and test of Farmguard ClientThis third chapter will start out by quickly running over some of the choices from the

analysis, that where made before the actual design process could start. This is followed with a closer look on how the actual system is designed. This includes the different layers such as domain layer and presentation layer and how they play together. To finish off the chapter are some tests that will tell if the client solved the problems it was meant to solve and if it was done in a convenient way for the user.

3.1 Technology ChoiceAs mentioned in the analysis, the Farmguard project was already in development when

the client project started. The interfaces to the client were based on the Microsoft .NET platform and therefore the client had to use the .NET platform as well. With the platform settled there were still a few options with the graphical technology. Here the choice fell on the rather new Windows Presentation Foundation. Though the others were interesting alternatives, WPF felt as the natural choice because it is part of the .NET platform. One of the interesting thing about WPF is it's portability to Silverligt. This means that a move to web based application can be done with a minimal of work. WPF also provides a great degree of freedom when it comes to graphical presentation. You can customize just about anything to look and feel just like you want it and it is almost 100% directX based, meaning great performance. To ease up the construction of graphical components, a markup language, called XAML, is provided to do just that. This does not only make it easier but also a lot faster. Because of XAMLs hierarchical structure, it fits well with the graphical representation and provides a nice overview making it easier to see the big picture.

Lastly it has to be mentioned that WPF is not just for graphical presentation, it is a complete application framework that supports many of the known object oriented patters which again leads to solid structured applications. But if that was not enough, it also comes with a modernized framework structure introducing new and powerful features. One of these is the routed structure that makes it possible for any object in the application tree to catch events coming from other objects. It has a new set of properties which support notification, inheritance, default values an tons of other stuff.

In general it is a feature rich framework that makes it easier, faster and more intuitive to develop applications and that is why the choice fell on WPF.

3.2 Design The Farguard client is divided into two layers, a domain layer and a presentation layer.

Essentially there is a third layer, a data storage layer, but this is handled an maintained by the server component, which is developed by another developer, and is therefore left out of this project. The client will just use an interface which is provided to communicate with the the server component.

A small part of the domain layer is dedicated, as a connection process, to communicate with the Farmguard security gateway. Figure 8 shows a conceptual illustration of the farmguard client.

The connection process section is part of the domain layer but is only used when establishing connections with the FGSG. Basically it functions as a separated box where

of 81



the client provides the selected connections. The FGSG developer can then establish his specialized connections from there and do not need to be concerned about anything else in the client.

3.2.1 Domain modelIn domain models main purpose is to fetch and hold onto the data retried from the

server. There is not too much business logic involved with the client but it is a deliberate choice that were made for security reasons. The idea is to keep as much data within the server and only provide the client with the data necessary. This means that the client will receive different data when logging on the to same enterprise depending on the user. An owner will for instance receive all data belonging to the enterprise were an ordinary user will only receive the data which he is entitled to see.

3.2.1.1 Domain dataBecause the client is intended to be a 'dumb' client it does not store any data locally on

the computer. There are a few exceptions but I will cover then in a moment. All data is retrieved from the server and kept in memory until program close. But let us have a look at what type of data is received from the server.

• User data (requires owner login)A list of all the users belonging to the enterprise. This is typically a list of all the staff working on the enterprise.

• Entity dataEntity data covers enterprise, farms, locations, components and connections and all the details and parameters belonging to them. For instance a component could be a web camera. Data belonging to a web camera could be, name, type, parent (in this case the parent is a location), connections types etc. The data belonging to the entities are almost identical but can differ a little bit.

of 81


Figure 8: Conceptual model

Farmguard Client

Farmguard Server

Domain layer

Presentation layer

Connectionprocess

Farmguard S

ecurityG

ateway

<Interface>

FGSG

<Interface>Server proxy


• ParametersComponents and connections are a little special in that they contain parameters. Parameters are used for data such as IP address, port number, protocol type etc. The good thing about the parameters is that they are not set to a fixed amount or type. It is possible to attach an almost unlimited amount of parameters to a component or connection. And new types of parameters can easily be added to the system.

• Entity typesAll entities must belong to a specific entity type. Because types are abstract and do not represent a specific type of entity, types contains a group ID which then is used to group the different entity types together. The most interesting about the entity types are their drawing blobs. These make it possible to change the clients content by dynamically getting data from the server. Since there are complications for this to work it will be discussed in depth in chapter 3.2.1.2Dynamic data.

• User groups(requires owner login)User groups are groups that are specific to an enterprise and are created by the owner.

• External groups (requires owner login)External groups are from a system root point of view, global groups and are accessible from all enterprises.

• Relations (requires owner login)Relations in the client defines which is related with what. A relation between A & B means that A is a part or belongs to B, or, A has access to B. Basically it means the same but it is more convenient to use the slightly different expressions when explaining the relations. Below, is a table that describes the different relations that is held by the domain layer.

Object A Relations Object BUser Belongs to User group

User group Has access to EntityExternal group Has access to Entity

As the table describes there are three different relations. Later you will see how these relations are visualized in the access tables.

• Log data (requires owner login)Log data is simply a list of connection events. Every time a connection is made it is registered by the server. An owner can retrieve these from the server and consists of the entity the connection was made to, timestamp, who made the connection etc.

These are data objects that the Farmguard client holds onto. Figure 9 shows a complete diagram of the data and how the relate to each other.

of 81



3.2.1.2 Dynamic dataThe Farmguard client partially consists of dynamic data. The advantage of dynamic

data is that is makes it possible to update the client (so to speak) with new content without having to build a new version of the client and force all the distributed clients to download the new version. Instead, new content is added to the database and is automatically downloaded to the client though the server. The problem now is, how does the client know what to do with this new data and this is where the XAML languages helps out.

Before continuing on, remember that the 'entity type' data contained a drawing blob. It is this drawing blob that is the dynamic data and contains XAML language. The drawing blob is used to visualize an entity. For instance, web camera logo, PC logo, Air condition logo or what ever the component might be. Because it is only used as a picture (it is NOT a picture format of any kind, it is pure XAML but functions as a picture ) to represent a component, the client expects the XAML string to represent a Brush object. The client will then try and deserialize the XAML string into a brush object and then use it to paint the entity. Therefore it is important that it is valid XAML in the database otherwise the deserializing will fail and the client will paint the object with a default solid color.

This way the presentation can be changed on the fly without having to close down the server or update the clients. One might argue that the same effect could be archived with a picture instead of the XAML string. This is correct, but a picture has a few drawbacks compared to the XAML. First of the size of XAML string is far less then a picture, even when compressed. The second is that a picture does not scale well when zooming in or out on it. And if the picture is scaled down in order to accommodate a small size, it will look

of 81


Figure 9: Data structure diagram

Entities

Enterprise

Farm

Connection

Component

Location

ComponentParameter

ConnectionParameter

Entity TypeRelationUser

User Group

ExternalGroup

Relation

Relation

Activity Log


even worse when it is scaled up in the application. Because XAML describes how the geometric figures looks and are positioned relatively to each other, the client will just render new images of the 'picture' when it is scaled. This means that the picture will always be sharp and clear.

3.2.1.3 CacheNow a days people normally have broadband connections with the capacity of one Mbit

or greater. But Farmguard is meant to be used on a farm which is located far away from the broadband infrastructure. This means that I can expect situations were the connections is run on old telephones lines with the help of a modem. Therefore data transmitted should be held to a minimal. Though the XAML strings are small in size, the sum of all the required drawing blobs could potentially exceed that of what one would like to download via an old modem connection. To cut down on the data, the drawing blobs are cached on the local computer where the Farmguard Client is installed. Since the drawing blobs do not contain any sensitive data, it can be store without compromising the security.

First time the client connects to the server it gets a list of all the entities that the enterprise consists of. From this list the client complies a list of all the drawing blobs it needs to display the enterprise. Because the client contains a hash value of the entire XAML string, any change in it (or XAML drawing if you will) with result in a different hash value and can thereby tell if it needs an new one from the server. When the client knows what drawing blobs it needs, it tries to read the drawing blobs from a locally stored file. Every drawing blob will have its own file named using the Id. Since this is the first time the client connects to the server it will not find the requested drawing blobs in the cache directory and is forced to retrieve them from the server. When they drawing blobs arrive at the client it will store each drawing blob as a file in the cache directory. From now on, as long as the drawing blobs are not changed, the client will grab the blobs from the cache.

If for some reason the client fails to deserialize the cache file, it will delete it, fetch the blob from the server and write a new file. The cache directory is located in the system user application data folder to avoid an file access violation. This is especially relevant on Windows Vista machines.

Besides storing the drawing blobs, the client maintains a small settings file that remember the last login ID. This is automatically inserted into the login formula to accommodate some user friendliness. This has also been approved by the developer that safeguards the security measurements in the Farmguard system. The short answer to why this is allowed is, that the user id is not considered as a secrete, because of three factor authentication. The user ID is actually printed on the backside of the token. The setting file also contains components that are added to the bookmark box. To identify the component the client uses it's guid6.

6 GUID is short for Global Unique Identifier and is 128bit long. Is is such a large number(3.4x10^38) that the probability of the same id being generated twice is infinitesimally small.

of 81



3.2.1.4 Domain structureThe domain layer is built with one entry point called DataCenter. The DataCenter is a

singleton object which makes it is globally accessible via a static class member called 'Instance'. The singleton implementation also ensures that there can only be one instance of the DataCenter at any given time, even among different threads.

All entities consists of three parts, an EntityClass, EntityType and DrawingBlob where the last is optional. The DrawingBlob is actually part of the View, and discussed in the Analysis; it was important that there was a clear separation between the domain and UI layer. But as usual, there are no rules without exceptions. Because the DrawingBlob is data driven by the server, it is a natural part of the domain data. To hold all these three objects together is a simple generic class called FGCompositeUIElement. Besides wrapping the three objects mentioned above it provides an event notification used by the View. EntityTypes which contain the XAML string that again is parsed into the drawingblob, are loaded asynchronous sometime after the FGEntityClass is loaded. Therefore it is unknown when the drawingblob is ready for display. To solve this the FGCompositeUIElement provides a VisualChanged event to notify the view that it should update its drawingBlob. The structure is illustrated in Figure 10

FGEntityClass and FGEntityType are objects coming from the server. It is the DataCenters responsibility to retrieve these objects from the server and wrap them with a FGCompositeUIElement. However, the FGCompositeUIElement only holds one entity, so to handle them are generic EntityManagers. There is one for each EntityClass and any further references to the entities is done via the EntityManagers.

How exactly the domain layer builds its data can not be shown in a static diagram like Figure 10. To illustrate the sequences going in the domain layer, a dynamic diagram is needed. For this purpose I have made a sequence diagram that shows all the steps that takes place when loading an enterprise. The sequence diagram in Figure 11 does not capture the process of handling the users, external groups, relations etc but only the core data that makes up an enterprise. I feel that it is more intuitive to start out with the basic foundation and then build on top of that. So the rest of the domain layer will follow shortly

of 81


Figure 10:Domain structure.

FGCompositeUIElement<FGEntityClass>

FGEntityType

FGEntityClass

View

DrawingBlob

DataCenter

FGEntityManager<FGEntityClass>

1

1

1

0..1

VisualChanged


after. The sequence diagram should be fairly self explaining but I will add a few lines for each to.

The hole thing starts out by a user triggering the loading process. The job of getting the entityClasses (GetEnterpise) is moved to a worker thread which connects to the server via a server proxy. When the server returns with the entepriseClasses (together they make up the enterprise), the DataCenter skims the entityClasses and writes down the EntityTypes needed for the collection of entityClasses and returns back to its self but in the main thread. Back in the main thread the DataCenter loads up the EntityManagers. When they are set it signals the mediator that it can begin loading the UI layer. But the EntityTypes are still missing so it also starts a new thread for retrieving these. The first task in the 'load EntityTypes thread' is to read the cache directory for existing EntityTypes. Remember form the first worker thread retrieving the EntityClasses; just before returning to the main thread it collected a list of the required EntityTypes, identified by their GUID. The cached files (if any) contain deserialized EntityType objects, one for each file. The file name is used to identify the what file contains which EntityType because the EntityTypes GUID (identification) is used as the actual file name with a file extension of .fget (farmguardentitytype). All EntityTypes have a hash value of their drawingblob (if it has a drawingblob) and a GUID. While deserializing the cached files it builds a 'type' dictionary, keying the EntityType GUID together with the drawingblobs hash as the value. If the

of 81


Figure 11: Sequence diagram for loading an enterprise.

DataCenter(Worker thread)

DataCenter(Main thread)

BeginLoadEntityTypes

WorkerThread

MainThread (GUI)

GetTypeRequestList

GetEnterprise

Sucess

ServerProxy

BeginLoadEnterprise

LoadEnterpriseEnded

LoadEntityManagers

Meidator

GetEntityTypesFromCache

VerifyEntityTypes

LoadUI

LoadEntityTypesEnded

BeginFileWriter

CreateBrushFromEntityType


deserializing fails or the files does not exists the GUID is still filed in the type dictionary but the hash value is left empty. When all the EntityTypes needed are are processed like this, the type dictionary is sent to the server for verification. If the type dictionaries hash value differs from the hash valued stored by the server, the server will send back a dictionary containing the EntityTypes that did not match. After verifying (and retrieving if necessary) the EntityTypes the DataCenter returns to the main thread again. If any EntityTypes were retrieved by the server it will write these to the cache, which is again done in a worker thread. Lastly the DataCenter finishes off by deserializing the XAML form the EntityTypes and store it in the FGCompositeUIElements.

After loading the EntityManagers it is a race between the domain layer (retrieving the EntityTypes) and the UI layer (building the control widgets). In case the UI layer finish before the domain layer; the domain layer will notify the UI layer when it finishes via the VisualChanged event and the entity is displayed correctly. This concludes the domain models core.

The rest of the domain data is retrieved depended on the user logged in. The remaining data is the event logs and the user/access tables. There is very little domain logic involved with the log event data. This is mainly due to the server proxy which provides the data in a convenient way. The log events is a list of FGTunnelControlEvent objects with properties such as device, timestamp, userFirstName, userLastName etc. The DataCenter simply provides a method that provides this list. After that it is up to the widget to display the contents of this list.

The access relation data can not be used directly from the Server proxy and needs a little structuring. However, the structure is rather UI specific so instead of formatting the data in the domain layer it is moved to the presentation logic which is located in the presenter.

To conclude the domain layer is a diagram of the remaining data.

of 81


Figure 12: Domain layer; log events and access relation data.

DataCenter FGTunneControlEvent

Users

UserGroups

ExternalGroups

UsersUserGroupRelationsServerProxy

UserGroupEntityRelations

ExternalUserEntityRelations


3.2.2 Presentation layerThe Farmguard clients primarily function is to visualize data which means the

presentation layer makes up the majority of the application. Building the presentation layer is done by using the MVP model. As described in the analysis the MVP overcomes the limitations of the earlier models and provides great flexibility.

3.2.2.1 UI CommunicationBecause the UI layer is made up of many different visuals, a control unit is necessary

to handle the communications between these. To do this, a mediator object is create. The mediators job is to take output signals from the different controls and communicate them out to the other controls that are affected by particular changes. The advantage of a centralized control unit is first and foremost overview. It means that all communication logic is placed in one spot instead distributed among the individual controls. The individual widgets presentation logic might already be complex enough so relieving them from communication logic, helps avoiding them from becoming a great overly complex beast. Figure 13 shows the two different approaches.

As Figure 13 shows, the complexity grows fast when using distributed communication,

actually the number of communication lines is equal ton∗n−1

2 . Therefore the mediator

is highly recommended when structuring the communication among widgets.Because the client is made in WPF the mediator takes on an additional task which it

normally would not do. WPF provides a visual tree were all the visual components are attached to. It can then traverse up and down the tree to perform measurement, layout and rendering of the visual elements but it also introduces a new feature called routed events. For instance when a button is clicked the event will start out at the source, in this case the button, and travel all the way up the visual tree towards the root. In WPF this is called a preview event. When the event hits the root it turns around and travels all the way back to the source. The later event is the 'normal' event. It is this routed mechanism the mediator uses together with WPFs command feature. This is illustrated in Figure 14

of 81


Figure 13: UI Communication

Centralized communicationDistributed communication

Widget-A

Widget-CWidget-D

Widget-EWidget-B

Widget-A

Widget-CWidget-D

Widget-E

Widget-B

Mediator


WPF introduces a built in command system for all button types and what is even better is that commands make use of the routed mechanism described above. The command pattern is noting new and is part of the design patterns described in Design patterns7. In WPF a command does not implement the logic its self but instead uses a delegate (function pointer in c++) so the implementation can be done by an arbitrary object. In addition to an execute deletage WPF provides a CanExecute delegate which is used to enable/disable the command. It is possible to execute the commands manually but they are intended for buttons and menu buttons that not surprisingly have a Command property.

Because the command pattern in WPF make use of the routed mechanism they are actually called RoutedCommands, so when a button is clicked, the routed command will traverse the visual tree. Unfortunately the mediator is not part of the visual tree so it can not directly catch the command, but it does hold a reference to the main grid which is part of the visual tree. It can then use this main grid to indirectly catch all the routed commands because the main grid is located 'above' the control widgets and therefore the mediator can implement the execution and canExecute methods. The click event could also be done via the mediators widgetChange method but the routed command pattern was so compelling that I decided to use it whenever the opportunity was there.

3.2.2.2 WidgetsI have divided this sub chapter into four parts; Mediator integration, Presenter and

View. In case you might wonder why the Model is not mentioned, it is because the domain layer represents the model and were explained in chapter 3.2.1.4 Domain structure. From a widgets perspective the only important thing to know about the model is the data and notifications it provides via the DataCenter object which is globally accessible because of the singleton implementation. There are quite a few controls in the UI layer so it will be a bit to ambiguous to sketch and demonstrate all of them in detail. Instead I'll demonstrate with one of the controls. Some are more complex then others but the general idea / pattern is the same.

Mediator integrationWith an overall idea of how the UI communication is structured, let us look at how the widgets are build up together with the mediator. The base object in all control elements is the widget object. This object provides the means of communication to the mediator and therefore holds a reference to the mediator object. The mediator has a widgetChanged

7 Design patterns, also referred to as Gang of Four or just GoF is a book from 1995 written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. It is a collection of commenly used design patterns.

of 81


Figure 14: Routed event

Rootelement

Button

Preview event

Event

Routed events


method that all the widgets can call and notify the mediator about changes. The mediator knows of each concrete widget and can therefore make appropriate changes to other widgets. Sometimes it is not enough to just notify the mediator about changes, widgets might need to pass data onto the mediator. The widget does this by passing its self as an argument in the widgetChanged method. All widgets have a 'parameter object' where widgets can store data. The mediator knows about this 'parameter object' and can thereby use it to retrieve data from the widget. For the mediator to identify the changes made by the calling widget, the widgetChanged has a second argument. This argument describes what changes have been made and from that, the mediator can determine what to do next.

PresenterThe first real step in building a control is to create the presenter. Data retrieval from the model is rather trivial and is done with simple method calls. The presenters real work begins with the presentation data and presentation logic necessary for the control. Some controls are quite complex and need several helper classes and objects to perform the presentation logic, while others require almost nothing. When building and processing the presentation data and logic it is worthwhile considering an estimate on how long it will take. The reason for this is that the presenter is working in the main application thread and the UI will freeze during this time. This is especially relevant for the Farmguard client because it collects all of its data from a server. In chapter 3.2.1.3Cache it is mentioned that there is a chance that the Farmguard clients will be run on computers with slow modem connections. In such a situation, the client could hang for several seconds while retrieving and building complex data structures. Therefore, asynchronous data retrieval and processing is preferred in these cases.Let us take a look at one of the controls, the 'Logbox'. The logboxs purpose is to display the log events provided by the server in a gridview8 manner. The presentation data and logic in this case is.

Presentation data• ObservableCollection which is exactly what the view is expecting, but more about

the shortly. The presenter retrieves the event data from the DataCenter and adds them to the ObservableCollection.

• ICollectionView is used to attach filter, sorting algorithms and refreshing the data.• The View• Sorting direction

Presentation Logic (methods)• Show print, and print contents of the logbox.• Change sort direction and sort data.• Apply search filters• Space columns evenly.This is quite a complex control but fortunately for us developers, WPF shipped with

controls like gridview as a standard control. While standard controls and ready to include, you will not get away that easily if you want to use the control to its full extent. The above

8 Gridview is a commen way of presenting data. It is exactly the same as in Windows explorer when choosing 'detailed view'.

of 81



mentioned presentation logic is witness to that fact. While not major tasks, they do require a little 'scratching the surface' in order to archive the desired effects. In particular, customizing the the printing with header and footer was a tricky task, which involved a lot of manual overwriting.

The point is, that the presentation data and logic can be a real heavy weight task. The logboxs logic is rather simple but yet, still requires a good deal of work. Imagine if the gridview control did not ship with WPF, that would involve a lot more work. But again, that is the hole purpose with OOP, reuse what is already there.

ViewWith the presenter and domain data in place it is only the view that is missing. The view is sometimes represented by a custom user XAML file togehter with its code behind file. Existing controls provided by WPF are used in cases where their functionality is sufficient. In cases where the view is very simple and not part of the standard control collection, objects from ordinary code are use to build the view, since it would be overkill to create a custom XAML view just to place a textbox and a button side by side.

One of the really nice features with XAML is that it can contain custom presentation logic in a really simple matter just by tweaking its control template a little bit. It is typically done by defining a condition of one or more properties, when they satisfy the conditions with a boolean true or false you can for instance tell it to set borders fill color to green. When the condition is not met it returns to default values. A very simple example of this is show in code snip below.

Though the above example is very simple, it should be mentioned that building a complete ControlTemplate for some of the more complex controls like a scrollview, it quickly becomes a very large xaml stylesheet. But because the larger and more complex control are assembled by many smaller controls the problem is broken into smaller pieces and thus easier to overcome.

of 81


<Style x:Key="CloseButtonStyle" TargetType="Button" > <Setter Property="Template"> <Setter.Value> <ControlTemplate> <Border Name="CloseBorder" Background="{StaticResource GradientBoxBrush}" CornerRadius="2" BorderBrush="Gray" BorderThickness="1"> <Rectangle Name="cross" Margin="2" Fill="{StaticResource CloseBrush}" /> </Border> <ControlTemplate.Triggers> <Trigger SourceName="CloseBorder" Property="IsMouseOver" Value="True" > <Setter Property="Background" TargetName="CloseBorder" Value="{StaticResource GradientStdMouseOverBrush}" /> </Trigger> <Trigger Property="Button.IsPressed" Value="True" > <Setter Property="Background" TargetName="CloseBorder" Value="{StaticResource GradientStdMouseDownBrush}" /> </Trigger> </ControlTemplate.Triggers> </ControlTemplate> </Setter.Value> </Setter> </Style>


As the MVP describes, the view can handle data update logic by its self and one the cool ways of keeping the view synchronized is with data binding. For instance, say you have a boolean property telling us whether or not an object is stored in the clipboard. The past menu button, in the menu bar, should be enabled/disabled accordingly to the clipboards boolean property. With a simple data binding setup between the two properties it will handle its self. But bindings can do more then just that. Bindings can be bidirectional so that changes in either end will update the other. Bindings also support converters, making it possible to bind different data types together. This is done by providing the binding a converter object. WPF ships with a set of converters used for common encountered data types, for instance conversion between boolean and visibility. But the developer can also create his/her own converters and even define separate logic for each direction, one from A to B and another for B to A. Because the converter object leaves the actual conversion logic up to the developer, it can be used to make conditional bindings. For instance, in case of grammar, it is possible to implement logic that takes singular and plural in to consideration. Take a converter, which input argument is the number of connections and the implementation would look like this.

of 81


public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) { int connectionCount = (int)value; if(connectionCount > 1) { return "Connections "; } else { return "Connection "; } }


So far I have showed a couple of different features and techniques used to make the views. But what does the actual view look like. As mentioned the views are custom user control built up by XAML and because of that it is actually very easy to show you how a view looks like. Figure 15 shows the view belonging to the user-usergroup access control.As Figure 15 shows, the view consists of several components. The highlighted ones are panels that are used to structure the view but also the 'opdater' botton, filter check boxes are parts of the view. All these parts have a name property which is accessible via the code behind file and it is this files the presenter uses as interface to the view. With this interface the presenter can read and change any parts of the view. In addition all these components have events which the presenter can catch and react to.When I say that Figure 15 represent the access control view it is not entirely true because there are more to it then that. Actually Figure 15 only shows the static part of the view. The dynamic access table, which will be placed in the 'TablePlaceHolder' panel, is built up by the presenter and consists of many small visual objects that also are part of the view. But wiring it all together is the presenters job.

So to sum up the view, the point is that you can quickly sketch up the view in XAML and automatically get an interface to it so the presenter can access it. If the view does not exist as a standard component there is some additional craftsman work in making the custom view. ControlTemplates can be used to structure the view as well as bindings, converters and commands are used to synchronize and notify its surroundings about its state/actions.

of 81


Figure 15: Access control view.


3.2.2.3 Presentation diagramsWith the individual presentation parts described let us finish off by taking a look at the

big picture. Figure 16 Shows the class diagram of the presentation layer. To the right is the domain layer (model in MVP terms). At the top sits the mediator that handles all the communication between the control widgets and occasionally make changes to the domain layer. In the middle is the control widget which make up the presentation layer. The control widget consists of a widget which provide the mediator communication, a presenter that handles the main presentation logic and a view made up by XAML (for the most part of it). Finally commands and bindings provide assistance in synchronizing and notification between the presentation and domain layer.

While the class diagram shows how the individual components are built up, the presentation layer consists of many individual visual components communicating and handling various user input. Instead of typing a long list of all the components, I have instead chosen to show a navigation diagram that shows the real deal. This navigation diagram consists of screen shots taken from the Farmguard client and scaled down to thumb size and connected in the order of which the screens appear. There is a picture for every main control element in the Farmguard client and should you want to study the screen shot in more detail, appendix 5.5 Farmguard screen shots holds a full size picture of all the screen shots in the navigation diagram.

of 81


Figure 16: Widget structure

Presentation layer

Widget

Presenter DataCenter

Domain data

View

Binding

Mediator

RoutedCommand

Legend:

Control Widget

1

*


3.3 Use case testThe use case test is a way of ensuring that the problems have been solved according

to the problem statements defined in the requirement specifications. This allows for traceability back to the projects beginning. Not surprisingly the use case tests are base on the use cases. The first step in the test is to make a test plan. Besides trivial information such as the person conducting the test, test Id, test type etc. the test plan describes the following:

• Test purpose What part of the system will be tested and what does it involve.

• Test description The process of the test I.E the steps involved.

• Test prerequisites What conditions needs to be met before the test can be performed.

• Test cases Different cases of the same test. For an example, an input form, one case could be with the entire input form filled out, and an other were the form is blank, or partially blank.

• References Use case references / involved with the test.

• Acceptable error margin If the test accepts an error margin, what are the max / min limits.

For each test plan a test report is mad to capture the results of the test specified in the test plan. Just as the test plan, it holds trivial information as test type, test plan used, test report ID etc. The actual content of the test report includes:

• Test result A description of the test results, including the different test cases.

• Error / deviation Occurring errors during the test. Any deviations from the expected result and if they are within the accepted error margins.

• Conclusion A short conclusion on the test results followed by an assessment on what further adjustments if necessary.

I have included the first use case test in the report as an example on what they look like. Because there are several test case each taking up a hole page I have added the rest of the test cases to the appendix chapter 5.4 Use case tests.

of 81


DTU - IMM

Test plan

Test type:Use case test

Conducted by:Christian James

Test ID:§301

Version:1.0

Test purpose:For a user to log into the Farmguard system.Test description:The test attempts to login with both accurate and inaccurate information. This is of course manly to test if the user can log in but also to see what happens when incorrect information is entered. Test prerequisites: The user logging in is required to have a token that generates one time passwords as well as a user Id and a personal pin code. Secondly it is required that the computer used has its system time set correctly.Test cases:- Input with correct information.- Input with wrong user name- Input with wrong pin code- Input with wrong one time password.- Input with correct information but with bad system time.References:Use case: §201Acceptable error margin:No errors are acceptable in the login process.

Test report:



Used test plan:§301

Test repport ID:§401

Test result:- Correct input logs in the user as intended. - Wrong information entered regardless of the what type results in the same error message, saying that input could not be verified.- Incorrect system time results in the same error message as incorrect input information.- Typing in letters instead of numbers results in a error message notifying the user that only numbers are allowed.

Error/deviation:No errors in login procedure. Error messages can do some degree be interpreted as an error deviation.Conclusion:The login procedure works as intended. However there are is a little issue with the incorrect system time. The user needs to be correctly informed of this instead of telling him/her that the input was incorrect.

of 81

TNM Consult


3.4 User testWhile a use case test can tell us whether the product solves the problems specified in

the requirement specification, it does not tell us anything about the usabilities quality, which is equally important. There are two main reasons to why usability is so important, the user patience and competition. When users sit down and try out a program they will have decided within the first 10 minutes, whether or not they want to continue with the program. This is of course subject to the nature of the programs size and complexity but the point is that if the user does not feel comfortable with the program within a reasonable amount of time they will reject it. Secondly, software engineering is now a huge industry which means a lot of competition. Others might provide the same functionality as you so the only way to separate you product from the rest, is by usability.

To conduct the user test you obviously need a user to sit and try out the program. Testing the Farmguard client were three volunteers, two farmers and one IT supporter from TNM Consults sister company TNMIT.

• IT-SupporterAs an experienced computer user the IT-Supporter quickly familiarized himself with the program layout. But experienced users often have a preference for keyboard efficiency rather then mouse navigation. And this also showed when he desperately were trying to navigate via the keyboard and looking out for keyboard short-keys. However, the navigation map which is primarily mouse based was still a success with the IT-supporter because it is very simple and thereby provides a quick access to components installed on a farm. One thing he was missing was an actual true sketch up of the farms. At the moment the farms, locations etc are automatically laid out so they take up as little space a possible while still providing enough margin to make it look nice. The reason why the TI-Supporter wants a true scale model of the real farm is that they provide on-site support. When on-site the supporter often have to search several large buildings in order to find components. With a true scaled down model he would know where to go in order to find the desired components.Another complaint was that he wanted an option to scale down the size of the application. Desktop computers this is not a problem but for small laptops that they usually bring with them for on-site visits, the size becomes a problem.When selecting the enterprise and filtering log events he was very happy about the filtering mechanism which worked very intuitive and fast.

• The FarmersThey were really pleased with the navigation map which gave them an overview of what IT components is installed within their enterprise. As anticipated their main tool is the mouse and keyboard is only used for inputting text, so the lack of keyboard navigation was not even mentioned. In contrast to the IT-supporter the farmer did not mention a real scale model of their farm. This also seems logical since they obviously have a clear picture of their property and where IT components would be installed.The client timing out after 2 minutes of inactivity was an annoyance for them. Their preferred use of the Farmguard client was to log on once when they started the day and then leave it open during the day and close it when going home. That way they would have the equivalent of their old desktop with icons (short cuts) opening the

of 81



connections but with the client handling the log on procedure.The access control panel was not as obvious as I had hoped, but needed a little explaining. Once explained (which was not too hard), it was fairly easy to use and did not involve further problems. As with the IT-supporter the filtering worked well and was easy and intuitive for them to use.

3.5 SummeryDuring the case study the focus have been on designing and implementing the

Farmguard client. I started out by specifying the technology used for the implementation which involved a brief resume of the .NET and WPF framework together with XAML. Next came up the design phase that had two major parts, domain model and presentation layer.

The domain layer talked about the domain data, some dynamic data via the server, some cache issues and finally the actual domain structure.The presentation layer talked about the overall GUI communication realized by the mediator pattern. Then the MVP model came into play and it was shown how the presenter was build into the mediator and of course how the three components (model, view, presenter) would communicate and take advantage of the new WPF features such as the routed mechanism, converters, bindings and commands.

Finally the Farmguard client was put to the test. First it was tested if it had solved the problems specified earlier on in the 1.2.3 System Requirement Specifications.Following the use case test was a user test which consisted of feedback from two farmers and an IT supporter from TNM Consults sister company (TNM-IT)

4 ConclusionWhen reflecting back on the Farmguard client project, I am filled with a lot of different

feelings and thoughts. Therefore I have decided to split the conclusion into three parts. First I will talk a little about the personal experience I have gained during the project and how it was being part of a collaborate process. Secondly, how did the Farmguard Client turn out. Good and bad decisions, what can I learn from my mistakes, how could I have done better and of course also the successes. Lastly, some future perspectives being both sort term as well as long term.

4.1 Personal thoughtsLet me start off by saying that the Farmguard Client project has been a great

experience, both personally and technically. It has been a lot of hard work but also a lot of fun and can honestly say that I have enjoyed ever little bit of it. Of course problems have occurred during the project but after all, that is part of the job, solving problems. And in the end, the satisfaction of overcoming the problem always overcome the agony sometimes inflicted by the problem.

When beginning this project I was naturally very excited, not only because it was my final project but because it involved some aspects that I had not experienced before, or at least not to the same extent as with the Farmguard project. To begin with, this project was actually meant to found the basis for the real Farmguard Client, which I think is quite

of 81


4 Conclusion

admirable to give an engineering student such a responsibility. Secondly, even though the Farmguard Client was my own project, the nature of Farmguard required me to work together in a team and cooperate with two colleges in order to make a functional system. To me this is what always amazes me every time I read about engineering projects. Individual persons combining their components into a useful system, so this was of course something that I really had been looking forward to; being part of a team and contributed to a greater system.

Besides teamwork, working on the Farmguard client project has also given me a lot of experience with WPF and .NET. Though these technologies undoubtedly still have uncharted areas for me, I do feel a lot stronger and more confidence working with them after have done this project. Because in the end there is only one real way to learn it, and that is by getting your hands dirty.

4.2 FarmguardThinking back to the projects beginning I would say that I got off to a good start.

Captured the target consumer and retrieved some valuable information which lead to the keyword “simplicity”. Keeping in mind that Farmguards primarily function in the everyday scenario, is to establish connections to IT components. I quickly come up with the goal that, it should be as simple as clicking the VNC9 icon on the Windows desktop. And according to the initial user tests, I would say that I was pretty close to that goal. Generally I am pretty pleased with the design of the controls and think they are pretty intuitive. However it showed that in some cases (mainly the access grid) an explanation was necessary before they could understand them. Luckily these explanations were simple enough to fit a tool tip or a little program manual. The success of the controls is no doubt a result of studying the target consumer and figuring out what type of interface that fits them best. To keep me on tract I used another little method I made up during the project. Every now and then I would take a friend with no knowledge about the Farmguard project and present him/her for the access table(as an example) and as questions like “what do you think these lights mean? Or what do you think happened when I clicked that button?”. This little feedback was actually a pretty good indication whether or not I was on the track or not.

Structuring the program using OOP was major task. Because the server proxy handles the data transformation between the data storage and the domain layer this was not necessary to implement in the domain layer. Of course you can argue that the server proxy is part of the domain layer but as said, it was not implemented by the Farmguard client. A result of this, the DataCenter object became a little too big for my taste and took on the responsibility of handling almost all the domain logic by its self. Although it works quite well, refactoring the DataCenter is definitely something that could improve on the domain layers structure and overview.

The biggest part of the Framguard client consists of the presentation layer and therefore also did a thorough research on how to structure the GUI layer. There were many great models but unfortunately the subject is also very confusing because of the many different interpretations of how the models work. After comparing several variations of models I believe that I have got a somewhat correct idea of how they work. Because WPF introduces some new and useful features I must confess that I did not obey the rules

9 VNC is short for Virtual Network Computing and is an alternative to Microsoft's Remote desktop (RDP)

of 81


4 Conclusion

of MVP 100% but did some tweaking with the communication and moved a little bit of the execution a round. However, the MVP model is still the main GUI structure in the Farmguard client and it is only in very few cases were I broke the rules and generally I am very pleased with the outcome of the presentation layer and how the MVP model works in the Farmguard client application.

WPF provides a welcoming addition to the .NET application framework in the form of XAML, which adds a new way of creating visual components. But there is one area that I would have liked to studied some more. The view's I made were built as user controls which is just a composition of standard components encapsulated by the user control. Custom controls, which is the ones I would have like to study some more, are controls were you implement the control logic in an ordinary class file. The class file then supports ControlTemplates and Themes for visualizing and should have at least one default template stored in the resource directory. This provides a much more flexible control because it can be restyle simply by overwriting its default ControlTemplate (as I showed in 3.2.2.2 Widgets by changing the buttons view). This provides a new and very interesting way of implementing the MVP model, however, creating these custom controls is not an easy task and there were simply not enough time in this project to cover these as well.

As said before, I am quite satisfied with the design/structure of the Farmguard client but as always, I still think there is room for improvements. The reason why I say this might actually be answered by a quote from Martin Fowler, that goes like this: “As complexity of the system gets greater, the task of building the software gets exponentially harder”. As to date, the Farmguard client is the most comprehensive software application I have worked on and its complexity far exceeds those projects made during my DTU courses. Looking back I can certainly say that he was not wrong about that statement because the Farmguard client has definitely been a challenge.

4.3 Future perspectives Building successful software today is a continues process. The competition is so hard

today that you need to be one step ahead all the time, otherwise you will quickly be overtaken by a rival company. So with the initial version of Farmguard finished it is time to think about the future. What directions could it take and what additional tasks could it perform.

One of the possibilities with Farmguard is as an integrated part of an enterprise application. Farmers as well as other companies need applications for their economics, managing suppliers and stock, staff, analytic applications etc. Here Farmguard acts as security and accessibility and can be integrated with the other applications as part of an enterprise application.

There is of course the idea of porting the Farmguard client. Two good candidates would be a web based version and hand held computers. As discussed earlier, because choosing WPF the client can be ported to Silverlight. I have done some quick research on Silverlight and with version 2 now out, it shouldn't be problem. However one of the problems with Silverlight is that it can not embed third party programs. And because some of the connections relay on third party programs not normally found on computers, it limits the use of Farmguard. The second candidate is a hand held computer. Technology wise these computers should be fully capable of running a Farmguard Client application. However, it would be necessary to redo the presentation layer because of the small

of 81


4 Conclusion

screen. Maybe also take a look at ways to generally speed up routines by optimizing the code since desktops CPU power is many times that of a hand held computer.

Another idea could be to make a private version of the Farmguard system. Imagine you are on some remote location and you need some file from the home computer. You have the Farmguard Client stored on you USB stick. You load up the Farmguard client from the USB stick and just like that you have access to your home network. You would probably implement a wake of lan feature so your computer does not need to run 24/7.

At the moment it is unknown what direct it will go but at least it seems that there are many possible paths to take.

of 81


5 Appendix

5 Appendix

5.1 GlossarySome names and words used in this report may not have the exact same meaning or

definition as found in the dictionary. Some of them are related to the language use by the IT-business and others a special for this project. Here is a list of the most common words used in the report that has a slightly different meaning then normal.

• Client• Component• Enterprise• Entity• External user• FarmGuard Security Gateway (FGSG)• FarmGuard Server (FGServer)• Owner• Staff• User

Client relates to the software or program that this report is about. The system has one server with an arbitrary number of identical 'programs' connecting to it. Therefore the terminology Server-Client(s).

Component is a special type of entity. What makes them different from other entities is that you can connect to them. In other words, a component is a physical device that has a network connection.

Enterprise describes a collection of farms. The location of the farms is irrelevant and a farm can only belong to one enterprise. For an enterprise to have meaning it must contain at least one farm.

Entity is a general description of elements that make up an enterprise. There are many different types of entities but are all building blocks in an enterprise.

External user is equal to a user but with the exception that an external user does not by definition belong to an owner and his enterprise.

FarmGuard Security Gateway is a modified router that can open and close connections to components. Is does so in agreement with FarmGuard Server.

FarmGuard Server is the central actor in the system. Among it's tasks is, handling authentication and authorization coming from the clients, approve connections and storage of data.

Owner is a person that owns an enterprise and is registered in the FarmGuard system.

of 81


5 Appendix

Staff is a person who is registered in the system and assigned to an owner and can operate within the owners enterprise.

User can be either an Owner, Staff or External user. So basically a person that interacts with the system.

of 81


5 Appendix

5.2 Use case diagrams

of 81


Owner

Create user group(§204)

FarmGuard Client

FarmGuard Server

Delete user group(§205)

Add/Removeuser-group relation (§206)

Add/Removegroup-entity relation (§207)

Add/Removeexternal users (§208)

Add/Remove externaluser-entity relation

(§209)

View activity log(§210)

Print activity log(§211)

«extends»

User

«inherits»

Check Allowlist(§203)

Get allow list(§202)

«uses»

Login (§201)

5 Appendix

5.3 Use cases

of 81


FarmGuard Client

Connect tocomponent (§214)

User

FarmGuard Security Gateway

FarmGuard Server

Owner

Get entities (§213)

Bookmark component(§215)

«uses»

All use cases in this diagram except from §212 and §215 make use of §203 'Check allow list ' to determineif the requested task is allowed for the current user.

Get & Selectenterprise (§212)

DTU - IMM

Use case §201: LoginPurpose Provide a login formula for the users, enabling them to enter

the Farmguard system.

Preconditions None

Success end condition The entered information is correct and the user is logged into the Farmguard system.

Failed end condition User is denied even if the information is correct.

Primary actor User


Motivation and interest In order to use the system users need to be logged in. This login formula provides an easy way of entering the system.

Trigger The use case is triggered by the user.


1 User clicks 'login'

2 The client provides a formula to fill out. This includes a user id, pin code and a one time password generated by a token.

3 The client forwards the input to the server that returns with a response.

4 The server responses with a success message.

5 User is logged in and can proceed using the system.

Extensions 3a Server does not respond with a success

4a There are many different kinds of responses other then success. The used is not logged in and notified of what went wrong, incorrect input, no connection etc. and is prompted to try again or contact support.

Priority High

Frequency High

References §101

Use case §202: Get allow listPurpose To get an allow list which contains the operations the user is

allowed to execute.

Preconditions User logged in and a working connection to the server.

Success end condition An allow list is returned for the current user logged in.

Failed end condition A person that does not have authority to execute any operation is not a fault (but unlikely). Therefore the client can only determine of the correct allow list is returned by checking the server response, which should be success. Any other response will be interpreted as failed end condition.

Primary actor Farmguard server.

Secondary actor Motivation and interest The user needs the allow list to use the system.

Trigger Login. The login is retrieved immediately after logging in.


1 A user loges in successfully.

2 The Farmguard server is asked for an allow list.

3 Farmguard server respond with a success and the allow list is stored.

Extensions 3a The server does not response with a success.

4a The user is noticed about the error and is asked to log in again.

Priority High

Frequency High

References §102, §103, §201

of 81

TNM Consult

DTU - IMM

Use case §203 : Check allow listPurpose To check the users authority. This check is performed every

time a user tries to access, alter and delete data. It is also used to initialize the user interface. Not all buttons and options should are visible for all users. With the allow list the client can check what controls it should provide the user.

Preconditions Allow list successfully downloaded from the server.

Success end condition That the allow list return a true/false as result.

Failed end condition Using allow list results in an error (exception)

Primary actor Farmguard Client

Secondary actor Motivation and interest Security measurement upholding authorization

Trigger Server operation.


1 A server operation is triggered.

2 The Farmguard client checks its allow list for a match of the desired operation.

3 If the allow list checks out okay, the operations is performed. If not the user is presented that with an authorization warning and the operation is not performed.

Priority High

Frequency High

References §101, §215

of 81

TNM Consult

DTU - IMM

Use case §204 : Create user groupPurpose For an owner to create a group that belongs to his

enterprise.

Preconditions 1) The user logged in must be owner of the enterprise.

Success end condition The new group is created and is related to the currently enterprise.

Failed end condition The group is not created or is linked to a different enterprise.

Primary actor Owner

Secondary actor FarmGuard Server

Motivation and interest For the owner to organize access control. By creating groups (s)he can specify access among his staff.

Trigger The owner wishes to group people together.


1 The owner calls forth an input formula with a click of a button.

2 Owner types in the group name and a short description. Client provides sanity check on the input. Description is optional but group name must consists of minimum 3 letters. When the input is verified a submit button is enabled.

3 Owner clicks submit and the client sends the information to the server and awaits for a response.

4 The server responds with a success and the client reloads and updates all user interface elements that relates to groups.

Extensions 3a Server response is not a success but with an input validation error. User is asked to try again with correct input.

3b Server connection could by established and the

user is asked to verify his Internet connection and try again code.

Priority High

Frequency Low

References §101, §215

of 81

TNM Consult

DTU - IMM

Use case §205: Delete user groupPurpose To delete a group.

Preconditions 1) The user logged in must be owner of the enterprise.2) A group must exist.3) The group must not contain any users.

Success end condition The group is remove from the enterprise and system.

Failed end condition User group still exists in the system.

Primary actor Owner

Secondary actors Farmguard Server.

Motivation and interest For the owner to organize access control. By creating groups (s)he can specify access among his staff.

Trigger The owner wishes to remove a group. Maybe the groups is not needed anymore.

Main procedure Step Event1 The owner enables 'delete mode' by clicking a

button.

2 The owner picks a group to delete.

3 The selected group id is sent to the server for deletion.

4 The server responds with success indication that the group was successfully deleted.

5 All user interface components related to the deleted group are reloaded and updated to reflect the new state.

Extensions 3a Connection to server fails. The user is notified and the process is terminated.

4a Server responds with a fault. The user is notified that the operation was unsuccessful with an error code and asked to try again.

Priority High

Frequency Low

References §102

of 81

TNM Consult

DTU - IMM

Use case §206: Add/Remove user - group relation.Purpose Create or delete a relation between user and a group.

Preconditions The user logged in is required to have a role type as owner for the current enterprise or higher.

Success end condition A relation between the intended user and group is created/removed.

Failed end condition The relation is not removed/added.

Primary actor Enterprise owner


Motivation and interest Adding and removing individual users to groups.

Trigger The enterprise owner triggers this operation.

Main procedure Step Event1 The owner picks the access table for user and

groups.

2 From the access table, the desired relations are added/removed.

3 The new relations are collected and sent to the server.

4 The server responds with a success meaning all relations were saved.

5 All user interface components related to user – group relations are reloaded and updated by the client.


3b Server responds with a fault. The user is notified that the operation was unsuccessful with an error code and asked to try again.

Priority High

Frequency Low

References §103

of 81

TNM Consult

DTU - IMM

Use case §207: Add/Remove group / entity relation.Purpose Administrate access for groups. User groups are assigned

to zero or many entities. Members of a group have access to what the group is assigned to.These relations follows a parent/child access hierarchy which must be followed. For instance, a group can not have a access relation to a location it does not have an access relation to the farm containing the location. However the client will help with this rule and notify the user about it.

Preconditions 1)The user logged in is required to have a role type as owner or a higher. This is determined by the allow list.

Success end condition Relations are added to the selected entities and groups.

Failed end condition Selected/removed entities are not changed.

Primary actor Owner

Secondary actor Farmguard client, Farmguard server

Motivation and interest Grant/deny groups access to one or more entities.

Trigger Owner

Main procedure Step Event1 The owner selects or removes all the relations

(s)he wish to add/remove. This is done with the group / entity access relations table.

2 Client checks for parent constraints.

3 The new relations are sent to the server and saved.

4 The server responds with success.

5 All user interface components related to entity – group relations are reloaded and updated by the client.

Extensions 2a If the parent access role is broken the client automatically add or removes relations.

4a Connection to server fails. The user is notified and the process is terminated.

4b Server responds with a fault. The user is notified

that the operation was unsuccessful with an error code and asked to try again.

Priority High

Frequency Medium

References §104

of 81

TNM Consult

DTU - IMM

Use case §208: Add/Remove external usersPurpose To lookup external users in the system and add/remove

them to/from the enterprise.

Preconditions 1)The user logged in is required to have a role type as owner for the current enterprise or higher. This is determined by allow list. 2) For removal there can not be any relations to the external user.

Success end condition External users(s) are granted access to the enterprise. No further access is granted, only an empty enterprise.

Failed end condition 1) Existing external users does not show up or 2) are not added to an enterprise.

Primary actor Owner

Secondary actor Farmguard server

Motivation and interest When an enterprise owner wants support from an external user he can quickly find them in system. After adding the external user to the system it is possible for the owner to grant him access to the specific component/entity.

Trigger Owner

Main procedure Step Event1 The owner brings forth a list containing the external

providers.

2 The owner can either scroll through the list or filter it with an input box.

3 When the external user is found the owner can added him to the enterprise.

4 The client submits the user to the server.

5 The server responds with success and the access grid panel for external users is reloaded to get the changes just made.


5b Server responds with a fault. The user is notified

that the operation was unsuccessful with an error code and asked to try again.

Priority High

Frequency Medium

References §105

of 81

TNM Consult

DTU - IMM

Use case §209: Add/Remove external user-entity relation.Purpose To add a relation between an external user and an entity.

Preconditions 1)An external user must have a relation to the enterprise as described in use case §208.2) The person logged in must be owner of the enterprise or higher.

Success end condition The intended relation(s) are added/removed form the server.

Failed end condition The intended relation(s) are not added/removed form the server.

Primary actor Owner

Secondary actor Farmguard server.

Motivation and interest The external will usually be other companies that sell agricultural IT equipment. With the external / entity relations the owner can provide the company's support people access to the specific component they provide.

Trigger Owner.

Main procedure Step Event1 The owner selects the intended relations.

2 Client sends the relations to the server.

3 The server responds with success and the UI interface components the reflect any relations to the external user / entity relation are reloaded.


4a Server responds with a fault. The user is notified that the operation was unsuccessful with an error code and asked to try again.

Priority Medium

Frequency Low

References

of 81

TNM Consult

DTU - IMM

Use case §210: View activity logPurpose To show a list of who has made connections to what

component in the past. Provides name, component, time and type of component connected to.

Preconditions The user logged in is required to have a role type as owner or higher. This is determined by allow list.

Success end condition A list of events is listed for the owner.

Failed end condition 1) Events not listed for the owner.2) Events are listed for ordinary users.

Primary actor Owner

Secondary actor FarmGuard Server

Motivation and interest To keep a history track of who has accessed what and at what time. This is value information for the owner if an error has happened.

Trigger §201 - Login procedure.

Main procedure Step Event1 An enterprise is selected.

2 Client checks allow list if the user is allowed to view the event log.

3 If yes the log is retrieved from the server and and option to view it is presented for the owner.

4 User is provided with a set of sort and filter options to help him what what he is looking for.



3c If the user is not allowed the see the log it is not retrieved and menu/buttons to view log are hidden.

Priority Medium

Frequency Low

References

of 81

TNM Consult

DTU - IMM

Use case §211: Print activity log.Purpose Take an print of the activity log.

Preconditions Use case §210

Success end condition A print file is sent to the system print spool containing the visible content on the activity log.

Failed end condition Print file is not sent or it's content is wrong.

Primary actor Owner.

Secondary actor Motivation and interest Acquiring a physical print of the log.

Trigger Owner.

Main procedure Step Event1 Owner opens the activity log, filter and sort it as

(s)he want it.

2 Owner chooses to print it.

3 Log page is fitted with Farmguard header printing and page numbers.

4 Print file is sent to system print spool.

Priority Low

Frequency Low

References

Use case §212: Get & Select enterprisePurpose To select and retrieve an enterprise.

Preconditions 1) User must be logged in. Use case §2012) the current user must be assigned to at least one enterprise.

Success end condition User picks an enterprise and is retrieved.

Failed end condition User can not retrieve his enterprises.

Primary actor User.

Secondary actor Farmguard server.

Motivation and interest To use the system. Without enterprise data the client is no use.

Trigger User.

Main procedure Step Event1 After authorization and authentication the user is

presenter with the enterprises he has access to.

2 The user picks the desired enterprise.

3 The client retrieves the enterprise data from the server.

4 Server responds with success and the enterprise data is presented in a graphical manner.

Extensions 2a If only one enterprise is available it is picked automatically by the client.

3a Connection to server fails. The user is notified and the process is terminated.


Priority Very high

Frequency Very High

References

of 81

TNM Consult

DTU - IMM

Use case §213: Connect to componentPurpose To establish a connection to a selected component.

Preconditions The user must have access to a connection. If not (s)he will not be able to see any and thus not make the connection.

Success end condition The desired connection is established.

Failed end condition For some reason the connection can not be made.

Primary actor User.

Secondary actor Farmguard server, Farmguard security gateway

Motivation and interest To establish a remote connection to a component. This could be a webcam, remote desktop, ssh access etc.

Trigger User.

Main procedure Step Event1 The user picks the component and one of it's

connections. Then the user opens the selected connection.

2 The client checks if the required external application is installed on the computer.If the application is missing the user is asked to install the application.

3 The client connects the server an requests permission to use the selected connection.

4 The server respond success together with information (no passwords are included in this information) to make the connection.

5 The client connects the security gateway, along with the data retrieved from the server, and requests the selected connection.

6 The security gateway returns with an acknowledgement that it is ready to accept the desired connection.

7 The client loads an external application, together with the log on parameter, that is used to make the connection. This can be browsers, VNC clients, MS

remote desktop etc.

8 The external application starts up and connects to the component selected with the Farmguard Client.

Extensions 2a If the application is missing the process is terminated.

3a The server could not be connected. User is notified.

4a The does not return success. The user is notified and process terminated.

5a The security gateway can not be connected. The user is notified and process terminated.

6a The security gateway does not acknowledge the connection. The user is notified and the process is terminated.

Priority Very high

Frequency Very high

References

of 81

TNM Consult

DTU - IMM

Use case §214: Bookmark componentPurpose Bookmark a component. The bookmarks are tied to

individual users.

PreconditionsSuccess end condition The component bookmarks are store on the PC locally.

Failed end condition Bookmarks are not store on the PC.

Primary actor User

Secondary actor Motivation and interest If an enterprise has a large amount components and your

frequently used components are not naturally close to each other, it can be a tedious job of navigating to them one by one. With a bookmark system the user can access his favorite components easily and quickly.

Trigger User

Main procedure Step Event1 The user selects the component (s)he wishes to

bookmark.

2 With a mouse click and a key combination the user can drag a component to the bookmark bin.

3 The program is eventually close and the client will write the components to the a local file.

Extensions 1a A component is selected from the bookmark bin and is removed from there with the delete key.

Priority Low

Frequency Medium

References

of 81

TNM Consult

5 Appendix

5.4 Use case tests

of 81


DTU - IMM

Test plan



Test ID:§302

Version:1.0

Test purpose:To test the use of the allow list. The allow list contains all the server calls allowed for the current user and thereby determines which controls should be available for the user. Test description:Different users with different access will be logged in. When logging in an access allow list will be retrieved which determines which UI controls should be exposed for the user.Test prerequisites: User logged in.Test cases:- Administrator user logged in.- Owner logged in.- user logged in.References:Use case: §202 and §203Acceptable error margin:No error margin accepted.

Test report:



Used test plan:§302

Test repport ID:§402

Test result:- Users logged in as administrator or owner will correctly be presented with some additional controls such as log events and access panel.- Users without administrator or owner rights are not presented with log event or access panels.Error/deviation:The user events and access panels are not disabled when logging out, but the content is cleared. When the next user logs in the allow list is fetched and the access panel is correctly set again.Conclusion:The allow list works as intended. The correct server calls are returned from the server and the client uses it to set the users authority.However there is found a small glitch when logging out, where client stops checking the allow list or should just reset to some initial state.

of 81

TNM Consult

DTU - IMM

Test plan



Test ID: Version:1.0

Test purpose:

Test description:

Test prerequisites:

Test cases:

References:Use case: Acceptable error margin:

Test report:



Used test plan: Test repport ID:

Test result:

Error/deviation:

Conclusion:

of 81

TNM Consult

5 Appendix

5.5 Farmguard screen shots

of 81


Illustration 2:Enterprise selection

Illustration 1: Log on formula

5 Appendix

of 81


Illustration 3:Farm map

5 Appendix

of 81


Illustration 4:Farm tree view

5 Appendix

of 81


Illustration 5:Bookmark list

5 Appendix

of 81


Illustration 7:Print preview

Illustration 6:Event log

5 Appendix

of 81


Illustration 8:Access control list

5 Appendix

of 81


Illustration 9:Establishing connection

dtu-imm / tnm consult exams project 2008etd.dtu.dk/thesis/259767/dip08_59.pdf · ·...

Documents