摘要： 首先要确定系统的功能和约束，也就是，它必须做什么以及在什么限制条件下工作，这样也就确定了问题空间。接下来我们要了解事实，重要问题和架构的关注点。确定工作流也是一个极为重要的步骤，来自于我们对于如何划分系统的考虑。 系统架构常见的关注点有，功能性：产品向特的用户提供哪些功能？可变性：软件将来可能需要哪 阅读全文

摘要： 企业中聚焦信息的架构展示了与Web一样的明确特点：伸缩性、弹性、架构迁移策略、信息驱动的访问控制等。Web服务的目标是要成为一种业务策略，形式，是在不影响客户的情况下升级这些系统。在大家的概念中，Web是以文档为中心的。具体来说，就是当大家想到Web时，就会想到在Web浏览器中看一些文档。但是Web 阅读全文

摘要： 软件系统就像一座城市一样，而架构就是对这座城市的规划，有了一个良好的规划城市的创建就会井然有序，最后的结果也会符合规律。 “混乱大都市”的构建是在向我们诉说一个糟糕的架构甚至没有架构会产生多么严重的后果。首先，它会让新进成员浪费很多时间在阅读代码上，因为没有架构，所以就缺少了设计文档或者文档一团糟。 阅读全文

摘要： 架构是一个过程，在这个过程中肯定会出现一些意想不到的问题，解决或者绕过了这些问题，就会出现一些好的目标产物。架构这个过程是架构师洞见系统内在结构、规律、原则和逻辑的过程。因为只有清晰的理解系统，才能简洁的描述它。 架构之美，Don't repeat yourself。在架构设计初期将一些关注点有意推 阅读全文

摘要： 用例要易于阅读，这就要求用例文档短小简明，那么这些要求会让我们达到这一目的:1.让问题短小。2.从头开始，用一条主线贯穿始终。3.用动词短语来给用例命名。4.用完整的主动语态句子来描述要完成的子目标。5.从触发事件开始一直继续，直到目标实现或者被取消，并且系统完成所有与这次事务处理有关的记录。6.确 阅读全文

摘要： 每个开发组都应该形成并制定一套工作习惯。在将大家集中在一起时，首先制定一份粗略的系统功能图，方便大家对于该系统形成一个统一的共识，制定详细的用例视图。 用例的来源庞杂时需要怎么办呢？首先在编写用例的这段时间中选择一个固定的地方，其次人员可能会很庞杂，但是我们要尽可能的在其中找对的人--真正的系统执行 阅读全文

摘要： 需要分清楚扩展和技术与数据的变化，扩展说明系统的目标有所改变，但是技术与数据的变化是过程肯能会有所不一样，但是最终目标是相同的。连接用例分为子用例和扩展用例两种。子用例就是在子用例名称上添加链接，点击名称可以撞到该用例的解释的地方。对于扩张用例不太懂，我认为就是在一个主线程中，可以调用其它的子线程。 阅读全文

摘要： 课堂讨论记录： 利益相关者描述： 利益相关者 特征 教师 教师使用系统制定考试信息，考试试题，并使用该系统查看学生的解答并进行评分，同时查看学生成绩。 学生 学生使用该系统下载试题，对试题进行解答并上传，以及查看自己成绩。 造纸厂、工人 利益消极相关者，该系统使考试不再使用纸张，影响了造纸厂的利益， 阅读全文

摘要： 用例书写，在一开始的时候不必太深入，这样既可以减少自己在书写用例上的精力，又可以给相关成员更多修改和深入思考的机会。还有如果一开始的用例是错误的会造成过多的精力浪费，不仅增加了工作量，更给心理上添加了负担。还有就是项目的范围，我感觉书中的方法很好。创建一个由三列组成的简单表格，左边一列是有关项目的主 阅读全文

摘要： 编写有效用例，首先要清楚用例是什么。用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约，描述了在不同条件下，系统对某一项目相关人员的请求所做出的响应。一个好的用例很容易阅读，但是要写出一个好的用例很不容易。而且用例不是要写的多正式、完整、漂亮，而是尽可能得充分，就足够了。还有在书写用例之前 阅读全文