PS：已经完成了，点击查看效果

一个橱柜公司的网页界面设计，Yanyan要求我出两款，实在没什么创意，还好自己平时就收藏一些比较好的界面，参照了一下，设计了两款，为了后期的页面代码重购，整体给自己的要求就是，正规，简单大方一点，感觉还是找不到感觉，但是时间又逼的紧～

我个人喜欢第一款，这是仿韩国网站设计的，还有国内一些比较好的企业主页修改而成，感觉色彩以及布局比较现代，大方～

第二款，就比较老土，但是应该来说我先做的时候还是想这样做，以最老土的形式先把界面内容整理出来，对页面的元素清楚了，现在一些公司基本不会给你很明确的咚咚，所有的东西，你必须自己提起，自己调整，等都明确了，才能更好地把创意设计加到里面，～

后面就是选个方案，修改扩充，然后页面的实现，很想真正来一次完全按标准写的做一次，看时间，来的及，可以尝试～

PS：开始规划自己的域名申请跟空间存放问题，找了一个国外的空间，还必须要信用卡，我晕，有钱自己整台服务器，努力，努力再努力～

1. 产品制作人，写产品计划书。
2. 用户体验研究员，作调查分析。
3. 信息建构师，设计产品架构。
4. 互动设计师，作出互动流程。
5. 视觉设计师和用户界面设计师，作出页面视觉设计。
6. 前台工程师，前台开发。
7. 后台工程师，后台开发。
8. 用户体验研究员，做用户测试确保质量。

主要网络产品设计工作流程是这样的：

网络产品设计：

产品制作人写产品计划书，确定新产品或新功能的市场意义和经济效益，提交部门审批，同意后，确认需要设计的部分，和用户体验研究员（user researcher），信息建构师(information architect)，视觉设计师(visual designer)、user interface designer， 互动设计师(interaction designer)，web developer，工程师(engineer)一起讨论需要的支持，然后订出时间计划分工合作。一般是先由用户体验研究员作调查、分析后由信息建构师设计产品架构，然后由互动设计师作出互动流程，之后交给视觉设计师(visual designer)和user interface designer作出视觉设计。然后web developer把设计通过编写程序（html, dhtml, JavaScript）等等再现出来，最后交给工程师。做完后用户体验研究员需要做用户测试，QA（Quality assurance） 需要测验这一产品的每一步骤，确认产品的使用质量，如果有问题需要让工程师或相关人员解决。

小型项目的工作流程局往往限于有限的人力和时间，经常是短、平、快：拿到brief，进行设计，综合意见，投放到网站，总结效果。比如广告设计，一般是我组织市场部开会，集体出创意，然后大家达成一致意见。决定设计主题后发到德国和法国取得相关的翻译。按照雅虎的广告标准，我设计制作出最终的广告，交到广告发行部定期发行。广告运行两周后，拿到数据信息，根据浏览量(page impressions)，点击率(CTR: Click Through Rate)，和conversion rate来分析广告效果，总结经验。

今天看到一个例子，比较有感触，应该归结于三维空间的导航交互研究一部分吧，我们目前正在构建一个基于网络的立体博物馆，目前就遇到很多关于如何导航的问题，以及交互问题，这里介绍的这个系统就很有意思，Ipunkt系统在博物馆中可以追踪行人，为他引导方向，显示所在位置，还会为你提供展品的信息 。目前已经在一些博物馆和展厅使用了，看了他的介绍这个应该 是个现实中的，但是我想如果把他应用到网络上，会是一个不错的二维和三维结合体验，因为这个导航更多的是把定位的理念融合在里面，定位，很容易让人想到点击，而且它本身的界面美观也会为场景增添一道风景线，比起单纯的标识还是会好一些~

最近接触比较多的是三维空间的交互，感觉这里面可探讨的东西很多，目前在网络上关于这方面的理论又很少，关于二维的 ，目前研究的已经很多，基于三维的，现在大多都是跟虚拟现实结合在一起，我接触比较多的是网络三维，所以在平时的时候我就像如何来最大地满足我们正常的交互，如何把宜人的人机结合进来，是我所关心的~

把一些问题先提出,以后有想法,一一来解答

1.三维空间的交互如何更好地提醒人进行操作

网络三维的空间，不同于硬件上的虚拟现实空间，目前他还没有一些虚拟手套以及三维眼睛，还是依靠传统的鼠标以及键盘，场景是三维的，但是屏幕依然是二维的,所以他依然摆脱不了GUI上的一些界面元素,但是平面的设计可以依靠文字或图形化标志来提醒,但是三维的空间为了完全更虚拟与现实,就必须尽量避免出现文字,在这种情况下,如果有效地提醒人进行操作是个很大的问题?

2.在仅有鼠标和键盘的情况下，如何优化操作

三维空间，就是为了更好地体现沉浸感，所以很多的时候，我们必须尽最大努力去实现这些功能，但是，目前的输入方式有限，所以，这方面什么优化也有必要好好思考，目前有些游戏的界面以及操作还是很不错的，但是很多还是给予二维上的~什么最大发挥三维的优势是个问题？

3.视宽视域的研究

在目前，我碰到最多的就是这个了，三维的视域比较特殊，你必须要注意纵深的问题，这个什么样的范围是可以接受，什么样会让人感觉更舒服，还有就是水平面应该与人的角度是多少，人在场景中漫步才不会有跳跃感？

4.界面的合理设计

三维的界面，虽然少了很多平面的东西，但是还是基于屏幕出现的，因为它还不能完全智能，所以还是有很多的界面需要设计，一些必要的提示以及弹出提示筐还是很有必要的，如何来优化这些，也需要好好探讨~

5.导航系统的研究

这个在三维的空间中是很重要的一个环节，如果一个三维的空间没有了标识，那就很容易会让人感觉是乡下人逛城的感觉，会彻底让人找不到北，我曾经就碰到很多这样的例子，走到一个三维空间，找不到方向，于是就团团转，这是很糟糕的问题，所以一定的合理的导航系统，还是非常有必要的~

6.场景的渲染效果

这个当然是越真实越好，但是目前的硬件设备还是有限的，实时渲染有对显卡要求很高，所以如何能最大地优化这些效果，让速度提升的同时又不影响人的视觉效果，以及抗锯齿问题，都应该很好地思考一下，这也是应该思考和摸索的，但是这可能就不是交互方面的，是属于视觉效果的，~

……

关于Ipunkt系统更多的图片

在网上还查到一篇关于新一代界面的研究文章，未来的界面会不会开始全部基于三维，操作的系统的发展又会是什么样，以及PC机的交互设备会不会有重大改变，好好思考一下，说不定会有很大收获~

陆陆续续终于把Django step by Step,从头做了一遍，虽然还有很多细节不是很清楚，但是收获还是挺多的，我也开始越来越喜欢Python,感觉他听符合我的使用习惯的，特别是思维以及建站流程，开始明白了他所谓的快速开发的优势在哪里，他自动建立的后台，不仅功能强大，而且界面也相当美观，以及如何简单实现一些优化，如何把美化以及技术融合在代码里面，比如怎样进行CSS以及 AJAX的运用，在教程里面基本能找到答案， 但我知道，目前所了解的也只是皮毛，你要真正去理解Python，真正去理解Django，你还是必须到他官方站去学习，这对于我的E文是个挑战，但是却也给我带来了学习的机会，对于技术的E文，我感觉我还能逼着脑子看下去，这段时间为了了解一些细节，我感觉我浏览的英文网站比以前所有的时间还多，也得开始得把这个补上了，这样才能更快地学习最新技术~

稍微整理了一下最近学习的笔记，其实在[url=http://groups.google.com/group/ie01com/browse_thread/thread/f26cf9b8c92155d9/19f424d11b233562?lnk=st&q=django%E4%BD%BF%E7%94%A8%E7%82%B9%E6%BB%B4&rnum=1&hl=zh-CN#19f424d11b233562]GOOGLE 邮件列表[/url]里面已经发现了一份，我再根据自己的学习体会稍微总结一下，也方便以后真正做东西的时候参考~

django是用python开发的一套web framework工具

1。首先所有的操作我目前基本是居于DOS在操作，所以首先了解一些必要的python命令是需要的

创建project ：

这个相当于建一个项目总文件夹，里面有四个文件

后面经常会用到manage.py。包括运行他自带的服务器，建一些其他的东西，都是居于manage.py 进行的

2.创建application ：

运行这个会产生 3个文件

这样在 [appname] 子目录下有以下文件:

我用的是Mysql，关于mysql的安装以及在Django中的使用我前面也简单介绍了一下，不再重复~

3. 编辑settings.py

4.初始化数据库

以前好像是manage.py init 现在已经改变了，应该注意，运行后会提示建立超级用户，记得自己建一个，后面Admin 的时候有用。

5.
安装 admin app

这个运行，就是自动给你省城一些功能强大的后台

6.批处理快速建立环境

7.转换到python环境

修改urls.py

上面的 r'^$' 是为了匹配空串，也就是形如: http://localhost:8080/ 。这个是 URL映射的修改地方，访问没有文件后缀名，都靠这个来映射，也是我比较喜欢的方式~

8.创建 login.py

9.添加一些CSS和图片

增加了一些 div 标签

表示是对 base 的扩展，然后是相应的块的定义:

所有扩展的东西一定要写在块语句的里面，一旦写到了外面，那样就不起作用了。

……

PS:未完，待续，时间太晚了，明天在继续整理~ [redface]

By Don Awalt and Rick McUmber
RDA Corporation

摘要：所有伟大的架构师都掌握了在抽象的不同层次上概念化解决方案的技能。通过将解决方案组织到离散的层次，架构师可以专注于解决方案的单个方面而忽略所有剩余的复杂性。展示将抽象层次应用到 IT 解决方案的技术，并将其与其他工程学科相比较。

本文内容

将抽象层次应用到 IT 解决方案
抽象层次：所有工程师的强大武器
应用抽象层次时的核心原则
将抽象层次应用到 IT 系统
简单框架：四个抽象层次
通过迭代发展层次
重访抽象层次核心原则
扩展层次以支持企业解决方案
优点
小结
自我评估

将抽象层次应用到 IT 解决方案

企业架构师正受到其所面临的大量复杂性的挑战。开发一个能够自动处理企业任务的独立的部门应用程序是一回事。而设计并组成一个支持上万 IT 使用者的满是应用程序、服务器和数据库（全都支持多种企业活动）的 IT 实验室全球网络，则完全是另外一回事。要组合这些复杂性，IT 网络必须随时可用、响应迅速并保护企业宝贵的信息资产。除所有这些之外，IT 网络还必须足够灵活以支持企业永远变化的需要，并且采用出现的新技术。

一些架构师在这种复杂性方面明显非常出色，而且在不断进步。在我们的职业生涯中，能与一些真正伟大的分析师和架构师并肩工作是非常幸运的。反思这些经验，我们已经分析出是什么造就了杰出的架构师。

无一例外，所有伟大的架构师都掌握了在截然不同的抽象层次上概念化解决方案的技能。通过将解决方案组织到离散的层次，架构师可以将精力集中在解决方案的单个方面而忽略所有剩余的复杂性。他们一旦稳定了解决方案的某个部分，接下来就能继续处理其他方面，从而不断地将层次发展并完善到最终可以被实现的粘合模型中。

大多数软件开发人员懂得应该将解决方案分解到抽象层次。但是在实际的项目中，这是非常难于付诸实践的。当遇到第一个困难时，在急于开始编码时是很容易放弃这些层次的。伟大的架构师会经受这些挑战并在整个项目的生命周期中严格保持这些层次。他们意识到，如果不这样做，最终将淹没在复杂性中。

本文展示了将抽象层次应用到 IT 解决方案的技术。首先，我们会通过一个简单的示例演示此方法，然后提出一个基于正式抽象层次的系统产品的结构。

抽象层次：所有工程师的强大武器

其他的工程学科，比如土木工程师，几个世纪以来一直利用抽象层次复制复杂性。让我们学习一下其他更成熟的工程学科是如何应用抽象层次的，就从电子工程师开始吧，他们设计每次更新换代都变得更加复杂的计算机系统。

硬件工程师

系统设计师使用抽象层次为计算机系统建模。每个层次都是定义完善的，并提供了该系统的一个不同角度。许多系统是在三个主要层次上设计的：系统、子系统和组件，如图 1 所示。

分层使工程师能够将庞大数量的复杂性集成到一个单一的工作计算机系统中。在其原子部分的层次上确切了解一台计算机是不可能的。在单独一块 Intel Itanium_ 芯片上有大约 25,000,000 个晶体管。

对 IT 相关学科来说，这种把复杂性分解到抽象层的方法当然不是惟一的。类似的方法被用于从航空工程到微生物学的无数其他学科。

应用抽象层次时的核心原则

所有工程师在应用抽象层次时都遵循这套核心原则。当把抽象层次应用到软件时，这些原则也同样适用。

这些层次的数量和范围是定义完善的，以便工程师能够在复杂的系统上协作，所有团队成员必须共享对层次的同一理解。只要设计师做出设计决定，他们必须将那些决定归档到相应的细节层次。

三个抽象层次定义如下：

图 i. 定义的三个抽象层次

图 ii.抽象层次的一个简单框架

每个层次内的多个视图

一个单个层次内的复杂性可以变得非常多，以至于使人无法一次全部掌握。在这种情况下，工程师通过多个视图将设计展现于单个层次内。每个视图展现设计的一个单独方面，但保持在相同的抽象层次上。举例来说，母板工程师为板的每个层创建一个视图，从而为每层的连接路径的设计建模。

图 1. 计算机系统的抽象层次

必须保持层次间的一致性

为了让系统按预期方式运行，每个后续的层必须是其父层的适当改进。如果计算机系统设计师从 IDE 总线切换到 SCSI 总线，那么所有设备的接口规范也必须切换到 SCSI。如果层次没有同步，那么系统就不会按预期方式在顶层执行。

将抽象层次应用到 IT 系统

既然我们已经分析了其他学科是如何应用抽象层次的，现在就让我们将此技术应用于 IT 解决方案1。下列部分展示了应用抽象层次为典型 IT 应用程序的需求、设计和实现建模的技术。这些技术是通过一个针对假想零售商的简单的、指导性的在线定单系统示例来展示的。在我们的示例中，我们不仅包括了体系结构，而且扩展了范围以包括系统需求和业务环境 — 如同由零售业所定义的。

简单框架：四个抽象层次

我们的简单示例定义 IT 解决方案的如下四个抽象层次：

? 域

? 业务处理

? 逻辑

? 物理

在每个层次内，我们既展示了该特定层次行为的动态视图，又展示了其静态视图。动态视图为对象之间的消息建模，而静态视图为对象之间的结构和关系建模。

域抽象层次

应用了上面的范围规则，零售商就会作为域层次中的黑盒子中心的演员。客户作为外部的演员。域层次是从客户的角度来建模的。只为购买交互建模。用于完成购买的通讯形式不包括在这个层次，但是会在业务处理层次引入。

图 2. 关于从零售商处购买物品的域层次动态视图

图 3. 关于从零售商处购买物品的域层次静态视图

动态视图

域层次内的动态视图为客户和零售商之间的交互建模。下图汇总了域环境，并包含了简单的业务交互使用案例描述。

图 4. 关于从零售商处购买物品的业务处理层次动态视图

静态视图

域层次的静态视图为类结构和在使用案例中出现的它们的对象的关系建模。换句话说，它说明了在这个抽象层次上，为了完成购买交易客户需要了解什么对象。 图 5 展示了域层次静态视图的类关系图。

图 5. 关于从零售商处购买物品的业务处理层次静态视图

客户是 Person 的实例。客户和零售商之间的关系被具体化为 Account。所有的 Purchase 都与客户的 Account 相关。Purchase 与每个被购买的 Item 相关。每个 Item 都与特定的 Product 相关，这里 Product 遵循元类模式。Product 的实例实际上本身就是类。将其他 Product 添加到 Catalog 完全是一个数据驱动过程，而且不会对类模型产生影响，因此将 Product 建模为一个元类会使我们的模型更加灵活。围绕这些类，每个 Payment 都与其 Purchase 相关。

如您可能看到的，这个层次的模型对大多数零售商（无论类型为在线或传统，大型或小型）来说是有代表性的。这说明了为什么 [Industry] 域模型确实应该将公司定义为黑盒子中心的演员。同一个行业中的公司倾向于支持带有其外部演员的同一套业务交互。此外，域模型排除了公司的特定业务处理，这是因为在同一行业中的公司之间它们会有相当大的变化。

域层次严格集中在从外部演员的角度看到的业务交互。对此我们必须注意，不要将用于完成交互的实现机制包括进来。这些细节属于下一个抽象层次。因此，在本例中，我们只为浏览、选择、购买和支付建模。我们不为如何完成这些交互（通过电话、美国邮政、电子邮件、Web 应用程序、亲自前往、支票、信用卡或现金）建模。

业务处理抽象层次

下一个抽象层次为公司的业务处理建模，以实现在域层次捕获的交互。系统层次“内部缩放”公司的黑盒子，并标识为完成业务交易而协作的所有员工和系统。在这个层次，要开发的系统作为黑盒子中心的演员。

应用了系统层次的范围规则，在线定单系统就作为黑盒子中心的演员。客户和员工作为外部演员。系统层次是从客户和员工的角度来建模的。客户在线执行购买。支付是通过信用卡完成的。通过将物品运送到客户的收货地址履行定单。出货通知是由电子邮件发送的。

动态视图

动态视图重演了域层次购买交易，这次公开了零售商的内部业务处理。图 4 汇总了业务处理环境，并包含了关于系统及其演员之间的交互的简单使用案例描述。

静态视图

这个层次的静态视图对类模型做了改进，以捕获在业务处理层次使用案例中出现的对象。换句话说，“为了在线创建一个定单并履行该定单，客户和雇员需要理解哪些对象？”图 5 展示了业务处理层次静态视图的类关系图。我们修改域类模型以捕获在这个抽象层次上的角度。Person、Account 和 Company 抽象保持不变，Catalog 和 Product 也一样。但是，用 Order 替换了来自域模型的抽象 Purchase 事件。

Order 包括 LineItem，它与 Catalog 中的 Product 相关联。因为这个层次为公司的内部业务处理建模，所以我们需要获得现有的库存（最小库存单元 (SKU) 的一个属性，它表示在一个特定位置的物品的库存）。我们也为客户的 UserAccount 建模，它提供对在线系统的访问。Payment 是通过使用 CreditCardAccount 来完成的。Location 代表美国的一个地理位置，它作为账单邮寄地址，同时也作为 Order 的收货地址。Shipment 包含 Shipment 中包括的 Item。

我们在系统抽象层次创造方法来简化业务处理，因此该层次通常需要很多创造力。为此，通常使用业务处理层次上的若干不同形式来实现单个域层次交易。举例来说，一次购买可以通过在线、电话、邮件、传真一个定单表格或者亲自到零售店来完成。对于每一种形式，都需要在业务处理层次为其建模。请注意，尽管对零售商来说 Credit Authorizer 是一个外部演员，但是它还是在这个层次引入，这是因为只需要它实现在该层次首次出现的业务处理。

最后，请注意该系统是技术独立的。我们的在线购买系统可以用任何 Web 技术实现。在系统黑盒子内选择技术是一个体系结构决策。

逻辑抽象层次

逻辑层在系统黑盒子内缩放，从而公开高级别的系统设计。架构师选择技术并定义高级系统结构。在我们的简单示例中，系统是由承载表示层、业务层和数据访问层的 Microsoft IIS/Microsoft ASP.NET 服务器和承载持久性数据的 Microsoft SQL Server 数据库服务器组成的。

动态视图

逻辑层上的动态视图跟踪通过系统主要组件的消息流。如示例所示，在提交 ConfirmOrder Web 表单的时候，图 6 跟踪这一消息流。

图 6. 从零售商处在线购买物品的逻辑层次动态视图

静态视图

这个层次的静态视图也将我们的视角切换到系统内部。尽管业务处理层次为出现在业务处理中的真实抽象建立了模型，这个层次将抽象建模为其在系统中所要被表示的那样。在实际的系统中，架构师会为每个软件层（表示层、业务层和数据访问层）设计类。为了保持本文的简洁，图 7 只展示了业务层的静态设计，以便说明系统层抽象是如何针对设计进行改进的。

图 7. 从零售商处在线购买物品的逻辑层次静态视图

架构师对系统层类进行改进以设计业务层接口。

因为系统中的所有账户和客户都是零售商的，所以创建一个单一的 Company 实例并使其与所有账户相关联是不切实际的，因此该层次中省略了 Company。我们只是存储 Payment 所带的信用卡号和账单邮寄地址，并非为每个 CreditCardAccount 创建一个单独的实例。此外，对系统来说，为每个出售的 Item 创建一个实例是不切实际的，因此从模型中删除了 Item，并改为由模型跟踪 LineItem 中订购的物品数量以及在新 ShippedItems 类中附带的物品数量。

架构师还定义业务层公开的服务间隔。对于本示例，业务层为 Account、UserAccount、Order、Shipment 和 Catalog 导出了 Create、Read、Update 和 Delete (CRUD) 服务。椭圆形指出了 CRUD 间隔。

请注意，即使本层次的类不是业务处理类的合适超集，架构师也可以通过直接改进业务处理类、将视角由系统外部更改为系统内部来实现这个设计。

物理抽象层次

物理抽象层次捕获系统实现的结构。系统作为一个节点的网络实现，每个节点都配置有硬件和软件。逻辑视图中的三个软件层（表示层、业务层和数据层）是以代码形式被物理实现，并部署到这些节点上。逻辑视图中的持久类物理存储在 SQL Server 数据库的关系表中。

动态视图

动态视图跟踪经过物理配置节点的消息流。ConfirmOrder HTTP post 从客户的浏览器通过 Internet 通过零售商的防火墙流动到 Web 服务器，在那里 Microsoft Windows 将其转发到 IIS，IIS 又将其传递到 Microsoft ASP.NET，然后 ASP.NET 调度 ConfirmOrder.aspx。幸运的是，现代开发工具将我们与多数物理网络隔离开来。但是，架构师需要了解物理层以避免网络瓶颈和安全暴露。

静态视图

静态视图（图 8）将逻辑视图中的持久类改进为其物理表示形式。在我们的零售示例中，业务层类存储在下列 SQL Server 表中。

图 8. 从零售商处在线购买物品的物理层次静态视图

映射到关系表和属性的类作为列实现。一对一关系和一对多关系使用一个外键来实现。开放式并发通过给每个被“凝结”的父类分配一个 datetime 字段来实现。

在设计逻辑层次时，架构师主要集中关注于实现系统功能。在确信包含了系统功能之后，架构师就能够专注于在物理层次优化实现。

通过迭代发展层次

建立了这个框架后，架构师通过几次迭代对解决方案加以发展。每次迭代都合并额外的功能 — 发票、待交定单、亲自订购、电话订购等等。在每种情况下，架构师都更新适当的抽象层次，然后将这些更新改进到物理实现层。

重访抽象层次核心原则

让我们对照核心抽象层次原则来测试我们的示例。

? 这些层次的数量和范围是定义完善的：我们有四个不同的层次：公司黑盒子、系统黑盒子、系统内的逻辑设计以及物理实现。

? 每个层次内的多个视图：在这个简单示例中，我们在每个层次上展示了一个动态视图和静态视图。

? 必须保持层次间的一致性：如果对域模型作出了更改，则更改也一定会影响到较低层次。举例来说，如果零售商决定为其产品提供维护合同，分析师就会将MaintenanceContract 添加到域模型，并将其改进为其物理表现形式。对于维护大型系统来说，同步所有层次是很重要的。因为提交了增强请求，所以分析师执行对相应细节层次的影响评估。一些增强请求影响域层次（并且因此影响所有后续层次）。其他请求只影响物理层次。

扩展层次以支持企业解决方案

既然我们已经展示了带有四个抽象层次的简单示例，现在就让我们扩展这个方法来支持 IT 企业的解决方案。图 9 展示了一个 Rational 统一过程 (Rational Unified Process，RUP) 配置，它将项目产品组织到定义完善的抽象层次中。

表中的层次描述如下。

图 9. 将项目产品组织到定义完善的抽象层次中的 RUP 配置

? 域。域层次捕获项目的业务环境。

? 项目洞察力。项目洞察力对系统将会有的对企业的业务影响进行通讯。它以投资回报分析量化了这个影响。项目洞察力表示该项目的最高抽象层次。

? 业务处理。系统层次为公司内的业务处理建模。对于极其复杂的单位来说，这个层次可以再细分到子层次：部门、部门间以及部门内。

? UI 规范。UI 规范设计了实现业务处理的用户界面。它是由 UI 设计文档和功能 UI 原型组成的。

? 详细要求。详细要求指定了系统要求的最低层次抽象。它包括诸如数据类型格式和详细业务规则等详细信息。它还包括专业性要求，例如，性能、可用性、安全性、国际化、配置、可扩展性和灵活性要求等。

? 体系结构。系统的体系结构被组织到六个视图中：

? 逻辑。定义软件层和执行系统功能的主要抽象。

? 并发。捕获系统的并行方面，包括交易、服务器场和资源争用。

? 安全性。定义用于身份验证、授权、保护机密和日志记录的方法。

? 部署。定义网络拓扑和系统的部署配置。

? 组件。定义系统组件、其接口以及依赖项。

? 数据。定义持久性数据的设计结构。

优点

将系统产品组织到离散的抽象层次有若干优点：

? 它将系统要求分离到三个不同的抽象层次：业务处理、UI 规范和详细要求。我们不会再用令企业用户感到不知所措的单个整体功能规范了。取而代之，我们在三个改进的详细层次中对系统要求进行通讯。

? 分析师和架构师可以将复杂性控制在一个单一的、集成的系统模型中。

? 架构师可以专注于系统的单个方面，并将那些决策集成到整个解决方案中。

? 抽象层次形成了系统产品的结构。举例来说，软件体系结构文档为每个视图专设了一个小节。

? 抽象层次提供从要求到设计再到实现的直接可跟踪能力。可跟踪能力使小组能够在评测更改请求时执行精确的影响评估。

? 在使用同一框架开发几个系统之后，会在每个抽象层次形成模式。单位可以编录这些模式和每个抽象层次内的其他最佳实践。这个最佳实践的目录会作为过程改进计划的基础。

小结

为了处理复杂性，所有工程学科都应用正式抽象层次。软件也不例外。为了实现抽象层次的优点，项目必须：

? 正式标识层次，每个层次都有定义完善的范围。

? 将一个层次内的复杂性分开到多个视图。

? 在层次间保持一致性。

通过一个简单的示例，本文演示了如何应用抽象层次，然后将该方法扩展到支持企业 IT 解决方案。它提供了一个 RUP 配置框架，该框架将系统产品组织到定义完善的抽象层次。

自我评估

? 您当前的项目是否应用了抽象层次？

? 层次是否定义完善？

? 项目团队是否很好地理解了这些层次？

? 如果复杂性在一个层次中变得过大，团队是否将其分离到视图中呢？

? 团队是否在层次间保持一致性？

? 您的项目会从抽象层次中获益吗？

伟大的架构师本能地遵循这些原则。我们其余的人就必须有意识地应用抽象层次，并运用规则在整个项目生命周期中保持这些层次。

资源

Cockburn, Alistair. Writing Effective Use Cases. New Jersey: Addison-Wesley, 2001

Kroll, Per and Kruchten, Philippe. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Boston MA: Pearson Education and Addison-Wesley, 2003

DeMarco, Tom and Plauger, P J Structured Analysis and System Specification. Prentice Hall PTR, 1979

要获得 DoD 标准 2167A 的联机副本，请访问 http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html。

脚注

1 很多人已经成功地将抽象层次应用于软件。Ed Yourdon 和 Tom DeMarco 在 1979 年提出了结构化分析和结构化系统设计的概念。美国政府的许多分支机构标准化了 DoD 的 2167A 标准，它要求系统由有层次的硬件和软件配置项组成。DBA 社区经常应用细节层次为关系数据库建模。特别地，Bachman 工具集和 James Martin 的信息工程方法学 (Information Engineering Methodology，IEM) 先为数据库逻辑建模，然后再为其物理建模。在 Google 上键入“software levels of abstraction”进行搜索会返回若干个结果，但其中大多数来自于学术社区，而且其内容看起来集中在正式计算机语言方面。

关于作者

Don Awalt 是 RDA Corporation 的创始人和 CEO，该公司是一家自定义软件工程公司，成立于 1988 年，在华盛顿特区、巴尔的摩、亚特兰大、费城和芝加哥都设有办事处。作为微软认证金牌伙伴 (Microsoft Gold Certified Partner)，该公司专注于使用 .NET Framework 开发企业 Web 和富客户端系统。Don 目前是 Microsoft 华盛顿特区的区域总监，他以前曾经担任费城首任区域总监。Don 经常在行业活动中演讲，这些活动包括 Tech Ed、Developer Days、MSDN 活动和各种 SQL Server 及 Windows 活动。他是 SQL Server Magazine 和 PC Tech Journal Magazine 的特约编辑，并且也为其它出版物撰写稿件。Don 所擅长的技术领域包括 Web 服务、SQL Server、现代编程语言的发展，以及在 Microsoft 的 Prescriptive Architecture Group (PAG) 中可以看到的许多体系结构和处理工作。可以通过 AWALT@rdacorp.com 联系到 Don。

Rick McUmber 是 RDA 的质量和最佳实践总监。他为 IBM 和 Rational Software Corporation 一共工作了 11 年，致力于为美国运输部、国防部、NASA 和加拿大国防部开发系统。从 1994 年以来，他一直在 RDA 工作，致力于为其客户开发业务解决方案。可以通过 McUmber@rdacorp.com 联系到 Rick。

转自： CSDN

说说大型高并发高负载网站的系统架构

转自：Just Do IT (http://www.toplee.com) lee@toplee.com

我在Cernet做过拨号接入平台的搭建，而后在Yahoo3721负载搜索引擎前端平台开发，又在猫扑处理过大型社区猫扑大杂烩的架构升级等工作，同时自己接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，可以和大家一起探讨一下。

一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

1、HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、图片服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群和库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。

问题果真出在这，我在运行MySQL-python-1.2.1_p2时，运行python setup.py install,c出现了以下咚咚：

最后还出现一个错误：

没搞明白，为什么还需要.Net Framework SDK框架，这个不是.net的吗，这边有什么作用？？

风向标 兄推荐了用 这个安装MySQL-python.exe-1.2.0.win32-py2.4.exe ，一运行就OK了，不要在install，继续下一步研究中…… 非常感谢~^_^~

运行出来的心情真好 [lol] ，后面不知道还会遇到什么困难，不过车到山前必有路，相信很快就会有些成果了~ [cool]

后面的就是熟悉一下流程，感觉还是比较比较容易上手，按照limotou的教程，第一个Wiki我已经编译出来，这可能是最简单的了，但是出来了一个小例子，就是离成功又进了一步~现在已经有点感觉了~

在学习的过程中遇到的问题

1。一个就是Template出错问题，这个刚开始一直不知道为何，后来一查，是因为Django把原来默认的.html模板取消了，而limotou 的教程还没改过来，~把相对应得py文件里面默认的文件，加上模板后缀名就OK了

2。中文乱码问题，这个后来也解决了，是因为模板文件用的是ANSI格式,转为UTF-8就可以了，但是里面有些中文还没搞定~

目前还得暂时放一下，因为为了学习Python、Django，已经把科研放了很久了，今天一规划，发现还有很多事情需要做，得赶快抓紧，还好这些东西，都是在我事先规划好的形成，可以互为借鉴，目前我把我们要做的已经尽最大努力往这方面靠，目前就是开发语言不一样而已，科研上用的可能会是ASP，但是数据库我还是选择MySQL ,功能上就是一个我们策划的项目的简化版，希望能把一切都协调好~尽快出成果~3D学习跟上~ [sweat]

在google的 python 论坛列表里面看到的一些关于3D跟python的结合，比较兴趣，我后面想做就是如何把3D整合在Python里面，能不能整合问题，心里还没什么底，现在看来还是可以实现的，把一些相关讨论先放在这里，有空可以学习一下~

of leading open source 3D engines, such as Nebula and Crystal Space, haven't yielded anything. I'm now starting to look at non-game applications.

To the best of my knowledge, there's only a few where the engine itself is written in Python:

* Alice — I believe early versions used to be written in Python to
a Direct3D API, think they've been moving away from that in later
versions, possibly toward a Java implementation?
* OpenGLContext — my testing/demo environment for PyOpenGL, which
is based loosely on a VRML97 scenegraph model (and includes simple
VRML97 loaders and the like).
o Provides Transform,Group,Switch,
PointLight,SpotLight,DirectionalLight, Background, Shape,
Appearance, Material, ImageTexture, TextureTransform,
IndexedFaceSet, IndexedLineSet, PointSet, Box, Sphere, Text,
FontStyle, Polyline2D, NurbsCurve2D, Contour2D,
NurbsSurface,TrimmedSurface, and NurbsCurve nodes (some with
only partial support, it should be noted)
o Has basic navigation, polygon tessellation, transparency and
selection passes
* ZOE is apparently written in Python, never played with it. Claims
to focus on wireframes and particle systems.
* VisualPython (VPython) may have some significant portion of the
code in Python, but I can't say how much (or indeed whether there
is any).

However, these engines (save maybe ZOE, about which I know next to nothing) are focused primarily on teaching, rather than game or application development. Particularly given your legendarily high standards, I think you'll find that none are sufficient for your needs wrt building practical 3D apps in Python. The collective wisdom on that would seem to be "wrap a C/C++ engine if you need any sort of interactive speed on a non-trivial application".

If you do find any other engines, consider adding them to the list here:
http://www.py3d.org/py3d_zwiki/Python3dLinks
(the formatting is messed up, but the information is often useful). [/quote]