运行astah-pro.bat，这是windows下运行的。astah-run.sh是Linux下运行的。
类结构视图的作用是描述类模型和模型与模型之间的关系，也就是说我们在这要把这个一对多和多对多的关系理清楚。这个工具最强悍的地方是如果做完视图的话右键一点可以帮你上传表结构，再右键一点可以把你的类全部做好，再右键一点可以把DAO全部写好。
这里新建一个类是视图化的效果，其实和你在程序里面new一个类是一样的。
我们这里不描述方法是写什么的。我们这里只是描述实体类的结构。我们现在描述我们的实体类模型其实我们是不看方法的，你可以把方法删除掉。
Operation Compartment Visibility操作是否显示点击去掉钩。如果不想显示变量点击去掉Attribute Compartment Visibility属性是否显示就只剩下类名了。
这次项目从哪个开始画呢你得有个开始点吧。今天我们看所有的模型其实都是围绕一个核心：订单。一开始是先下订单，然后审订单，然后是为这个订单派人，然后这个订单派这个人去完成这个订单，到最后按照订单入库。整个都是围绕着订单来做。我们呢就造一个类这个类是订单类。
老师的实体类为了描述这个实体类后面会带一个后缀叫做Model。属性写中文英文都无所谓，OrderNum或者是订单号都可以。订单号其实你看大部分网站一般都是1234567890AB...Z，另一方面int会把0000000001转化成1，但是String就不会，所以int处理起来不太方便。
Staff是雇工，Employee是员工，所以员工的实体类的命名是EmpModel，把员工类的方法隐藏了。
但是这个箭头描述的他俩的关系主要是想说这个东西是从谁关联谁，那么你应该是先把关系理出来才能说谁对谁。Hibernate不是必须两边都有unique-key。它可以只配一边，就像你们都知道老师的名字叫做什么，但是老师不一定知道学生的名字叫做什么。
要是一开始不知道两个类的关系咋办，干脆别用箭头了，直接用一根线得了，反正他们俩有关系。一个订单归属一个员工，但是一个员工能下多个订单。
所以员工类和订单类是一对多的关系。
从订单类找员工类是靠creater，但是从员工类找订单类没有，就说明没有关系。所以这个时候你就知道了其实应该是右到左的箭头，就是由订单可以找员工，但是由员工找不着订单。
在企业开发中如果你一直做电商的开发电商这些名词你会很熟悉的。
申请时间createTime(时间点) 审核时间checkTime(时间点) 跟单时间completeTme(是个过程，有个开始时间有个结束时间)。最后一个审核时间其实就是跟单的开始时间，就是你审核完其实就开始跟单了。所以其实它未必非要记俩时间。这一次我们里面就不考虑它的跟单时间了，就是这俩字段不再做了。跟单完之后把东西拉回来，到家后入库，入库完来个时间。入库全部入完这个单子就真的结束了。endTime指的是整个订单的完成时间。
采购、销售、退货照样得有这些东西。
那采购单、销售单、销售退货单、采购退货单我是记在一个表里呢还是记在四个表里呢？如果它们大量的字段都相同，那就是一个表，如果有很多不一样的字段就分开。企业开发中我们一般使用多个表来记录是比较合理的。这次做在一张表里面，加大它的复杂度，万一你要是做一张表该怎么做？
orderType订单类型1234分别代表四种订单。
订单类别区分出来之后，这个订单刚下好一个申请单然后我再把它审核完。那么申请出现一条记录，审核完是出现一条全新的记录还是用的是同一条记录？如果是全新的记录有两条记录他俩订单号一样，那我咋区分呢？这一个订单号对了八条数据(2*4)就无法区分了，所以我们说应该是对一条记录。
如果是对一条记录靠什么区分呢？就是你现在是刚申请的还是审核的。状态！
还有很多很多其他的字段。比如说这个采购单要记录买什么东西，企业开发过程或者是日常生产一般是不会记录买哪家的东西。其实我们下订单的时候都是对一家企业下，并不是把所有的东西都记录上去。至于我这次采购可能分很多种东西那应该是在不同的单子里面。
totalNum你这个订单一共多少货，
checker也得关联员工表。那样就两根线重合了。一个表和另一张表多次关联。
这种东西在企业开发中是很常见的。
你不觉得你这个订单连个东西都没有吗？是不是得有商品？去超市买东西就是一个订单，那个小票就是订单。如果再在订单类上面加字段：商品名、数量、单价，不可能这样加吧，那这样我的一个订单类中得有无数个吧。你难道可以给我这个订单类表造个几千上万个新的东西吗？不行，我们得造一个全新的模型，专门用来描述订单里面的订单项。
订单项模型叫做OrderItemModel。所以加个订单明细模型OrderDetailModel。最起码里面有哪个商品买了多少个多少钱一个。所以得有个商品模型。
仓储系统中用Goods表示商品比较常见。
一个订单明细可以对一个订单商品，一个订单商品可以对多个订单明细。
OrderDetailModel必须通过gm连过去，不然你都不知道这个商品是什么？然后某个商品多少个是数量num:int,数量我们这里用int，其实不一定,在老师的原系统中,我们买的商品的单位是很特殊的，有可能它的单位是个，有可能是箱，有可能是公斤，所以有可能是吨、公斤这样的单位的话，那可能它就得是个小数了。但是咱们这次不整这种了，就是全部都是整数了。价格price与钱有关的单位一般不用Double，用的是String，String可以描述很长的精度，Double是有限的。一个字符串中能放多少个字符呢？String有一个方法可以访问字符串的长度，String返回字符串长度的方法，String的length()方法的返回值类型就是字符串中能放的字符总数。String的length()的方法的返回值类型是int，int的最大值是2147483647，负方向的最大值是2147483648。所以它里面能放的字符总数就是2147483647。这就是学完知识之后所反馈的信息，虽然老师没跟你说，但是你自己可以想得到。数组中有多少个元素？数组有长度，数组.length属性可以得到一个int类型的值，所以数组中的元素上限也是2147483647。一般银行做财务类的也是用String的。还有一个是BigDecimal是在Java中能够描述的最大的数值类型。它能描述的数值上限是很猛的，它能描述到1200多的阶乘，就是1200多阶乘的结果可以描述出来，这个也是企业中比较常用的。这次咱们用的是double，比较简单的，但是你得知道企业中比较常用的是String，拿出String再想做运算就转，再转就能用了。
合计用不用存储一下呢？不用，每次用都重新乘，万一存储的结果不是price*num就麻烦了，无法解释。这里面还有一个最核心的东西：订单项属于哪个订单你得描述一下吧。所以订单项所处的订单类别一定是订单model(OrderModel)。一个订单有多个订单项，一个订单项属于一个订单。所以他们俩之间得有关系，它们俩之间又得拉出一个关系了。
那有没有需求从订单OrderModel找回订单项OrderDetailModel呢？不知道，如果有需求你就写，没需求就到此结束。可以写可以不写，如果写的话就是增加一个odms:Set<OrderDetailModel>
它让你创建一个类型，我们用的这个视图里面它把这种东西不是当泛型用的，它当成全新的数据类型了。不用管它留着，我们只是为了描述关系而已。双向关系两边都写变量名，单向就不写了。
现在画的这些类图是为了描述它们之间的关系。商品还要有供应商。供应商得有名称、地址、电话等等。一个供应商得有多种货物，但是一种货物归属于一个供应商。还得加一级商品类别，否则供应商不好管理，一个供应商有成千上万种货物。为了让它好管理，所以我们再加一级商品类别。
一个商品类别对多个商品，一个商品对一个类别。那么究竟是从类别找商品多还是从商品找类别多？商品找类别比较多。还是我拿到商品想查一下它是什么类别这种需求比较多，我想看看这个类别有哪些商品这是按条件查询回头我们再说这种东西该怎么写。
一个供应商对多个类别，一个类别属于一个供应商。
一个供应商可以有多个订单，但是一个订单只对一个供应商。
大家会发现产生了一个闭合的圈子。有人会问回头我拿hibernate做的时候这个一个对象加一个对象或者一个对象里面挂一个对象到时候形成圈了不是死循环吗？到时候再解决这个问题，看看是不是能死循环在这儿。
如果没有类似的工具就这套模型得在你的脑子里面转多长时间？如果不画这种图后期你再理这些关系你是非常难理的。在企业开发中这些关系都会提前理清楚，理好之后会形成一张比较大的图。拿着这张图所有人都可以通过这张图看这个项目里面的层次关系，有什么用。当你想不明白的时候把这张图找出来就行了。到制图部一打印，在墙上一贴，好吧咱们这个项目的整体结构就这么多。你需要哪一块单独把这一块截出来去制图，这样的话你理的你的东西会非常容易理清关系。
还得有一个部门表吧。一个部门有多个员工，一个员工属于一个部门。这个线画的再漂亮现在都不行了，所以这个线一般是最后才去调整。
人和角色之间有关系吧，来个角色表。一个人有多个角色，一个角色对应多个人。
有种箭头可以描述这种多对多谁是主，谁是从。hibernate那里应该讲过主从概念，是为员工分角色的概率比较高，还是为角色分员工的概率比较高？大部分都是为员工指定角色。所以我们认为员工到角色的关系是主，员工是主，角色为从。以后管理都是由员工管理到角色，很少由角色管理到员工。所以这里由主指到从，由员工到角色，用员工去为他分配角色。
还有一个玩意：资源。资源和角色之间也有关系。是为资源分角色多还是为角色分资源多？为角色分资源的概率比较大。
这样就描述出来了一个多对多。我们还有很多模型没有画，例如：仓库。一个管理员对多个仓库，一个仓库对一个管理员。但是在老师的模型中是一个仓库也是多个管理员管。
有了仓库得有个仓库的货物明细，既然是仓库的货物明细，那就和货物玩到一起了吧。仓库的存储明细StoreDetailModel。哪个仓库哪个货物数量多少这是最基本的。一个仓库对多个仓库明细，一个明细属于一个仓库吧。一个货物对多条明细，一条明细对一种货物。
这才哪到哪儿啊，这在整个系统中连一块都算不上。如果老师画的这些东西在整个ERP系统中，如果它是单位1的话，那么一套ERP系统至少是它的三个数量级，1000倍，至少是它的1000倍，关系交叉的根本无法下手。
系统越做越大，如果不画图，光是在你的脑子里面转那就更死了。系统越做越大都是由小系统组成的。在原系统中采购、销售、采购退货、销售退货是四张表，那商品GoodsModel总共要连四张表。
这种图尽量不要交叉，调整成拐弯的。