Skip to content

Folder Structure of daisi and cpps #187

@janagoe

Description

@janagoe

Currently, the folder structure of daisi/src and daisi/src/cpps is a bit all over the place.

Application-neutral Folders

Some folders with "application-neutral" content such as the datastructure and material_flow are located in the daisi/src folder, because they could be used in many applications.

However, they are currently only used inside the cpps. Should they stay located in daisi/src, or be moved into the cpps?

Folders to be deleted

Inside the daisi/src/cpps, there are the to, agv, and negotiation folders which will be deleted with the big refactoring.

The top level message folder probably too, because messages got separately reimplemented inside the amr and logical folders.

Amr, Physical, MaterialFlow and Logical Agent Structure

Now there is some confusion with the amr and logical folders inside the cpps.

We currently have the AmrPhysicalAsset, AmrLogicalAgent, and MaterialFlowLogicalAgent as the main entities. AmrPhysicalAsset is in the amr folder, and AmrLogicalAgent and MaterialFlowLogicalAgent in logical.

I think this structure makes more sense than moving the AmrLogicalAgent to the amr folder, because there is a lot of communication happening between the AmrLogicalAgent and MaterialFlowLogicalAgent. Therefore, the logic can be nicely separated from the rest of the code with the algorithm_interface.h, which both of them depend on. Additionally, the implemented algorithms will be extended a lot in the future.

On the other hand, there is little communication between the AmrPhysicalAsset and the AmrLogicalAgent, which will be extended in the future. Therefore, I don't think there is a problem in keeping them separate.

The third option would be to create three folders, for each entity. But then the question is where to place the communication between the (AmrPhysicalAsset and the AmrLogicalAgent) and (AmrLogicalAgent and the MaterialFlowLogicalAgent)?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions