New Project – RAW Rota Generator

Posted on by Robert Worrall

My day job requires me to create rotas for GP’s and Nurses. This is planned out of a spreadsheet which in turn counts the number of clinics, types etc onto a separate sheet.

For long time I have thought about creating software that would create the rota for me. Given the number of variables for a rota, there are no perfect solutions but only a best fit option.

This leads me to think that some AI search algorithms could be used to find the optimal solution.

This project can be done done some of my break time and can be done concurrently with the KUP Assessments Project.

KUP Assessments – Development Process

Posted on by Robert Worrall

Development will follow TDD type process from validated requirements. The process will be as follows:

  • Valid Requirements using the following criteria:
Criterion Description
Necessary Can the system meet prioritized, real needs without it? If yes, the requirement isn’t necessary.
Verifiable Can one ensure that the requirement is met in the system? If not, the requirement should be removed or revised. Note: The verification method and level at which the requirement can be verified should be determined explicitly as part of the development for each of the requirements. (The verification level is the location in the system where the requirement is met (for example, the “system level,” the “segment level,” and the “subsystem level).1
Attainable Can the requirement be met in the system under development?
Unambiguous Can the requirement be interpreted in more than one way? If yes, the requirement should be clarified or removed. Ambiguous or poorly worded writing can lead to serious misunderstandings and needless rework. Note: Specifications should include a list of acronyms and a glossary of terms to improve clarity.
Complete Are all conditions under which the requirement applies stated? Also, does the specification document all known requirements? (Requirements are typically classified as functional, performance, interface, constraints, and environment.)
Consistent Can the requirement be met without conflicting with all other requirements? If not, the requirement should be revised or removed.
Traceable Is the origin (source) of the requirement known, and can the requirement be referenced (located) throughout the system? The automated requirements tool should enable finding the location in the system where each requirement is met.
Allocated Can the requirement be allocated to an element of the system design where it can be implemented? If not, the requirement needs to be revised or eliminated.2
Concise Is the requirement stated simply and clearly?
Implementation free The requirement should state what must be done without indicating how. The treatment of interface requirements is generally an exception.
Standard constructs Requirements are stated as imperative needs using “shall.” Statements indicating “goals” or using the word “will” are not imperatives.
Unique identifier Each requirement should have a unique identifying number that assists in identification, maintaining change history, and providing traceability.
  • Create the basic structure using SOLID and other design prinicples. Additionally since this project intended to be a resetful service initial URL endpoints shall be suggested and then refinded inline with changes to system structure.
  • From this create the tests from the verification sections when validating the requirements above.
  • Write test and implement using the RGR cycle
  • Write a failing test (Red)
  • Write the code so the test passes.
  • Re-factor your code, improve, document
    • Check Structure, remove complexity
    • Legibility – e.g Method Extraction
    • Check for Anti-patterns
    • Check for coupling
    • No local variables
    • Methods should not be more than 10 lines of code.
    • Where applicable use dependency injection
  • Cycles should not be longer than 5 minutes or ten lines of code.

KUP ASSESSMENT DEVELOPMENT

Posted on by Robert Worrall

Project Goal

A service that allows/ precipitates the creation and sharing of assessments of any kind from risk assessments to simple checklists. Assessments can scored using different schemes including secondary and primary contributory factors. These could then be assessed using Bayes theorem.

Initial Requirement List

  • Manage users
  • Users can create edit and amend own assessments
  • Users can create documentation for their assessments
  • Users can access documentation on how to create assessments.
  • Assessments can use a number of different scoring schemes.
  • Non users can use assessments and email/ print/ save results

Suspected Target Technologies

  • JAX-RS
  • MySQL
  • HTML5
  • JavaScript

Initial Use Case

Initial Use Diagram (PIC)

KUP Assessments

Posted on by Robert Worrall

It has been a while since I have posted anything. Work commitments have kept me distracted, however I have still managed to do some programming. I have started a new project titled “KUP Assessments”. For the next several posts I will outline the development process of the service.

The projects main goal is to allow users to create assessments that can be completed by other users. This assessments can be shared and not have to be recreated needlessly.

Refactoring Desktop Snowfall

Posted on by Robert Worrall

Using the refactoring checklist I will attempt to improve the design of  my Desktop Snowfall project

  • Can the code be Tested?  – The application is GUI based application with not a huge amount going on underneath.  Also some of this is subjective ie is the snow realistic? So it is impossible to test for. The current class diagram looks likes this:

  • Do you need a seam?
    • extract methods using protected not private that use the seam.
  • Create Tests

To create the tests I will need to extract the GUI from the other logic e.g generation of the snow. I started by creating an Environment package and an Environment interface that can store the environmental variables, screen size etc. This is then injected into the snowfall class. Additionally a factory pattern could be used for creating the items in the weather. Hence as weather factory interface could created and injected into the snowfall class. For future flexability objects that fall are defined by a Map held by the environment. Keys in the map are the class names of the objects and the int is the percentage occurrence in the environment.  Therefore the amount of objects created is still controlled by the user through the variable renamed from amountOfAnow to theAmountOfWeatherObjects.

I then created implementations and tests for them and I then integrated them into the design.

  • Start with the deepest branch to shortest branch – Refactored
  • Keep changes small and consistently retest. – Refactored
  • Remove complexity – Refactored
  • Methods should not have more than 10 lines of code – Refactored with a couple of instances where a method is 12 lines of code.
  • Replace conditionals with strategy pattern. – Refactored – achieved with introduction of weatherObjects, WeatherFactory and Enviroment interfaces.
  • Remove local variables – Refactored
  • Remove comments – use descriptive method names. – Refactored
  • Remove cryptic or clever code, – Refactored
  • Remove abbreviated code – Refactored
  • Refactor with dependency injection – Refactored used with implementing strategy pattern.
  • Refactor using SOLID
    • Single Responsibility Principle (SRP)
      • All classes now have singular responsibilities
    • Open Closed Design Principle
      • Up to this point I have amended, restructured the program to fit in with design principles. One I have completed this list. I will hold to this more strictly. Which begs the question. Should it have come first or last.
    • Liskov Substitution Principle (LSP)
      • implemented with the WeatherFactory, Environment, WeatherObject and Weather classes.
    • Interface Segregation Principle
      • At present the interfaces are basic and largly singular in purpose. e.g Environment interface only for retreiving details about the weather.
    • Dependency Inversion Principle
      • Achieved by making Environment, Weather and WeatherFactory dependent on abstractions.
  • Refactor using other design principles
    • Encapsulate what changes.
      • Reviewed – no further changes needed.
    • Don’t Repeat Yourself (DRY)
      • Reviewed. No further changes needed
    • Don’t look for things. Ask for things. (Dependency Injection)
      • Reviewed. No further changes needed.
    • Favor Composition over Inheritance
      • Reviewed. No further changes needed
    • Program to the Interface not to the Implementation
      • Reviewed. No further changes needed
    • Delegation Principles
      • Reviewed. No further changes needed

Now the structure of the program now looks like this:

I will update the source forge and the projects page in the coming days.

Refactoring – Other Design Principles – JobMan

Posted on by Robert Worrall

Encapsulate what changes

A factory pattern could be used to encapsulates job creation. The factory could be for each specific interface -e.g SpawnableJobs. The structure now takes the following form.

Don’t Repeat Yourself (DRY)

After applying the other principles – I cannot see any duplication of functionality at this time.

Don’t look for things. Ask for things. (Dependency Injection)

This is already achieved by the implantation of the factory method for creating Jobs. It is also done via injecting the numbering scheme at database creation.

Favor Composition over Inheritance

Composition has already been used for the implementation of SpawnableJob.

Program to the Interface not to the Implementation & Delegation Principles

This was covered when jobman was reviewed for Single Responsibility Prinicple and Interface Segregation Principle.

 

Conclusions

This was a useful exercise and will allow some of the work I did on JobMan to be reused in other projects. I will move the GUI code to a separate  repository which will be placed on the Sourceforge page and the projects page of this website.

Refactoring – Dependency Inversion Principle (DIP) Applied To JobMan

Posted on by Robert Worrall

Already in the previous posts I have moved the Database to an interface where JobDatabase interacts with abstract base classes of Job and SpawnableJob. Meaning that neither Databases are dependent of details of implementions of Job and SpawnableJob and conversely they are not dependent the JobDatabase class as this is declared through interfaces. So the resulting structure is now:

I also renamed the currently implemented JobDatabase to JobDataBaseDB4OEmbedded.

Refactoring – Liskov Substitution Principle (LSP) Applied to JobMan

Posted on by Robert Worrall

In the previous article I introduced 2 base classes Job and SpawnableJob. Their purpose was to forfill the closed open principle. However, as a side effect when all jobs are returned from the database spawnablejobs was also returned. This breaks the LSP as it is not intended that SpawnableJobs are substutable for Jobs and to do so would violate the single responsibility principle.

So to fix this. Spawnable will change so it has a filed of jobToBeReplicated  which will hold an instance of Job and will no longer inherit from Job.

Refactoring – Open Closed Principle applied to JobMan

Posted on by Robert Worrall

The MainJob and Replicator classes could turned to Abstract or I could introduce new base classes. I had previously deleted the Job class but this needs reinstating with MainJob extending Job. Then there could also be a replication base class that then extends the Job class functionality and introduces the functionality associated with spawning a Job. The base class in this instance could be referred to as SpawnableJob. I have chosen to introduce base classes mainly because I prefer the names of the base classes.

In future Job Classes could have further functionality added e.g a job with attached documents.

This would require minimum amendments to the JobDatabase class.

The class diagram now looks like this: