Presentation is loading. Please wait.

Presentation is loading. Please wait.

Clever Framework Name That Doesn’t Violate Copyright Laws

Published byBudi Widjaja Modified over 6 years ago

Similar presentations

Presentation on theme: "Clever Framework Name That Doesn’t Violate Copyright Laws"— Presentation transcript:

1 Clever Framework Name That Doesn’t Violate Copyright Laws
March 27, 2015

2 Meeting Agenda Framework Overview Prototype 1 Design Goals
Prototype 1 Demo Prototype 2 Design Goals Timeline Moving Forward Questions & Answers Speaker: Lauren

3 Framework Overview Do we need this or should we go right into prototype 1? Would it make more sense to show this first? Should be discussion formatted – maybe present our current design, start dialog about changing the design

4 There’s a hurricane We have sensors monitoring conditions during the storm so we can get an idea of what is hit the hardest People need water, food, and medicine The city has shelters that people are going to for relief How does the city use its food banks, hospitals, weather information, and relief trucks to distribute resources to those shelters?

5 We connect these resources so that truck drivers know where to send food, food banks know when they will receive more inventory, and city leadership knows the status of these systems and can route according to weather and road conditions Finally the city is back on its feet and city managers want to look back at how decisions were made to modify emergency response protocols for future disasters. First we solved the immediate problem then learned from those decisions to help us in the future We will go into more detail about this diagram when we talk about prototypes

6 Shaping the Network Graph implementation should use the same concepts as graph design Business logic should be decoupled from connection logic When an edge goes across machines, this should be an implementation detail of the edge This computational graph abstraction applies to any level of the system The graph topology should be static wherever possible The graph topology needs to dynamically support new devices at runtime Bottom two points conflict – be sure to clarify what you mean here.

7 Is the temperature too high?
Processors Output Processor Input Sends Data Is the temperature too high? Receives Data Input Output Note: Rough Diagram Sketch Will likely have some more inputs and outputs coming in (imagine hospital and warehouse scaling diagram) Mention: "These are useful when, say, encapsulating a third-party sensor: when the component starts, use the proprietary sensor API to listen for events; when an event occurs, emit it on an output channel, perhaps after reformatting it in some way to be more useful to other components."

8 Static Subgraphs I have an idea of what to put here, but slightly unclear.

9

10

11

12 Pools

13 Burglar Alarm Pool Front Door Alarm Photo Proximity Data
Back Door Alarm Timestamp

14 Burglar Alarm Pool Front Door Alarm Photo Lobby Alarm Proximity Data
Back Door Alarm Timestamp

15 Speaker: Lauren or Weston

16 Feature Priority Dynamic Network Topology Framework Scalability
Large Scale Data Aggregation Historical Data Storage Robust Connections System Diagnostics UX/UI Should we include a definition of the feature being “complete?” This connects back to having a deliverable specs & reqs Message passing and adapters – P0 features that have been completed (work into list permanently)

17 Prototype 1 Design Goals and Demo

18 Essentially a reminder graphic for the prototype
Essentially a reminder graphic for the prototype. Should give basic story (hospitals have supplies, request new supplies from warehouse, helicopter finds people and sends info to hospitals), then go to goals slide (next)

19 Goals Framework Scalability Establish Infrastructure to Aggregate Data
Interaction with Cloud Services to store and produce data Establish Infrastructure to Aggregate Data Heterogeneous data, multiple inputs and outputs Dynamic Network Topology Introduce new components without reconfiguring Definitions: Framework Scalability  Arbitrarily complex graph of cloud and ground based devices The Cloud Service is Azure – store data in a cloud SQL server and produce data by spinning up component instances (or by random generation) Multiple inputs and outputs allowed by our Framework’s BLANK component Dynamic Network Topology – system robustness (pulling new components in if other fails, reconfiguring without taking system down, etc.) Question: Did we achieve goals beyond these listed?

20 Prototype 1 Demo

21 This is the final demo network

22 10 10 5 Ha - 5 Wa - 10 Hb - 10 Everyone starts connects their machine in the demo network, except Hb, Wb, and EB. Patient walks in with QR code, requiring 10 bandages. PM sends PatientInfo to Ha (Ha budget increases to 10) Ha uses 5 bandages via GUI (Ha inventory decreases to 0, budget decreases to 5) Ha sends RestockRequest to CM (requesting 5) CM sends Deliveryorder to Wa (requesting 5) and RequestConfirm to Ha Wa confirms delivery (Wa inventory decreases to 5) Ha confirms receipt (Ha inventory increases to 5)

23 10 10 5 -10 Ha - 5 Wa - 10 Hb - 10 Everyone starts connects their machine in the demo network, except Hb, Wb, and EB. Patient walks in with QR code, requiring 10 bandages. PM sends PatientInfo to Ha (Ha budget increases to 10) Ha uses 5 bandages via GUI (Ha inventory decreases to 0, budget decreases to 5) Ha sends RestockRequest to CM (requesting 5) CM sends Deliveryorder to Wa (requesting 5) and RequestConfirm to Ha Wa confirms delivery (Wa inventory decreases to 5) Ha confirms receipt (Ha inventory increases to 5)

24 10 10 -5 Ha - 5 Wa - 10 Hb - 10 Everyone starts connects their machine in the demo network, except Hb, Wb, and EB. Patient walks in with QR code, requiring 10 bandages. PM sends PatientInfo to Ha (Ha budget increases to 10) Ha uses 5 bandages via GUI (Ha inventory decreases to 0, budget decreases to 5) Ha sends RestockRequest to CM (requesting 5) CM sends Deliveryorder to Wa (requesting 5) and RequestConfirm to Ha Wa confirms delivery (Wa inventory decreases to 5) Ha confirms receipt (Ha inventory increases to 5)

25 10 5 5 -5 Ha - 5 Wa - 10 Hb - 10 Everyone starts connects their machine in the demo network, except Hb, Wb, and EB. Patient walks in with QR code, requiring 10 bandages. PM sends PatientInfo to Ha (Ha budget increases to 10) Ha uses 5 bandages via GUI (Ha inventory decreases to 0, budget decreases to 5) Ha sends RestockRequest to CM (requesting 5) CM sends Deliveryorder to Wa (requesting 5) and RequestConfirm to Ha Wa confirms delivery (Wa inventory decreases to 5) Ha confirms receipt (Ha inventory increases to 5)

26 10 5 5 5 -5 Ha - 5 Wa - 10 Hb - 10 Everyone starts connects their machine in the demo network, except Hb, Wb, and EB. Patient walks in with QR code, requiring 10 bandages. PM sends PatientInfo to Ha (Ha budget increases to 10) Ha uses 5 bandages via GUI (Ha inventory decreases to 0, budget decreases to 5) Ha sends RestockRequest to CM (requesting 5) CM sends Deliveryorder to Wa (requesting 5) and RequestConfirm to Ha Wa confirms delivery (Wa inventory decreases to 5) Ha confirms receipt (Ha inventory increases to 5)

27 10 5 5 Ha - 5 Wa - 10 Hb - 10 Everyone starts connects their machine in the demo network, except Hb, Wb, and EB. Patient walks in with QR code, requiring 10 bandages. PM sends PatientInfo to Ha (Ha budget increases to 10) Ha uses 5 bandages via GUI (Ha inventory decreases to 0, budget decreases to 5) Ha sends RestockRequest to CM (requesting 5) CM sends Deliveryorder to Wa (requesting 5) and RequestConfirm to Ha Wa confirms delivery (Wa inventory decreases to 5) Ha confirms receipt (Ha inventory increases to 5)

28 10 5 Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture -20

29 10 5 Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture -20

30 5 Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture -10

31 Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture -5

32 Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture -5

33 Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture 10 -5

34 Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture 5

35 Prototype 2 Design Goals

36 Goals Complete Large Scale Data Aggregation Robust Connections
Synthesize different types of inputs into one or more different types of outputs Increase the amount of data flow Robust Connections Demonstrate transmission failure recovery and unintentional disconnection recovery Network components directly related can tell when a device disconnects System Diagnostics Expand status logging of components, demonstrate logging capabilities of Framework UX/UI Ability to view actions while running the application Historical Data Storage is also on here, but I think that deserves a mention as an in progress item and doesn’t need a bullet point. System Diagnostics – Logger already created, we just need to fine tune what is being logged and find a way to display it in the application (to show it works)

37 We will introduce a new component (because we want to introduce more types of data -- hetereogeneous) a traffic reporter. This will relay traffic/road information to the central manager who uses this new information to estimate the time it will take for a warehouse to deliver resources. This will help address the Large Scale Data Aggregation by introducing new types of data that affect the central manager's decision of which warehouse toship the resources from. The central manager can begin to predict resource usage of each hospital, using historical usage data. The central manager will have a user interface for resource management personnel to take manual control over the manager's decisions. (Addressing the UX/UI feature)

38 Updated Timeline Yellow: Will demonstrate progress
Green: Will be complete by 4/10

Download ppt "Clever Framework Name That Doesn’t Violate Copyright Laws"

Similar presentations

Paul Chu FRIB Controls Group Leader (Acting) Service-Oriented Architecture for High-level Applications.

Paul Chu FRIB Controls Group Leader (Acting) Service-Oriented Architecture for High-level Applications.
16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.

16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.
Data Communications and Networks

Data Communications and Networks
COMP 410 Update!. The Problems Story Time! Describe the Hurricane Problem Do this with pictures, lots of people, a hurricane, trucks, medicine all disconnected.

COMP 410 Update!. The Problems Story Time! Describe the Hurricane Problem Do this with pictures, lots of people, a hurricane, trucks, medicine all disconnected.
Institute of Computer and Communication Network Engineering OFC/NFOEC, 6-10 March 2011, Los Angeles, CA Lessons Learned From Implementing a Path Computation.

Institute of Computer and Communication Network Engineering OFC/NFOEC, 6-10 March 2011, Los Angeles, CA Lessons Learned From Implementing a Path Computation.
MARCH 27, 2015. Meeting Agenda  Prototype 1 Design Goals  Prototype 1 Demo  Framework Overview  Prototype 2 Design Goals  Timeline Moving Forward.

MARCH 27, Meeting Agenda  Prototype 1 Design Goals  Prototype 1 Demo  Framework Overview  Prototype 2 Design Goals  Timeline Moving Forward.
COMP 410 FINAL PRESENTATION. Agenda  Introduction of the Problem  Overview of NetFlow  Demo of Applications Built on NetFlow  The COMP 410 Experience.

COMP 410 FINAL PRESENTATION. Agenda  Introduction of the Problem  Overview of NetFlow  Demo of Applications Built on NetFlow  The COMP 410 Experience.
COMP 410 Update. The Problems Story Time! Describe the Hurricane Problem Do this with pictures, lots of people, a hurricane, trucks, medicine all disconnected.

COMP 410 Update. The Problems Story Time! Describe the Hurricane Problem Do this with pictures, lots of people, a hurricane, trucks, medicine all disconnected.
Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila.

Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila.
Unit – I CLIENT / SERVER ARCHITECTURE. Unit Structure  Evolution of Client/Server Architecture  Client/Server Model  Characteristics of Client/Server.

Unit – I CLIENT / SERVER ARCHITECTURE. Unit Structure  Evolution of Client/Server Architecture  Client/Server Model  Characteristics of Client/Server.
Clever Framework Name That Doesn’t Violate Copyright Laws MARCH 27, 2015.

Clever Framework Name That Doesn’t Violate Copyright Laws MARCH 27, 2015.
Introduction to dCache Zhenping (Jane) Liu ATLAS Computing Facility, Physics Department Brookhaven National Lab 09/12 – 09/13, 2005 USATLAS Tier-1 & Tier-2.

Introduction to dCache Zhenping (Jane) Liu ATLAS Computing Facility, Physics Department Brookhaven National Lab 09/12 – 09/13, 2005 USATLAS Tier-1 & Tier-2.
9 Systems Analysis and Design in a Changing World, Fourth Edition.

9 Systems Analysis and Design in a Changing World, Fourth Edition.
9 Systems Analysis and Design in a Changing World, Fourth Edition.

9 Systems Analysis and Design in a Changing World, Fourth Edition.
What is SAM-Grid? Job Handling Data Handling Monitoring and Information.

What is SAM-Grid? Job Handling Data Handling Monitoring and Information.
SDN AND OPENFLOW SPECIFICATION SPEAKER: HSUAN-LING WENG DATE: 2014/11/18.

SDN AND OPENFLOW SPECIFICATION SPEAKER: HSUAN-LING WENG DATE: 2014/11/18.
VMware vSphere Configuration and Management v6

VMware vSphere Configuration and Management v6
© 2013, published by Flat World Knowledge Chapter 10 Understanding Software: A Primer for Managers 10-1.

© 2013, published by Flat World Knowledge Chapter 10 Understanding Software: A Primer for Managers 10-1.
Computer Simulation of Networks ECE/CSC 777: Telecommunications Network Design Fall, 2013, Rudra Dutta.

Computer Simulation of Networks ECE/CSC 777: Telecommunications Network Design Fall, 2013, Rudra Dutta.
Clever Framework Name MARCH 27, 2015. Meeting Agenda  Framework Overview  Prototype 1 Design Goals  Prototype 1 Demo  Prototype 2 Design Goals  Timeline.

Clever Framework Name MARCH 27, Meeting Agenda  Framework Overview  Prototype 1 Design Goals  Prototype 1 Demo  Prototype 2 Design Goals  Timeline.

Similar presentations

Ads by Google