Fork me on GitHub

Sections are specific to OfficeCompiler and are used to modularise the configuration of an application. Much like a business is broken down into sections with each section responsible for certain functions of the business, so does the Sections in OfficeFloor. The Section in OfficeFloor break down the configuration of an application with each Section responsible for certain functions of the application.

Sections focus on organising functionality

Jobs of the Job Based Architecture of OfficeFloor must be connected together to form the execution flows of the application. Jobs provide small discrete functions that rely on objects from the ManagedObjects to carry out the functionality of an application. They therefore, need to be connected with each other to create functional flows of the application and need to be connected with the ManagedObjects to support executing this functionality.

Managing the individual Jobs is much like managing the individual classes of an application. They are too small and detailed and must be grouped into components to allow better management. Components can then be grouped together into modules of an application. Naming conventions may have different names for each grouping but the idea is that smaller finer parts of the application can be grouped together to create larger courser parts. These groupings provide encapulsated parts of the application at differing levels of abstraction.

The differing levels of abstraction in grouping together parts of an application allow discussion and re-use at that level of abstraction without being caught up in the details. Typically when discussing how an application internally works developers and architects will use diagrams. Code is often too detailed and this is especially the case when trying to discuss it with non-technical individuals who are providing the business requirements for the application. Therefore, the application needs to be grouped at levels of abstraction that facilitates discussions at the appropriate levels of detail. Abstractions also provide developers simpler interfaces that allow them to focus on the functionality they are developing without being caught up in the details of other parts of the application.

Sections provide a hierarchical break down of application functionality. A Section may contain the following:

  • Tasks and how the Tasks are connected to each other
  • Inputs and outputs that allow Tasks to be linked to Tasks of other Sections. Inputs and outputs contribute to the interface of the Section.
  • ManagedObjects to allow Tasks to make use of them
  • External objects which allow ManagedObjects to be defined externally to the Section. External objects contribute to the interface of the Section.
  • Other Sections added as Sub-Sections that enables levels of abstraction. Sections can contain Sub-Sections, with those Sub-Sections containing their own Sub-Sections and so forth. This recursive hierachical grouping allows the levels of abstraction discussed above.

The Sections deliberately use only Work, Tasks and ManagedObjects as these are the Sources that developers use to provide the application functionality. The Administrators and Teams do not appear in Sections as they focus on technical aspects of the application that can be considered later at application assembly, once the application functionality is complete.

Working with the business

The configuring of Sections is typically through graphical editors within IDEs. The graphical nature of Sections allows a non-technical business individual to work with the developer and validate the functionality of the application. This is also another reason that the technical Administrators and Teams do not appear in Sections.

Having the business able to review the application as it is developed reduces costs. Getting the requirements right is a big focus of software development. It does not matter how well a system is built, if it meets the wrong requirements it is the wrong system. Getting business feedback is critical to ensure the accuracy of requirements and that the software is meeting those requirements. Many software methodologies even require people of the business to work closely with the development team to ensure the system is meeting the right requirements. This heavy focus on business feedback is necessary to ensure effort and subsequently cost is not wasted in achieving the wrong requirements.

The non-technical business individuals require a means to understand the system before they can review its accuracy. Typically developers will either demonstrate nearly completed functionality running or use diagrams to explain the functionality. Both of these incur additional cost to the development of an application, as:

  • running functionality that is wrong is effort spent developing wrong functionality, and
  • digrams to explain functionality require additional cost over and above the code and do not guarentee the application will end up adhering to the diagrams.

Having the Sections developed with graphical editors means that the business can provide feedback and there are no translations required into application functionality. As the business can review the diagrams the developer is putting together in the graphical editors, the developer can get immediate feedback on its accuracy. These diagrams also do not need to be carefully translated into application functionality as they themselves are compiled and executed by OfficeFloor. This means that the business can provide feedback on how the application actually works from the time the developer starts connecting Jobs together all the way through to application completion, giving the development team the necessary information to efficiently build correct applications.

Writing your own SectionSource implementation

Before writing your own implementation please have a quick check as there may be an implementation already existing that suits your requirements. This is especially the case as along with your SectionSource implementation you will likely be asked to provide a graphical editor for you implementation.

If however, you have found nothing that meets your requirements you can write your own implementation. The following table provides starting points for writing your own implementation.

Class Description
net.officefloor.compile.spi.section.source.SectionSource This is the interface that all SectionSource implementations must implement
net.officefloor.compile.spi.section.source.impl.AbstractSectionSource Provides abstract functionality to simplify implementing a SectionSource
net.officefloor.compile.test.section.SectionLoaderUtil Provides utility methods to test your SectionSource implementation
net.officefloor.compile.SectionSourceService Allows using the ServiceLoader functionality to provide additional meta-data about your SectionSource. Providing this is optional.
net.officefloor.model.impl.desk.DeskModelSectionSource Implementation that configures how Tasks are connected together. It gets its name from the idea that all Work must be done at a Desk. See the IDE for more details.
net.officefloor.model.impl.section.SectionModelSectionSource Implementation that allows connecting Desks and Sections together. It provides for the abstractions in organising the functionality of an application by allowing to arrange the Desks and Sections of an office. See the IDE for more details.

Please note that in writing you own implementation you are expected to provide a graphical editor to configure your implementation.