hbrs-maas / ws18-project-right-brothers Goto Github PK

@argenos

1. Is the design of the project already chosen? Since we did not have a class last wednesday for discussing and debating about the best design for creating agents and their conversations, we were wondering if the design has been finalised or not.
2. If it is not finalised, it does not seem possible to implement the skeleton code for the connectors of different stages (proofer, cooling racks, etc) and test it. If we implement agents based on our design, and unfortunately that design is not chosen then our agents will not be able to talk to agents created by other teams.

The names of the messages in the .md file and the pdf file do not match. Could you guys (@DRealArun
and @ZahidSE ) discuss among yourself and change one of the file accordingly.

The names of messages in .md file are in headings and the names of the messages in pdf file are in the bullet point message in and message out.

It should receive messages from order processor and send appropriate messages to mas-maas's proofer agent

• Make use of the upstream version of Start

• Remove the current Start file after switching

@argenos Currently the orders are in the clients.json. Wouldn't it make sense to have all orders in a seperate file (orders.json maybe)? They have a field called customerId anyway, which can be used to map an order to its corresponding customer.

• Make sure you can parse the sample scenario, found in config/sample, that is in the upstream remote (https://github.com/HBRS-MAAS/project/tree/master/src/main/resources/config/sample) and generate the required agents and objects
  • Test sending the customer order read from the sample file to the order processing agent.

• catch the messages thrown by cooling racks
• link with product objects

• Update your agent definitions. You should have the entire workflow modeled by now, including behaviors (and their type) and the messages exchanged by the agents (and their type).
• Don't forget to open a pull request with your order messages.
  • Your architecture should be uploaded both to LEA and the docs folder of your repository
  • The architecture should be considered documentation, i.e. while the diagram helps visualize, you should provide explanations as to why you took the decisions you took.
  • Add the agent/object which will manage the common time between your agents,
  • Describe how it (clock) will work.

• get loading bay interface agent and design packaging stage in detail similar to baking stage

Rough design outline

• Get messages thrown by cooling rack
• Apply steps in recipe to the products
• pack products based on orders
• send packed boxes of products to loading bay

• Currently half of the converter is in upstream. We need to move the whole to upstream and remove our version

• Add a visualization.md file with your proposal of what and how would you visualize the project, and which library or framework fits best your requirements. Upload it as a PDF to LEA.
  • This will be a shared agent between all teams in the course, therefore make a pull request to the upstream remote!

• get products with quantity from agent from #50
• apply post baking recipe steps (if any)

• Your team must upload your architecture and the agent definitions as discussed today, including the messages exchanged between agents. Keep in mind scalability! You may have thousands of any given property of the bakery, whether it be orders, ovens, trucks or customers. Make sure you are clear about which parts should be:
  • agents
    • is it created at runtime or at startup?
    • what behaviors does it have?
  • objects
• To which stage do these agents belong?
• Add the architecture diagram to your docs folder
• How do you plan to aggregate order data? Include a list of possible options, and which agent would take care of this.

• Update your agent definitions. You should have the entire workflow modeled by now, including behaviors (and their type) and the messages exchanged by the agents (and their type). Don't forget to open a pull request with your order messages.
  • Your architecture should be uploaded both to LEA and the docs folder of your repository
  • The architecture should be considered documentation, i.e. while the diagram helps visualize, you should provide explanations as to why you took the decisions you took.
  • Add the agent/object which will manage the common time between your agents, and describe how it will work.
• Make sure you can parse the sample scenario, found in config/sample, that is in the upstream remote (https://github.com/HBRS-MAAS/project/tree/master/src/main/resources/config/sample) and generate the required agents and objects
  • Test sending the customer order read from the sample file to the order processing agent.
• Add a visualization.md file with your proposal of what and how would you visualize the project, and which library or framework fits best your requirements. Upload it as a PDF to LEA.
  • This will be a shared agent between all teams in the course, therefore make a pull request to the upstream remote!
• Create the skeletons for all the agents in your workflow and set up basic communication between them based on your message definitions.
  • focus on the common agents that will serve as interfaces between the different stages (see the attached image for hints)
    • proofer
    • cooling racks
    • loading bay
    • mailbox

NOTES:

• Please keep your repositories up to date with the upstream remote (you should regularly check if there have been changes). Be careful when you merge and take a look at what the changes do. Open GitHub issues for any questions, problems or suggestions you're having.
• Use markdown formatting properly!
  

• get products with quantity from agent from #51
• match each product with the order (based on delivery date emergency)
• create box objects for individual products
• pack the order according to their priority

The upstream repo mentioned in the new homework is not possible to integrate with our team project repo. Our repos are not a fork of the upstream repo. In Last week's assignments as well, we had to copy and paste the messages.md file from one repo to another and then create a pull request.

Is there a way to solve this issue? @argenos

when running gradle run --args="-packaging" in develop branch, it produces an exception

***  Uncaught Exception for agent loader-agent  ***
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.maas.agents.LoadingBayAgent$PackagingPhaseMessageSender.findReceiver(LoadingBayAgent.java:186)
        at org.maas.agents.LoadingBayAgent$PackagingPhaseMessageSender.action(LoadingBayAgent.java:195)
        at jade.core.behaviours.Behaviour.actionWrapper(Behaviour.java:344)
        at jade.core.Agent$ActiveLifeCycle.execute(Agent.java:1585)
        at jade.core.Agent.run(Agent.java:1524)
        at java.base/java.lang.Thread.run(Thread.java:844)
loader-agent: Terminating.

Currently travis does not check the packaging stage as I have commented it out.

We need to discuss about our strategy to synchronize the file operations of the multiple agents when they try to write their status to the shared file (which will be used by the visualization agent). One direction to look into would be to add a status update behavior to all the agents which waits on a semaphore/mutex to update its most recent status to the file.

• Integrate with start.java
• read meta.json and start and end sim time correspondingly (denied by Argentina)
• (optional) start agents based on json files from time keeper (Not possible because the information about the number of agents and their type is not possible to know at the moment)

• Have a working JavaFX call from visualisation agent
• Change look of gui window based on visualization agent receiving a message
• Parse messages in visualization agent and only make changes to gui window when required
• make visualization agent intuitive, readable and modular
• (optional) make qui window pretty (possible animations)

Test your customer and processing agent in different computers.

• Create the skeletons for all the agents in your workflow and set up basic communication between them based on your message definitions.
  • focus on the common agents that will serve as interfaces between the different stages (see the attached image for hints)
    • proofer
    • cooling racks
    • loading bay
    • mailbox

Create the docs/messages.md file and add your proposal of how all your messages look like. Make a pull request to the HBRS-MAAS/project repository with your order message, we'll discuss them next week.

• Remove from gradle
• Remove related code if not being used

• BaseAgent
• Timekeeper
• Cooling rack

• Include order processor and customer along with baking stage in start.java
• Create a dummy proofer which accepts order messages from order processor
• Plug everything together and create pull request to upstream

• Integrate oven manager with cooling racks
• Integrate baking stage with timekeeper
• Actually bake products rather than instant baking
• Add 2 intermediate agents between baking and cooling
• Make a pull request to upstream with cooling racks agent

Your repository needs to contain the initial implementation of the customer and order processing agent, the bare minimum includes:

• The customer should be able to send orders to the bakery
• The bakery should be able to receive the order and confirm the reception.
• The order should be according to the convention mentioned in docs/messages.md.