在wiki.opendaylight.org中很容易搜到yang-java mapping的页面，在此不再敖述。
Tips:仔细观察yang模型与生成的代码不难发现，本例中的list都是具有
interface的java文件，而leaf则没有，yang模型生成的代码多很容易混乱，实际编程体会一下就会清晰好多。
找到生成的代码以后剩下就可以通过IDE一路追踪到具体实现，随便找到其中getTrunk方法，ctrl+Alt+H(eclipse)就可以找到它的层级结构，跳转到相应的java文件继续阅读代码。
以上就是YANG模型与南向接口的关系，与其说是代码分析不如说是如何针对YANG模型来分析OpenDaylight代码的方法。
总结
在不同项目中，相应的南北向接口可能不同，这主要依据实际情况而定，拿openflow协议来讲，它是具有南向北向两套YANG模型的，这主要是因为
OpenFlow协议复杂冗长，不适合直接以这种数据格式提供给北向接口，而要是以北向接口为准简化南向接口中诸如“length”这样的字段也很难使接口简单有效，所以对于openflow协议来说是有openflowjava（openflow 南向接口）和openflowplugin（北向接口）两个工程，分别定义了南北接口，当然，这其中肯定是有环节将南向北向接口数据进行对接。
另一个例子bgp，由于bgp协议数据结构相对简单很多，在这个工程中只有一套YANG，对应于北向接口，而南向接口中诸如”length“这样的字段就可以直接用本地变量来存储。
所以YANG模型的定义可以针对具体情况具体分析，而在使用的过程中，只要先掌握基本的语法规则，对于其他不常用的语法规则现查现用即可。
operational是ODL设计的另一个data store了，device就是网元，这个我认为跟NETCONF的三个data store有关系。