炫律 - 博客园

2013年1月9日

摘要：设计：1.使用2个listbox，作为展示楼层情况和电梯的运行情况，作为左右2个部分2.左边，根据XML文件中的电梯的最高楼层N，设置N个竖直方向的listbox，右边根据电梯架数M设定M个横向排列的listbox代表电梯3.每个listbox中嵌套的listbox中存储乘客的信息把程序每秒的结果都存储起来，这样可以通过滚动条来拉动到达不同的秒处。在UI上展示每秒的运行结果。实现工具：WPF程序架构：运行截图：心得：用简洁界面，实现功能才是最厉害的,有一个好的方法可以简单好多的完成程序。有一个会的人教，基本能很快的完成项目。阅读全文

posted @ 2013-01-09 21:28 炫律阅读(213) 评论(0) 推荐(0) 编辑

软件工程课程总结

摘要：软件工程课作为我这学期最后完结的一门课，结束后我感觉身上有种如释重负的感觉。在最后的这段时间里，我感觉特别的疲惫，各个科目各自的考试和大作业，都一齐如期而至。在最后的一个多月里每天最少忙到一两点才上床睡觉，元旦附近更是差不多有一周的时间3-4点过后才能睡觉。有好多同学身体都吃不消，感冒、拉肚子的都出现了好几个。我们小组就有一个，这个时候我们每个人身上的担子就更重了。在经历了那么久的辛苦学习后,现在终于可以闲下来对开学以来自己所学到的东西做一次总结了，做一次深刻的总结。下面是我对软件工程课从开始到结束的回顾与总结。刚开始时，我们听说这次的软件工程课与以往有所不同，是微软的老师来给我... 阅读全文

posted @ 2013-01-09 09:27 炫律阅读(248) 评论(1) 推荐(0) 编辑

2012年12月28日

必应缤纷桌面

摘要：下面是针对必应缤纷桌面软件的测试和用户调查第一部分Bug1.在bing新闻查看新闻的时候，点击标题不能进入它所显示的对应的文章，而是进入一个搜索界面。一般用户查看到描述之后，感兴趣的是提供描述的文章。Bug2.在缤纷桌面更换背景的时候，用户如果网速较慢，图片没有加载完，桌面图片会出现大量马赛克，而且不会再继续加载Bug3.在缤纷桌面更换过桌面后，如果用户取消采用缤纷桌面的时候，那么不能返回到用户采用缤纷桌面之前的桌面。Bug4.不提供卸载功能，在开始菜单中找不到，如果没有安装包，用户卸载就十分不方便了。第二部分采访者：北京航空航天大学2010级学生，计算机专业，男，业余时间大部分都花在电脑跟阅读全文

posted @ 2012-12-28 16:00 炫律阅读(462) 评论(0) 推荐(0) 编辑

2012年11月14日

《No Silver Bullet》读后感

摘要：没有银弹这篇文章讲述了束缚软件工程的几个重要问题：1、复杂性：软件增加新的内容，其复杂度的增加是非线性的，整体复杂性的增加可能比线性增加要大得多。随着软件功能的增加，显然可靠性是会下降的，接着还会面临一系列的难题。2、软件整合：人不是上帝，不可能像上帝创造世界那样完成所有的工作，软件是由不同的人写出来的，所以软件的整合成了一个很大的问题。3、可变性：因为软件是给客户做的，一旦客户要求变化，那么软件就要跟着变化，所以，开发的软件是随时可变的。就像们的第一次编程作业，因为之前的题目定义不明确，我们中途修改过题目，这就像是用户的需求在变。4、不可见性：软件不像建筑那样是可见的，也没有空间性，虽然数据阅读全文

posted @ 2012-11-14 00:07 炫律阅读(478) 评论(0) 推荐(0) 编辑

《MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS》感想和团队项目中的应用

摘要：在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。我感觉我们的团队项目中就用到了较多的瀑布型，但不全是，有些时候我们会遇到工作中的某些模块比较难处理，那么我们可能会暂时放一放，做下一个阶段的任务，有了头绪之后再回过头来做一遍。但是我们的开发过程是按顺序先走一遍的，类似于瀑布模型。瀑布型的各个阶段：1、定义期（1）问题的定义（2）可行性分析（3）需求分析2、开发期（1）系统设计（2）详细设计（3）编程调试（... 阅读全文

posted @ 2012-11-14 00:06 炫律阅读(219) 评论(0) 推荐(0) 编辑

《big ball of mud》感想

摘要：大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。这使得系统内的信息无法得到更好的控制和共享，使得信息失去了应有的价值。大泥球复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。产生：首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者编程的要求是在不断地变化的，任何一个已有的系统都随之会产生重大的变化，使得系统越来越复杂化，维护也越来越昂贵，另外编写人员的变动等等因素都会. 阅读全文

posted @ 2012-11-14 00:06 炫律阅读(348) 评论(0) 推荐(0) 编辑

《The Cathedral and the Bazaar》读后感

摘要：在阅读了《The Cathedral and the Bazaar》的介绍后，大教堂和集市的软件发展模式：大教堂的模型：在大教堂模式中，每一个版本的源代码都是可以被用到的，但是在不同版本间的已经开发好的代码被限制在一个专有的软件开发团队中。集市的模式：在集市模式中，代码的开发是通过互联网以大众的视角来开发的。我们团队用的开发模式是集市模式，代码是放在TFS上供大家一同开发的，而不是一个版本一个版本的开发。如果不断的限定版本号，每个版本都有一个团队来负责，这是我们不需要的，我们要做的只有一个版本，接着在上面不断的修改完善。原文链接：http://en.wikipedia.org/wiki.. 阅读全文

posted @ 2012-11-14 00:05 炫律阅读(297) 评论(0) 推荐(0) 编辑

《Lost in CatB.》读后感

摘要：在读了这篇文章过后，对我的原来的各种理解完全是种“颠覆”。过去我所了解到的Linux/Unix是开源的极好的系统.因为他的开源，所以其中的BUG很容易被人发现，因为他的开源，他们安全性是有所保证的。再同时他是一个精细的，简练的系统。但是，这里却说集市开发毁掉了Unix，表示说需要有人对版本负责，难道这是Linux成功的原因？因为对文章中说的一系列背景丝毫不了解，我也不能提出反驳的理由，所以，这个需要有人对版本负责，这个是一个新的声音。对我来说是个新的认识。原文链接：http://www.ituring.com.cn/article/9363 阅读全文

posted @ 2012-11-14 00:05 炫律阅读(160) 评论(0) 推荐(0) 编辑

《Agile Method – by Martin Fowler》敏捷开发感想

摘要：敏捷开发听上去就很能理解其特点，感觉上是一种不同于平常的软件开发方法。下面是具体的敏捷开发特点：敏捷型方法是“适应性”而非“预见性”。工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在一般情况下工作良好，但（需求、环境等）有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法则阅读全文

posted @ 2012-11-14 00:04 炫律阅读(329) 评论(0) 推荐(0) 编辑

2012年10月29日

《CODE COMPLETE 2》读后感

摘要：在读了《代码大全2》后的第一感觉是它不愧是软件工程类教材中的经典。具体的有以下几个原因：1、他不局限于某种具体的软件开发，或在某种具体的环境下开发，是软件工程的通用教材。2、书中内容的全面程度让你难以想象，几乎在软件工程中遇到的问题书中都有提及。3、问题的解决方法很详细，提出、发现问题后大多数问题都给了不止一种的解决方法。4、从基础到高端，书中的内容有显而易懂的基础，也有到工程才会遇到的问题。所以很适合读者一步步提高自己。在读《代码大全》的同时我还参考了《移山之道》，对于我们现在所处的软件工程课，《移山之道》的VSTS开发很贴切，具体的对VS2012的操作相当有用。《代码大全》全书... 阅读全文

posted @ 2012-10-29 15:07 炫律阅读(505) 评论(1) 推荐(0) 编辑

炫律

公告