基于NET的需求分析和解决方案设计06.docx

基于NET的需求分析和解决方案设计06.docx

《基于NET的需求分析和解决方案设计06.docx》由会员分享，可在线阅读，更多相关《基于NET的需求分析和解决方案设计06.docx（23页珍藏版）》请在冰豆网上搜索。

基于NET的需求分析和解决方案设计06

第6章物理设计的创建

本章概述

在计划阶段，连同概念设计和逻辑设计一起，项目团队还创建了一个解决方案的物理设计。

通过对物理设计的介绍，将了解到物理设计的目的，物理设计所涉及的任务，以及物理设计完成时的交付成果。

还将学习创建物理设计的四个步骤：

调研、分析、合理化、实现。

教学目标

●掌握在Microsoft解决方案框架（MSF，MicrosoftSolutionsFramework）过程模型中物理设计的角色

●掌握物理设计的步骤

●创建初步服务拓扑

●为解决方案选择候选技术

●将组件分布并打包到不同层次中

●设计编程模型

教学重点

●掌握物理设计的步骤

●设计编程模型

教学难点

●设计编程模型是一个需要具备较丰富企业经验的专业人事才能具体全面的概况到的。

对于大多学生来说，欠缺的就是企业经验

教学资源

课本

知识点

5.1物理设计概述

5.2物理设计分析

5.3物理设计合理化

5.4物理设计实现

习题

　习题1-对应知识点物理设计分析

　习题2-对应知识点物理设计分析

习题3-对应知识点物理设计合理化

习题4-对应知识点物理设计合理化

习题5-对应知识点物理设计实现

教师光盘

幻灯片

　教师光盘：

\Powerpnt\2710B_06.ppt

多媒体视频

　教师光盘：

\Powerpnt\

习题解答

　教师光盘：

\tPrep\answer

先修知识

在正式开始学习本章内容以前，学生须具备下列知识基础。

先修知识

推荐补充

了解Windows程序设计的基础知识。

《基于VB.NET的Windows程序设计》

了解WEB类程序设计的知识。

《面向.NET的Web应用程序设计》

连接XMLWebService开发的知识。

《XMLWebService开发》

建议学时

课堂教学（2课时）

教学过程

6.1物理设计概述

教学提示：

Microsoft解决方案物理设计概述主要达到两个目的。

●掌握物理设计。

（略讲）

●列出物理设计的交付成果。

（略讲）

教学内容

教学活动

教学提示

讲授：

物理设计是MSF过程模型计划阶段的第三个设计活动，物理设计是从开发需求的角度，描述解决方案的组件、服务和技术的过程。

物理设计定义了解决方案中将被开发的部分，以及如何对它们进行开发，还有它们如何互相交互。

物理设计是从开发小组的角度描述解决方案的组件、服务以及技术的过程。

物理设计旨在根据现实的技术局限性分析逻辑模型，包括实现情况和性能方面的考虑。

物理设计过程的结果是一组组件、特定平台的用户界面设计以及物理数据库设计。

物理设计为功能规格提供基础。

开发小组、测试小组以及部署小组都可使用这一功能规格作为质量保证的基础。

物理设计的输入是此时已被创建的所有成品，这些成品包括逻辑对象模型，一个初步用户界面设计，以及在逻辑设计中生成的逻辑数据模型。

像项目计划等成品将会进行一些较小的更新，并用来为物理设计的里程碑设置最后期限。

在物理设计的最后，团队会交付一组组件、Microsoft.NET程序集、二进制文件和链接库的说明书；解决方案用户界面的细节；数据库架构；如触发器、索引、存储过程等数据库对象；以及解决方案所要用到报表的细节。

讲解课本:

6.1.1

阅书：

6.1.1

幻灯：

第5页

讲授：

项目团队以下列目标创建物理设计：

讲解课本：

6.1.2

阅书：

6.1.2

幻灯：

第7页

讲授：

我们来看一下物理设计中团队角色的任务：

讲解课本：

6.1.3

阅书：

6.1.3

幻灯：

第8页

讲授：

我们来看一下物理设计的交付成果：

讲解课本：

6.1.4

阅书：

6.1.4

幻灯：

第9页

讲授：

物理设计过程包含几个步骤：

研究、分析、合理化以及规范化：

Ø物理设计的研究步骤包括确定基本结构的物理局限性以及解决方案的物理需求，并处理物理局限性与需求之间可能产生的冲突。

Ø物理设计的分析步骤包括选择备选的实现技术并草拟由网络、数据、组件拓扑结构组成的初步部署模型。

Ø物理设计的合理化步骤包含确定打包方式和分布策略、将对象分解成基于服务的组件、在拓扑结构中分布组件以及进一步改进打包和分布方式。

Ø物理设计的规范化步骤包括确定编程模型、指定组件接口和了解组件结构的考虑因素。

讲解课本：

6.1.5

阅书：

6.1.5

幻灯：

第10页

讲授：

现在我们来看一下物理设计的调研步骤：

调研基线的交付成果包括：

●当前网络拓扑

●当前数据拓扑

●当前组件拓扑

●物理应用程序需求

●更新的风险评估和减轻计划

同时还要确定物理需求和约束解决需求和约束之间的冲突。

讲解课本：

6.1.6

阅书：

6.1.6

幻灯：

第11页

6.2创建逻辑设计模型

教学提示：

本节主要达到一个目的。

●完善从逻辑设计中得出的UML模型。

（略讲）

教学内容

教学方法

教学提示

讲授：

在逻辑设计的最后，团队将得到解决方案中对象、服务、属性和关系的UML模型。

通常来说.，团队会使用能最好地体现他他他们意图和决策的成品来管理项目中的复杂部分。

这些成品包括下列交付成果：

●对象和服务清单

●类图

●时序图

●活动图

●组件图

这些就是我们需要去完善的部分。

讲解课本：

6.2.1

阅书：

6.2.1

幻灯：

第15页

讲授：

网络拓扑是一个基础设施图，用来显示硬件的位置和互联情况。

该图展示了工作站和服务器并描述了它们的功能。

此外，拓扑还展示了连接计算机的网络基础设施。

你首先要定义出动作，才能发现并定义这些附属的对象。

部署拓扑是一种图，它除了指明数据存储的位置之外，还指明了与网络拓扑相关的包、组件、以及服务的位置。

该图展示了组件的物理分布以及它们在不同服务层之间的位置。

如果团队不是用一个全新的解决方案进行工作，则应该已存在一个当前状态版本。

此时，可以添加应用程序所需的新组件和新服务。

以下就是一个网络拓扑的例子：

讲解课本6.2.2。

阅书：

6.2.2

幻灯：

第19页

●讲解配套ＣＤ上的ＰＰＴ。

6.3物理设计合理化

教学提示：

本节主要达到一个目的。

●确定合理化基线的交付成果。

（略讲）

教学内容

教学方法

教学提示

讲授：

我们现在来看一下合理化的交付成果有哪些？

讲解课本：

6.3.1

阅书：

6.3.1

幻灯：

第24页

讲授：

首先我们要知道什么是分布策略？

分布策略是一个基本原理，该原理用来决定在解决方案体系结构中服务分布的位置。

分布是基于服务的而不是基于组件的。

然后我们来看一下打包策略，状态管理方面的相关知识点：

讲解课本6.3.2

设计考虑包括：

可扩展性。

可扩展性包含迅速和容易地扩展解决方案的能力，从而能处理更多事务或更多用户

性能。

系统性能包括系统响应时间和系统执行一个应用程序任务的速度

可管理性。

系统的可管理性包括能够方便地在各个层次上对系统进行管理

重用。

重用指的是组件可以容易的被其他应用程序重新使用

粒度。

粒度指的是组成一个对象的服务的数目，和组成一个组件的对象的大小及数目

讲解课本：

6.3.2

阅书：

6.3.2

幻灯：

第25页

讲授：

良好的组件计划的特征之一是高内聚、松耦合。

我们来看一下什么是内聚和耦合。

如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。

高内聚性的软件更容易维护和改进。

判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。

如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。

只有高内聚性的模块才可能被重用。

高耦合度的系统是很难维护的。

一处的修改引起另一处甚至更多处的变动。

你可以通过以下方法降低程序的耦合度：

隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：

当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。

耦合度低的软件可以很容易被重用、维护和扩充。

讲解课本：

6.3.3

阅书：

6.3.3

幻灯：

第28页

讲授：

然后我们来了解一下打包组件的知识点：

讲解课本：

6.3.4

阅书：

6.3.4

幻灯：

第29页

讲授：

现在我们来了解一下分布层次指导方针：

讲解课本：

6.3.5

阅书：

6.3.5

幻灯：

第30页

讲授：

部署模型是一个图表，该图表将应用程序与应用程序的服务关联到实际服务器拓扑中。

部署模型的目的是允许开发团队与发布管理团队设计和计划服务器拓扑以及服务器配置。

它使用网络拓扑并显示将要部署到每一台服务器上的应用程序服务。

讲解课本：

6.3.6

阅书：

6.3.6

幻灯：

第32页

讲授：

最后我们要去验证和完善分布与打包

讲解课本：

6.3.7

阅书：

6.3.7

幻灯：

第33页

6.4物理设计实现

教学提示：

本节主要达到一个目的。

●描述编程模型。

（略讲）

教学内容

教学方法

教学提示

讲授：

首先我们要了解编程模型的目的。

编程模型描述了开发团队如何使用已选定的技术。

编程模型包括编程说明书或在项目实现过程中应该遵循的标准。

编程模型设置明确的指导方针来提供一致的组件实现，并提高组件的可维护性。

编程模型的设计考虑要考虑的很多方面。

比如：

实现技术。

有状态对象和无状态对象的对比。

进程内功能调用和进程外功能调用的对比。

内聚和耦合。

连接模式和非连接模式的对比。

同步编程模型和异步编程模型的对比。

线程模型。

错误处理。

安全性。

分布。

讲解课本：

6.4.1

阅书：

6.4.1

幻灯：

第36页

●参考链接：

讲授：

在描述了编程模型之后，项目团队要定义组件如何交互。

这些交互根据组件的接口编制成文档，组件接口描述了如何访问它们的服务与属性。

一个接口可以代表一个或更多的服务。

接口可以提供一种方法来请求执行操作的服务，也可以提供一种方法来获得结果属性的信息。

在组件接口中概略描述了组件的外部结构。

接口（interface）用来定义一种程序的协定。

实现接口的类或者结构要与接口的定义严格一致。

有了这个协定，就可以抛开编程语言的限制（理论上）。

接口可以从多个基接口继承，而类或结构可以实现多个接口。

接口可以包含方法、属性、事件和索引器。

接口本身不提供它所定义的成员的实现。

接口只指定实现该接口的类或接口必须提供的成员。

　　接口好比一种模版，这种模版定义了对象必须实现的方法，其目的就是让这些方法可以作为接口实例被引用。

接口不能被实例化。

类可以实现多个接口并且通过这些实现的接口被索引。

接口变量只能索引实现该接口的类的实例。

例子：

interfaceIMyExample{

　stringthis[intindex]{get;set;}

　eventEventHandlerEven;

　voidFind（intvalue）;

　stringPoint{get;set;}

}

publicdelegatevoidEventHandler（objectsender,Evente）; 

　　上面例子中的接口包含一个索引this、一个事件Even、一个方法Find和一个属性Point。

讲解课本6.4.2。

阅书：

6.4.2

幻灯：

第38页

●参考链接：