2012年11月
阅读《MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS》和《No Silver Bullet: Essence and Accidents of Software Engineering》的感想
摘要： 团队项目开发也进行了两周了，多少有些感想了，对于找“银弹”这个问题，还是计较赞同《No Silver Bullet: Essence and Accidents of Software Engineering》里的看法的，软件项目的复杂度增加真不是线性增加的，在我所在的团队里，是做网站的搜索部分和上传下载部分，比如我开始分配任务给各个组员的时候，每个任务都是很小的一部分，估计一天两天就能搞定的，但因为是分开几个小组一起做一个大的问答网站，各个小组都会随着自己的需求更改接口，或对别的小组提出别的要求，这样就面临了《No Silver Bullet: Essence and Accidents . 阅读全文
posted @ 2012-11-11 17:07 李忠 阅读(340) 评论(0) 推荐(0) 编辑
《MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS》总结
摘要： 这篇文章主要是介绍了“瀑布模型”。作者总结了自己在软件开发中的经验，提出了一个软件项目的开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈。他给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用，这也许就是我们后来人称之为“瀑布模型”的原因吧。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 每个阶. 阅读全文
posted @ 2012-11-11 16:41 李忠 阅读(429) 评论(0) 推荐(0) 编辑
《No Silver Bullet: Essence and Accidents of Software Engineering》总结
摘要： 这篇文章首先是介绍了软件工程要面临的固有的不可避免的问题，主要是复杂性（complexity），软件整合（conformity），可变性（changeability）和不可见性（invisibility）。下面是对文章里这些问题观点的整理：（1）复杂性（complexity）。软件要增加规模不仅仅是简单地增加相同内容的规模，还要增加新的内容，这就使得随着软件规模的增加其复杂度的增加是非线性的，整体复杂性的增加可能比线性增加要大得多。软件的复杂性的这个特征给软件的开发带来了不少的困难，它会给软件项目组里的组员之间交流带来困难，从而导致产品的瑕疵、开支过多和时间耽搁；这样的复杂性给我们穷举所有软. 阅读全文
posted @ 2012-11-11 15:54 李忠 阅读(912) 评论(0) 推荐(0) 编辑
2012年10月
读《移山之道》的疑问
摘要： （1）MSF团队模型中提出了“在对立中寻找共同利益，在冲突中达到平衡”，我觉得这是一个模糊不清的句子，没有根据具体的例子来说明这个问题，很多老师都喜欢说这句套话，然后学生还是不会怎么做。也许是我的开发团队项目的经验还不够吧，希望经过这次软工大作业能对这个有一些理解；（2）团队角色的划分有了，一个角色能有很多的组员构成，那么角色内部组员任务的划分该如何进行？毕竟每个人的水平是不同的，各有所长，比如项目开发组里，有些人可能算法设计能力强，有些人就不适合做算法研究，我们要如何充分调动这些资源；（3）《移山之道》里面讲到了很多的测试方法，很具体，并且讲到了测试用例的分类，我要提的问题是我们该如何设计测 阅读全文
posted @ 2012-10-30 22:33 李忠 阅读(192) 评论(1) 推荐(0) 编辑
我们的电梯调度算法的独到之处
摘要： 我们的算法里，定义了_PassengerQueue专门用于存储乘客发出的方向请求，还定义了一个ArrayList数组_targetOfElev用于存储每个电梯的目标楼层。把每个楼层里发出的方向请求相同的那些请求只存储一个，因为一个乘客如果进入不了一个电梯里的话，那么他就会再发出一次方向请求，这样又会对这个方向请求进行赋值，这样，只要还没有完成将所有的乘客都送到他们要到的楼层，那么_PassengerQueue这个队列就不是空的，那么，电梯调度算法就会继续去完成它。当有乘客进入一个电梯时，就会发出一个目标请求，我们算法里就把这个目标请求加入到数组数组_targetOfElev里该电梯对应的Arr 阅读全文
posted @ 2012-10-22 01:13 李忠 阅读(232) 评论(0) 推荐(0) 编辑
Design by Contract, Code Contract的优缺点
摘要： 契约式编程对于软件工程是一个极大的理论改革，对于C/S模式造成了极大的影响和冲击。对于C/S模式，我们看待两个模块的地位是不平等的，我们往往要求server非常强大，可以处理一切可能的异常，而对client不闻不问，造成了client代码的低劣。而在DbC中，使用者和被调用者地位平等，双方必须彼此履行义务，才可以行驶权利。调用者必须提供正确的参数，被调用者必须保证正确的结果和调用者要求的不变性。双方都有必须履行的义务，也有使用的权利，这样就保证了双方代码的质量，提高了软件工程的效率和质量。缺点是对于程序语言有一定的要求，契约式编程需要一种机制来验证契约的成立与否。而断言显然是最好的选择，但是并 阅读全文
posted @ 2012-10-22 00:27 李忠 阅读(1013) 评论(0) 推荐(1) 编辑
Information Hiding, interface design, loose coupling的利用
摘要： 信息隐藏：首先，在类中，定义的变量和方法可以再前面加上一个下划线"_"来标识，这是一个好的命名规范，可以避免无意中对私有成员进行赋值。类与类之间交换信息时，要交流私有变量时，要用事先设计好的方法来访问，这样如果我们在其它类里面调用另外一个类的私有变量，那么我们必须定义一个获得该类私有变量的方法；要在另一个类里面改变另外一个类里面的变量时，我们也要定义一个改变该类私有变量的方法。在C#里特别方便的一点就是有set和get，我们可以很方便的定义访问一个类私有变量的方法。接口设计：一个好的接口能够提供给后面的程序设计一个良好的框架，在这次电梯调度项目里，接口IElevator、I 阅读全文
posted @ 2012-10-21 23:59 李忠 阅读(227) 评论(0) 推荐(0) 编辑
电梯调度类图
摘要： 阅读全文
posted @ 2012-10-21 23:06 李忠 阅读(603) 评论(0) 推荐(0) 编辑
结对编程的合作情况，以及结对编程的优缺点
摘要： 我们合作的过程照结对编程的优缺点：（1）首先应该是结对编程的高效率了，结对编程的时候，两个人可以分开做不同的unit，也可以同时做相同的unit。在项目的一些简单的unit，一个人能够很简单的unit就可以分给不同的人去做；对于核心的unit，比如说此次项目电梯调度的算法部分，这是一个核心的部分，需要我们共同讨论，经过讨论后再去实现，或者两个人分别写出自己的想法，用代码实现，这时候，综合两个人效率高的那个人的算法。另外，在结对编程时候，有一定相互监督作用，比起一个写程序，更不会想去玩一些其它的东西。（2）想法源于两个人的激烈讨论，很多时候，我们在讨论中，常常忽然就会有一个灵感突然来袭，或者是会 阅读全文
posted @ 2012-10-21 22:34 李忠 阅读(680) 评论(0) 推荐(0) 编辑
结对编程成员的组成
摘要： 我和谢伯炎同学一组，我们为pairwork18，即第18组 阅读全文
posted @ 2012-10-21 21:55 李忠 阅读(140) 评论(0) 推荐(0) 编辑