基于NET的需求分析和解决方案设计02.docx
《基于NET的需求分析和解决方案设计02.docx》由会员分享，可在线阅读，更多相关《基于NET的需求分析和解决方案设计02.docx（37页珍藏版）》请在冰豆网上搜索。
基于NET的需求分析和解决方案设计02
第2章收集和分析信息
本章概述
收集、分析信息始终贯穿整个Microsoft®解决方案框架（MSF）过程模型。
本章将阐述如何收集和分析信息。
你将学习所需收集信息的类型、来源和一些收集信息的方法。
只有将本章节的内容学习透彻了，才可能对后面的课程继续进行学习。
教学目标
●描述收集信息的技术
●描述信息收集的来源
●创建信息收集的策略
●通过使用场景和用例来分析、完善需求
●创建内部项目文档
●描述建模表示法，比如UML和ORM
教学重点
●UML图是一种常用的建模的方法，了解UML对于学习本书尤为重要
教学难点
●了解UML和ORM是需要一些企业经验和实际开发经验后才能抽象理解的，而学生往往缺乏的就是实战经验，本章节的讲解需要教师多加入一些直观的案例
教学资源
课本
知识点
2.1使用建模表示法
2.2创建用例和使用场景
2.3收集信息
2.4分析信息
习题
习题1-对应知识点使用建模表示法（2.1）
习题2-对应知识点创建用例和使用场景（2.2）
习题3-对应知识点创建用例和使用场景（2.2）
习题4-对应知识点收集信息（2.3）
习题5-对应知识点分析信息（2.4）
教师光盘
幻灯片
教师光盘：
\Powerpnt\2710B_02.ppt
多媒体视频
教师光盘：
\Powerpnt\
习题解答
教师光盘：
\tPrep\answer
先修知识
在正式开始学习本章内容以前，学生须具备下列知识基础。
先修知识
推荐补充
了解Windows程序设计的基础知识。
《基于VB.NET的Windows程序设计》
了解WEB类程序设计的知识。
《面向.NET的Web应用程序设计》
连接XMLWebService开发的知识。
《XMLWebService开发》
建议学时
课堂教学（2课时）
教学过程
2.1使用建模表示法
教学提示：
使用建模表示法部分主要达到两个目的。
●描述统一建模语言（UML，UnifiedModelingLanguage）在概念设计中的作用。
（略讲）
●描述对象角色建模（ORM，ObjectRoleModeling）在概念设计中的作用。
（略讲）
教学内容
教学活动
教学提示
讲授：
建立系统模型的过程。
又称模型化。
建模是研究系统的重要手段和前提。
凡是用模型描述系统的因果关系或相互关系的过程都属于建模。
系统建模主要用于3个方面：
① 分析和设计实际系统。
②预测或预报实际系统某些状态的未来发展趋势。
③对系统实行最优控制。
对于同一个实际系统，人们可以根据不同的用途和目的建立不同的模型。
所建模型只是实际系统原型的简化，因此既不可能也没必要把实际系统的所有细节都列举出来。
实际建模时，必须在模型的简化与分析结果的准确性之间作出适当的折中，这是建模遵循的一条原则。
现在的系统类似股票交易市场的系统，银行信用卡中心的系统都是一些关系到民生问题的重要系统。
为了满足所有客户的各种需求，势必我们的系统会变的非常复杂，如果我们不能在复杂的东西里找到内在的联系和规律，或者提炼出一个高度概括或者抽象的模型的话，那我们的开发强度和难度及所需的时间会大大增加。
这就看出来了建一个模型的必要性了。
就比如我们课本配套光盘里的第二章节的案例，大家可以查看唯一的一个VISIO文件。
从这个文件里我们可以看出，一个购书网站要实现的功能是非常复杂的，就好比我们现在大家比较熟悉的贝塔斯曼书友会，然而要把这么多细支末结的功能一一实现而没有遗漏，光考我们传统的纸上记一笔，黑板上写一下是不够的，那我们如何利用一种方法来实现这种效果呢？
那就是建模型，我们继续看VISIO文档，从建好的模中，我们可以看见，本系统分为3块，购书网站一块，配送中心一块，WindowsServer2003UDDI服务一块，主要模块是购书网站，从图里我们也可以清楚的看出客户如何与网站进行交互，并分别通过哪些模块完成整个采购过程的。
从这幅图里大家就可以很清楚的看出本项目的结构及要完成的模块组织。
阅书：
2.1.1
幻灯：
第4页
讲授：
UML（UnifiedModelingLanguage,统一建模语言）是一种可视化的建模语言，它能够让系统构造者用标准的、易于理解的方式建立起能够表达他们设计思想的系统蓝图，并且提供一种机制，以便于不同的人之间有效的共享和交流设计成果。
（1）UML是一种语言
（2）UML是一种可视化的语言
（3）UML是一种可以用于详细描述的语言
（4）UML是一种构造语言
UML不是一门程序设计语言。
但可以使用代码生成器工具将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML。
UML不是一种可用于定理证明的高度形式化的语言，这样的语言有很多种，但它们通用性较差，不易理解和使用。
UML是一种通用建模语言。
对于一些专门领域，例如用户图形界面（GUI）设计、超大规模集成电路（VLSI）设计、基于规则的人工智能领域，使用专门的语言和工具可能会更适合些。
UML是一种离散的建模语言，不适合对诸如工程和物理学领域中的连续系统建模。
它是一个综合的通用建模语言，适合对诸如由计算机软件、固件或数字逻辑构成的离散系统建模。
标准建模语言UML的重要内容可以由下列五类图（共9种图形）来定义:
·我们这里看一个用例图的例子,用例图从用户角度描述系统功能,并指出各功能的操作者。
我们还是看书本光盘里本章节的技术文档（VISIO文档），这份文档里描绘的就是一幅用例图。
通过这份用例图我们可以清楚的看见用户从登陆，管理购物车，到用户帐户管理，书籍详细信息浏览，订单管理，查找书籍，购买书籍模块的操作如何进行。
清晰的描述了从用户的购物角度如果构建本系统的功能模块的。
通过每个功能，我们有可以看出支持完成这些功能的子模块及其功能。
我想浏览之此，大家应该已经体会到，一个复杂的系统通过一个用例图就能很清晰明朗的展现在我们眼前了。
阅书：
2.1.2
幻灯：
第6页
●简单讲解，不需要过多的展开。
给学生建立相关的概念即可。
讲授：
现在我们来了解一下UML视图有哪几个：
用户视图
用户视图也称作用例视图，前面已经多次和大家一同讲解过书本中的用例视图的例子。
此处就不再多累述。
结构视图
这就好比我们的设计图纸，告诉我们整个项目的结构是什么样子的。
构造如何。
例如：
行为视图
该视图也称之为过程视图，为的是告诉大家系统会做什么，会发生什么改变等等。
例如：
实现视图
实现视图表示系统逻辑要素的结构。
环境视图
环境视图也称为部署视图。
讲解课本：
2.1.3
阅书：
2.1.3
幻灯：
第7页
●帮助学生建立MSF的概念。
●让学生产生技术以外项目管理方面的兴趣。
讲授：
我们现在再来了解一下UML图的类型，这里我们介绍几个比较常用的：
用例
用例图描述了系统提供的一个功能单元。
用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的"角色"（actors，也就是与系统交互的其他实体）关系，以及系统内用例之间的关系。
用例图一般表示出用例的组织关系--要么是整个系统的全部用例，要么是完成具有功能（例如，所有安全管理相关的用例）的一组用例。
要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。
要在用例图上绘制一个角色（表示一个系统用户），可绘制一个人形符号。
角色和用例之间的关系使用简单的线段来描述。
类图
类图表示不同的实体（人、事物和数据）如何彼此相关；换句话说，它显示了系统的静态结构。
类图可用于表示逻辑类，逻辑类通常就是业务人员所谈及的事物种类--摇滚乐队、CD、广播剧；或者贷款、住房抵押、汽车信贷以及利率。
类图还可用于表示实现类，实现类就是程序员处理的实体。
实现类图或许会与逻辑类图显示一些相同的类。
然而，实现类图不会使用相同的属性来描述，因为它很可能具有对诸如Vector和HashMap这种事物的引用。
序列图
序列图显示具体用例（或者是用例的一部分）的详细流程。
它几乎是自描述的，并且显示了流程中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。
序列图有两个维度：
垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。
序列图的绘制非常简单。
横跨图的顶部，每个框（参见图4）表示每个类的实例（对象）。
在框中，类实例名称和类名称之间用空格/冒号/空格来分隔，例如，myReportGenerator:
ReportGenerator。
如果某个类实例向另一个类实例发送一条消息，则绘制一条具有指向接收类实例的开箭头的连线，并把消息/方法的名称放在连线上面。
对于某些特别重要的消息，您可以绘制一条具有指向发起类实例的开箭头的虚线，将返回值标注在虚线上。
就我而言，我总喜欢绘制出包括返回值的虚线，这些额外的信息可以使得序列图更易于阅读。
状态图
状态图表示某个类所处的不同状态和该类的状态转换信息。
有人可能会争论说每个类都有状态，但不是每个类都应该有一个状态图。
只对"感兴趣的"状态的类（也就是说，在系统活动期间具有三个或更多潜在状态的类）才进行状态图描述。
活动图
活动图表示在处理某个活动时，两个或者更多类对象之间的过程控制流。
活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。
根据我的经验，活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等。
这是因为与序列图相比，活动图在表示上"不够技术性的"，但有业务头脑的人们往往能够更快速地理解它们。
活动图的符号集与状态图中使用的符号集类似。
像状态图一样，活动图也从一个连接到初始活动的实心圆开始。
活动是通过一个圆角矩形（活动的名称包含在其内）来表示的。
活动可以通过转换线段连接到其他活动，或者连接到判断点，这些判断点连接到由判断点的条件所保护的不同活动。
结束过程的活动连接到一个终止点（就像在状态图中一样）。
作为一种选择，活动可以分组为泳道（swimlane），泳道用于表示实际执行活动的对象。
组件图
组件图提供系统的物理视图。
它的用途是显示系统中的软件对其他软件组件（例如，库函数）的依赖关系。
组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次2上显示。
部署图
部署图表示该软件系统如何部署到硬件环境中。
它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。
因为部署图是对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。
部署图中的符号包括组件图中所使用的符号元素，另外还增加了几个符号，包括节点的概念。
一个节点可以代表一台物理机器，或代表一个虚拟机器节点（例如，一个大型机节点）。
要对节点进行建模，只需绘制一个三维立方体，节点的名称位于立方体的顶部。
所使用的命名约定与序列图中相同：
[实例名称]:
[实例类型]
讲解课本：
2.1.4
阅书：
2.1.4
幻灯：
第8页
讲授：
什么是ORM?
对象角色建模（ORM）提供了概念性的、易于理解的模型化数据的方法。
ORM方法论基于三个核心原则：
∙简单：
以最基本的形式建模数据。
∙传达性：
数据库结构被任何人都能理解的语言文档化。
∙精确性：
基于数据模型创建正确标准化了的结构。
典型地，建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。
建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。
建模者也必须能以简单的单元分析信息，对样本数据进行处理。
ORM专门被设计为改进这种联系。
规则表达式
ORM把应用程序世界表示为具有角色（关系中的部分）的一组对象（实体或值）。
ORM有时也称为基于事实的建模，因为它把相关数据描述为基本事实。
这些事实如果分割为再小的事实就会丢失信息。
简单事实的一些例子包括：
∙人有电话
∙人住在某个地方
∙人生于某个日期
∙人在某个日期被雇佣
ORM的优点
ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。
从示例中，可以看出ORM还提供了灵活性。
使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。
另外，ORM允许非技术企业专家按样本数据谈论模型，因此他们可以使用真实世界的数据验证模型。
因为ORM允许重用对象，数据模型能自动映射到正确标准化的数据库结构。
ORM模型的简单性简化了数据库查询过程。
使用ORM查询工具，用户可以访问期望数据，而不必理解数据库的底层结构。
数据库生成和遍历引挚
像所有优秀的模型方法一样，ORM也不只是一个概念。
它包含了不同的设计过程以帮助建模者映射概念的和逻辑的模型，或使用转换引挚在这些模型间转换。
ORM模型也能够自动地映射到大多数流行的关系型数据库所实现的数据库结构。
检查前面的例子，ORM模型能自动生成ER图表或逻辑模型（可以翻译为SQL代码，并适用于所选择的数据库）。
讲解课本：
2.1.5
阅书：
2.1.5
幻灯：
第13页
●参考连接：
2.2创建用例和使用场景
教学提示：
本节主要达到一个目的。
●能够学会创建使用场景。
（精讲）
教学内容
教学方法
教学提示
讲授：
用例图描述了系统提供的一个功能单元。
用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的"角色"（actors，也就是与系统交互的其他实体）关系，以及系统内用例之间的关系。
用例图一般表示出用例的组织关系--要么是整个系统的全部用例，要么是完成具有功能（例如，所有安全管理相关的用例）的一组用例。
要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。
要在用例图上绘制一个角色（表示一个系统用户），可绘制一个人形符号。
角色和用例之间的关系使用简单的线段来描述。
讲解课本：
2.2.1
阅书：
2.2.1
幻灯：
第16页
讲授：
然后我们将要根据需要延伸出其他的用例，我们现在来看一下书上是如何讲解的：
讲解课本2.2.2。
阅书：
2.2.2
幻灯：
第17页
讲授：
使用场景说明操作者和系统之间的高层次交互。
所有用例组合起来详细地描述一个工作流过程。
使用场景提供有关组成一个过程的活动和任务序列的更多信息。
使用场景记录了任务的序列。
讲解课本：
2.2.3
阅书：
2.2.3
幻灯：
第18页
讲授：
我们现在来看一下创建使用场景的相关讲解：
讲解课本：
2.2.4
阅书：
2.2.4
幻灯：
第19页
讲授：
在确定一个用例之后，就能确定这个用例可以发生的不同使用场景。
然后使用从用户收集的信息描述这个用例的不同使用场景。
创建使用场景帮助确定是否收集了适当级别的信息。
收集必要数量的信息来描述当前状态是收集信息和分析信息迭代方面的一部分。
讲解课本：
2.2.5
阅书：
2.2.5
幻灯：
第20页
讲授：
我们现在来看一下如何进行确定需求的操作。
讲解课本：
2.2.6
阅书：
2.2.6
幻灯：
第24页
讲授：
最后我们需要去完善需求：
讲解课本：
2.2.7
阅书：
2.2.7
幻灯：
第25页
2.3收集信息
教学提示：
本节主要达到一个目的。
●确定用于收集需求的不同信息来源。
（精讲）
教学内容
教学方法
教学提示
讲授：
企业体系结构在某个时间点上为业务的表现，即一个动态系统。
一个公司的企业体系结构将信息技术组和过程与公司的目标结合。
要收集有关一个企业体系结构的信息，可以使用企业体系结构模型中的四个描述性类别来指导和分类收集到的信息。
这四个类别分别是业务、应用程序、运营和技术。
我们现在分别根据书本分析一下这四种类别的信息具体有什么含义。
讲解课本：
2.3.1
阅书：
2.3.1
幻灯：
第28页
●讲解课本即可，此处需要学生有一定的企业经验才能理解，所以老师需要多多采用一下实际的例子去讲解。
讲授：
信息必然需要靠人来收集，收集信息有许多中渠道，我们现在看一下书上街上了哪几种信息收集的方法：
讲解课本2.3.2。
阅书：
2.3.2
幻灯：
第29页
●教师需要以实际场景为蓝本进行教学。
讲授：
现在我们再来看一下信息的来源。
分为三个部分：
成品，系统，人。
现在我们以来自人的信息作为例子，给大家看一个上面介绍的购书网站的产品管理部门经理采访记录：
采访摘要
此次采访的对象是产品管理部门经理。
采访的重点是产品管理部门对书籍所采取的管理方式以及该部门对网上书店系统的建议。
采访详情
产品管理部门担负着管理全公司书库的重任，作为一个直接和书籍管理打交道的部门，长久以来我们形成了一套良好的管理策略，正是基于对书籍管理丰富的管理经验，我们才能够有能力确保公司的书目管理井井有条。
目前，公司要着手开发一个网上书店系统，这无疑需要我们部门对此作出相应的反应，在书籍管理策略上作出相应的补充。
最大的变化会发生在书籍数据的移植上，我们部门需要把公司原先系统中的书籍信息全部移植到新的系统上，同时还要对新的系统进行管理，这项工程的工作量是非常庞大的。
首先，我们可能遇到的问题是数十万条书籍纪录存放在原先的数据库中，但是该表的数据结构定义扩展性不够，这无疑将对我们部门数据的移植带来不便，所以我们希望具体开发网上书店系统的同时，能兼顾考虑到这个问题，开发方要能够参考我们内部网络中的数据结构作相应的设计，希望能够以我们目前的数据库结构为基础进行相应的扩充或修改，并把初步设计好的系统数据库结构拿出来与我们一同探讨，待我们确定后方可进行全面开发。
只有这样我们移植数据时才能保证原有信息的完善性和过程的简单性。
再有就是我们在管理书籍的时候时常会遇到这种情况，我们无法通过网络来获知书籍是否销售告罄，只能从配送中心的人工那里获得消息，这使得我们会增加许多不必要的工作量。
因此，我们希望新系统的设计能够考虑到这个问题，在某一书籍的即将售完的时候，系统可以及时地发出提醒，以便产品管理部门的人员可以及时与采购部门联系进货。
当然我们希望新书到货后，我们部门的人员可以将供货商提供的新书信息及时发布到新的系统中，以便客户迅速查看并搜索新书。
我们还希望有专门的板块能够供我们公司向用户介绍当前的热销书籍，这样一则可以方便用户快速找到自己想要定购的书籍，二者也可以促进热销书籍的销售。
另外需要补充的一点是，时常会有些书目资料信息发生变动，我们希望这些信息也能够第一时间地反映到网上书店的系统中。
我们觉得上述功能无疑将会是客户们最经常关注的部分，它不仅反映了我们公司供货渠道的高效率，而且也反映了我们对客户的周到服务。
讲解课本：
2.3.3
阅书：
2.3.3
幻灯：
第30页
讲授：
我们现在来看一下定义信息收集策略方面的知识点：
讲解课本：
2.3.4
比如：
移动软件开发商，俊晗工作室，在开发迷你万年历的前期，做了很多市场调查工作。
但是他们为了能更好的掌握将来软件开发出来的功能确认。
他们制定了自己的收集信息的策略：
1．向各个层面的不同工作，不同年龄的用户提供网络问卷。
2．向已经使用过其他类似软件的用户提供我们的计划前景书，收集他们对于我们计划的意见。
通过这个策略，该工作室可以向不同社会角色及年龄的人收集信息。
使信息具备广普性。
同时问卷，可以把信息及时反馈回来，同时具备记录存档的能力。
可以很好的为后面的分析资源记录提供原始资料。
向用过类似产品的用户收集信息。
可以达到从使用相似业务过程的组收集信息的目的。
阅书：
2.3.4
幻灯：
第31页
2.4分析信息
教学提示：
本节主要达到一个目的。
●描述用例和使用场景。
（精讲）
教学内容
教学方法
教学提示
讲授：
现在我们来看一下验证现有信息的一些基本常识：
讲解课本：
2.4.1
阅书：
2.4.1
幻灯：
第34页
●进行本章教学的时候，请参照本章习题4和5开展讨论。
使学生可以将所学的东西进行实际的应用和思考中。
讲授：
现在我们来看一下一个开始需求文档的例子：
讲解课本2.4.2
阅书：
2.4.2
幻灯：
第35页
讲授：
最后我们来看一下内部项目团队文档编制的相关知识点：
讲解课本：
2.4.3
阅书：
2.4.3
幻灯：
第36页
总结
经过本章的学习，我们了解了下列的知识和内容。
●描述收集信息的技术
●描述信息收集的来源
●创建信息收集的策略
●通过使用场景和用例来分析、完善需求
●创建内部项目文档
●描述建模表示法，比如UML和ORM
在第三章中，我们将进行解决方案的构思的学习，让大家能理解解决方案的构思在ＭＳＦ中起到什么作用．
布置作业
完成书后习题1-5
案例教学
请对应书本光盘“CASESTDY\第二章\阅读文档\”内的文档资料，能够了解项目中收集和分析信息的方法。
案例
统一运输
背景
统一运输是一家专业从事包裹货运的运输公司。
公司的业务遍布北美和欧洲，同时提供陆路和航空服务。
公司拥有属于自己的，包括卡车、飞机在内的交通工具用于运输。
公司每周平均处理10万个包裹。
公司最重要的业务之一就是商务运输。
由于运输市场的不断萎缩，公司经常发出未满载的运输工具。
为了最大程度的利用运输工具的空间和增加收入，公司计划向独立运输代理商提供一种新服务，该服务允许独立代理商使用公司的运输工具进行城际大宗货物运输，每宗货物都包含大量包裹。
必须改良公司现存的商务应用程序以支持新服务。
你是统一运输聘用的开发人员。
你将领导使用微软.NET框架的解决方案的开发，以满足新服务的需求。
现有IT环境和应用程序
公司使用一套运行在MicrosoftWindows2000Server平台上的包裹跟踪应用程序。
这套系统可以连接到客户机、手掌电脑和互联网。
公司员工用客户机和手掌电脑跟踪包裹的动向。
客户运用互联网跟踪其包裹的运输状态。
针对每个包裹，现有系统跟踪以下信息：
运货单号
兑换帐号
付款方式
重量
发送方姓名
发送方地址
发送方电话号码
接受方姓名
接受方地址
接受方电话号码
货物状态
用户不需认证就可以检查运货单状态。
系统保存历史记录以跟踪包裹位置。
每次包裹改变位置，历史记录就写入一次。
一个历史记录包括以下信息：
运货单号码
日期
时间
路线号码
仓库号码
货物状态
平均每个包裹占用1KB存储空间，用以存放包裹信息和所有相关包裹的历史记录。
公司也运用运输工具—行程安排应用程序来跟踪运输工具和其路线。
这个系统制定仓库间的时间路线图，跟踪运输工具是否可用，并根据预定路线指派合适的运输工具。
运输工具—行程安排应用程序使用自带数据库，包括以下表：
路线定义表描述仓库间准确路线的特点，包括预定的出发和到达时间
运输工具表记录运输工具的类型、大小和可用状态
路线实例表将一个制定的运输工具和一条定义过的路线联系起来。
当一个运输工具在两个仓库间运输货物时，就建立一个路线实例表的条目
实施
包裹跟踪应用程序和运输工具—行程安排应用程序是应用MicrosoftSQLServer2000，ASP，MicrosoftVisualBasic6编写的COM+组件和Vi
升级会员 