Risk Modeling Framework, an MVC approach
The Model View Controller (MVC) is a popular paradigm for building dynamic web applications. The main advantages of MVC are loose coupling and seperation of concerns. In this article I would argue that MVC is also ideal for building a cloud/web risk modelling framework with R/Python/C++.
MVC can be best explained through the concept of Lego1:
Request. It starts with a request to build something. Let’s say your brother wants you to build a spaceshuttle.
Controller. After the request comes in then the controller (modeller) is responsible for grabbing the objects and organizing them.
Models. The building blocks are known as models, and they come in different shapes and colors.
View. After retrieving and organizing the necessary items, the end product can be produced and shown to the requester.
Translating the above into a web/cloud risk modelling framework with R/Python/C++:
Request. The framework should handle incoming http requests that interact with the computation backend (R/Python/C++).
Conroller. This is the heart of the framework, where the risk modeler is going to grab the objects (models) an organize them. The best way to facilitate this process is through a visual workflow designer, which has two main functionalities:
Grabbing: a drag and drop facility, where each dropped object represents a node.
Organizing: a connecting facility, which connects the nodes as an execution workflow
- Models. The models, or the building blocks/nodes, come in different categories. The main categories are:
a. Data models, usually representing the input data definitions.
b. Task models, the (R/Python/C++) functions that execute a specific task: a stochastic simulation, a data transformation, a risk measure computation. Ideally these task models should be incorporated as a web service.
c. View state, the state in which a specific node should be exposed to the users. For instance, the output of a stochastic simulation node might be exposed as a graph (histogram), or a specific input data item as an editable datagrid
- View. This area is the front end of the risk model, where the end user can run the execution process, view the intermediate/end results and interact dynamically with the risk model. Designing the view is mainly about layouting the view-states as defined in the controller.
In the next blog post I will showcase a simple example of an MVC risk framework implemented in R OpenCpu.