软件系统架构有感

现在架构给了我一个很直观的感受，那就是跟UML差不多。因为你架构就必须得把相应的静态图和动态图绘制出来，而你能够绘制出来就说明你对软件的需求，逻辑架构等有了很充分的了解和准备。所以在做作业之前，我又把有关UML的教材看了一遍，而且把Thinking in UML的UML核心试图那一章节也看了一遍。

架构给我的印象最深的一点是，通过架构，软件可以推倒出来，而不是coding出来。这其实也是我们软件工程师，而不是软件编码师，所应该着重学习的。在以前总不明白UML有什么用，因为自己在绘图的时候自搞一套，在编程的时候又换了一套。我把自己的这种错误的做法归根为自己面向对象的思想运用的不够完善。在绘图的时候较多地考虑了面向对象，而有的时候在编码的时候则过多的考虑了面向过程，而且在学习完数据库设计的时候，在考虑逻辑功能的时候，总是想到关系型数据库的设计问题，而数据库的设计和面向对象的设计根本不是一个路子的，因为两种方法的核心出发点就不同。面向对象设计是为了将各个对象的功能按照类的方法分开，是为了强调各个模块在功能逻辑上的分工，而数据库设计是为了数据的持久化，为了数据能够高效的存储和查询。所以自己在以前犯的错误很多，把很多思路和方法混合在一起，所以总是做不出好的架构，因而总是感觉软件的编写总是那么难。

首先说一下用例图。其实用例图就是需求嘛，关键是你得从哪些方面，哪些角度考虑这些需求，这其实就好比是软件的包图，你得分开描述，这样才更容易理解。大象书上说，要从业务，业务实现，概念，系统，系统实现这五个角度进行用例的挖掘和绘制，然而这样的角度对于我们的淘味儿网来说，要画全简直是太多了，而我考虑到有的用例大家都很熟悉，便没有进行进一步的细化，所以我们的用例图其实就是业务设计的用例图。我是从这个角度，分成五个场景进行绘制的，因为我主要考虑了业务模块。主要有游客，用户中心，用户交互，卖家管理，用户通信这五个角度。然后接下来的图我也是通过用用例图来驱动的方式绘制的。首先画了序列图，从以上四个场景中分别绘制了四个序列图，然后又通过rose的转换工具将序列图转换出了协作图。然后我又绘制了活动图，由于系统的功能比较复杂，所以我只绘制了用户下单时的活动图，因为这是系统最核心的功能。绘制完活动图之后，又简要的绘制了类图，大象书上说类图要从三个方面逐步深入的绘制，分别是概念层，说明层和实现层，实现层的绘制目前来说比较困难，因为我们的系统采用的是SSH的框架，而且我觉得应该更加注重数据库的设计，必要的时候可以牺牲一下面向对象的设计，因为网站数据量会比较大，对数据的查询和存取性能要求比较高，不能让数据库成为系统性能的瓶颈，而且采用了Hibernate的ORM框架，所以需要细细考虑一下数据库。所以我暂时只是画出了说明层的类图。之后的会再详细画出来。

以上只是一些小小的感受，我觉得针对于怎么想和想什么这两个角度，老师更应该强调怎么想，在逻辑架构各个部分的建模过程中，强调一下建模的各个阶段该怎么做，这样更容易使得我们放开思路。

由于昨天寝室停电，所以作业没能及时给老师发过去，忘老师理解。

淘味儿网