Ⅰ 如何读懂Web服务的系统架构图
大数据数量庞大，格式多样化。大量数据由家庭、制造工厂和办公场所的各种设备、互联网事务交易、社交网络的活动、自动化传感器、移动设备以及科研仪器等生成。它的爆炸式增长已超出了传统IT基础架构的处理能力，给企业和社会带来严峻的数据管理问题。因此必须开发新的数据架构，围绕“数据收集、数据管理、数据分析、知识形成、智慧行动”的全过程，开发使用这些数据，释放出更多数据的隐藏价值。
一、大数据建设思路
1）数据的获得
四、总结
基于分布式技术构建的大数据平台能够有效降低数据存储成本，提升数据分析处理效率，并具备海量数据、高并发场景的支撑能力，可大幅缩短数据查询响应时间，满足企业各上层应用的数据需求。
Ⅱ web 应用架构图 用什么软件
Dreamweaver,俗称DW网页制作软件
Ⅲ web在实际应用中主要包含哪几个方面
1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
2、表单测试
当用户给Web应用系统
管理
员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、性能测试
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3、压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的”拼音与语法检查”功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓”相关文章列表”。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
四、客户端兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
Web应用系统的安全性测试区域主要有：
（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
Ⅳ Web应用框架的架构
基于请求的框架较早出现，它用以描述一个web应用程序结构的概念和传统的静态Internet站点一样，是将其机制扩展到动态内容的延伸。对一个提供HTML和图片等静态内容的网站，网络另一端的浏览器发出以URI形式指定的资源的请求，Web服务器解读请求，检查该资源是否存在于本地，如果是则返回该静态内容，否则通知浏览器没有找到。Web应用升级到动态内容领域后，这个模型只需要做一点修改。那就是web服务器收到一个URL请求（相较于静态情况下的资源，动态情况下更接近于对一种服务的请求和调用）后，判断该请求的类型，如果是静态资源，则照上面所述处理；如果是动态内容，则通过某种机制（CGI、调用常驻内存的模块、递送给另一个进程如Java容器）运行该动态内容对应的程序，最后由程序给出响应，返回浏览器。在这样一个直接与web底层机制交流的模型中，服务器端程序要收集客户端籍get或post方式提交的数据，转换，校验，然后以这些数据作为输入运行业务逻辑后生成动态的内容（包括HTML、JavaScript、CSS、图片等）。
基于组件的框架采取了另一种思路，它把长久以来软件开发应用的组件思想引入到web开发。服务器返回的原本文档形式的网页被视为由一个个可独立工作、重复使用的组件构成。每个组件都能接受用户的输入，负责自己的显示。上面提到的服务器端程序所做的数据收集、转换、校验的工作都被下放给各个组件。现代web框架基本上都采用了模型、视图、控制器相分离的MVC架构，基于请求和基于组件两种类型大都会有一个控制器将用户的请求分派给负责业务逻辑的模型，运算的结果再以某个视图表现出来，所以两大分类框架的区别主要在视图部分，基于请求的框架仍然把视图也就是网页看作是一个文档整体，程序员要用HTML、Javascript和CSS这些底层的代码来写“文档”，而基于组件的框架则把视图看作由积木一样的构件拼成，积木的显示不用程序员操心（当然它们也是由另一些程序员开发出来的），只要设置好它绑定的数据和调整它的属性，把他们大大从编写HTML、Javascript和CSS这些界面的工作中解放出来。 基于请求的和基于组件的两种框架各有优劣。虽然一眼看上去后者有很大的吸引力，普通的web开发人员只要使用专门的公司或开源组织提供的组件就可以轻松开发出好用漂亮的界面，但是有几种因素综合起来不利于这种理想中的方案。要编写一个没有潜在问题的、跨浏览器的、显示美观并且有足够灵活性可以调整的服务器端组件是需要高水平的技能、丰富的经验和较多时间的，即使付出这些成本，也不能完全避免使用者失望的情况。
综合来看，基于请求的框架要程序员自己动手的地方比较多，但也因此可以更精细地控制HTML、CSS和Javascript这些最终决定应用程序界面的代码，特别是如果要在界面上有创新，尝试新的视觉效果和用户操作，必然选择基于请求的框架。基于组件的框架可以提高开发界面的效率，前提是选用的组件质量优秀。
Ⅳ web应用包括什么
常见的计数器、留言版、聊天室和论坛BBS等，都是Web应用程序，不过这些应用相对比较简单，而Web应用程序的真正核心主要是对数据库进行处理，管理信息系统（Management Information System,简称MIS）就是这种架构最典型的应用。
一个Web应用程序是由完成特定任务的各种Web组件（web components)构成的并通过Web将服务展示给外界。在实际应用中，Web应用程序是由多个Servlet、JSP页面、HTML文件以及图像文件等组成。所有这些组件相互协调为用户提供一组完整的服务。
(5)web应用结构图扩展阅读
web应用缺点
1、网络应用程序强调浏览器的适用性。如果浏览器方没有提供特定的功能，或者弃用特定的平台或操作系统版本（导致不适用），就会影响大量用户；
2、网络应用依靠互联网远程服务器端的应用文件。因此，当连接出问题时，应用将不能正常使用。但是，如果使用HTML5 API，这些应用就可以被下载安装而可离线使用。
3、许多网络应用程序不是开源的，只能依赖第三方提供的服务，因此不能针对用户定制化、个性化，而且大多数情况下用户不能离线使用，因而损失了很多灵活性；
4、它们完全依赖应用服务商的可及性。如果公司倒闭，服务器停止使用，用户也无法追索以前的资料。对比而看，即使软件制造商倒闭了，传统的安装软件也可以继续运行，尽管不能再更新或有其他用户服务。
Ⅵ 简述web技术的结构
它是超级文本的简称。 二、超媒体（hypermedia） 超媒体是超文本（hypertext）和多媒体在信息浏览环境下的结合。它是超级媒体的简称。用户不仅能从一个文本跳到另一个文本，而且可以激活一段声音，显示一个图形，甚至可以播放一段动画。 Internet采用超文本和超媒体的信息组织方式，将信息的链接扩展到整个Internet上。Web就是一种超文本信息系统，Web的一个主要的概念就是超文本连接，它使得文本不再象一本书一样是固定的线性的。而是可以从一个位置跳到另外的位置。可以从中获取更多的信息。可以转到别的主题上。想要了解某一个主题的内容只要在这个主题上点一下，就可以跳转到包含这一主题的文档上。正是这种多连接性把它称为Web。 三、超文本传输协议（HTTP） Hypertext Transfer Protocol超文本在互联网上的传输协议。 当你想进入万维网上一个网页, 或者其他网络资源的时候，通常你要首先在你的浏览器上键入你想访问网页的统一资源定位符（UniformResourceLocator)，或者通过超链接方式链接到那个网页或网络资源。这之后的工作首先是URL的服务器名部分，被名为域名系统的分布于全球的因特网数据库解析，并根据解析结果决定进入哪一个IP地址(IP address)。 接下来的步骤是为所要访问的网页，向在那个IP地址工作的服务器发送一个HTTP请求。在通常情况下，HTML文本、图片和构成该网页的一切其他文件很快会被逐一请求并发送回用户。 网络浏览器接下来的工作是把HTML、CSS和其他接受到的文件所描述的内容，加上图像、链接和其他必须的资源，显示给用户。这些就构成了你所看到的“网页”。 大多数的网页自身包含有超链接指向其他相关网页，可能还有下载、源文献、定义和其他网络资源。像这样通过超链接，把有用的相关资源组织在一起的集合，就形成了一个所谓的信息的“网”。这个网在因特网上被方便使用，就构成了最早在1990年代初蒂姆·伯纳斯-李所说的万维网。 传统的Web数据库系统体系结构 传统的Web数据库系统一般实现Web数据库系统的连接和应用可采取两种方法，一种是在Web服务器端提供中间件来连接Web服务器和数据库服务器，另一种是把应用程序下载到客户端并在客户端直接访问数据库。中间件负责管理Web服务器和数据库服务器之间的通信并提供应用程序服务，它能够直接调用外部程序或脚本代码来访问数据库，因此可以提供与数据库相关的动态HTML页面，或执行用户查询，并将查询结果格式化成HTML页面。通过Web服务器返回给Web浏览器。最基本的中间件技术有通过网关接口CGI和应用程序接口API两种。 （一）、基于通用网关接口CGI CGI是WWW服务器运行时外部程序的规范，按照CGI编写的程序可以扩展服务器的功能，完成服务器本身不能完成的工作，外部程序执行时间可以生成HTML文档，并将文档返回WWW服务器。CGI应用程序能够与浏览器进行交互作用，还可以通过数据库的API与数据库服务器等外部数据源进行通信，如一个CGI程序可以从数据库服务器中获取数据，然后格式化为HTML文档后发送给浏览器，也可以将从浏览器获得的数据放到数据库中。几乎使用的服务器软件都支持CGI，开发人员可以使用任何一种WWW服务器内置语言编写CGI，其中包括流行的C、C、VB和Delphi等。 从体系结构上来看，用户通过Web浏览器输入查询信息，浏览器通过HTTP协议向Web服务器发出带有查询信息的请求，Web服务器按照CGI协议激活外部CGI程序，由该程序向DBMS发出SQL请求并将结果转化为HTML后返回给Web服务器。再由Web服务器返回给Web浏览器。这种结构体现了客户/服务器方式的三层模型，其中Web服务器和CGI程序实际起到了HTML和SQL转换的网关的作用。CGI的典型操作过程是：分析CGI数据；打开与DBMS的连接；发送SQL请求并得到结果；将结果转化为HTML；关闭DBMS的连接；将HTML结果返回给Web服务器。 基于Web的数据库访问利用已有的信息资源和服务器。其访问频率大，尤其是热点数据。但其主要的缺点是：①客户端与后端数据库服务器通信必须通过Web服务器，且Web服务器要进行数据与HTML文档的互相转换，当多个用户同时发出请求时，必然在Web服务器形成信息和发布瓶颈。②CGI应用程序每次运行都需打开和关闭数据库连接，效率低，操作费时；③CGI应用程序不能由多个客户机请求共享，即使新请求到来时CGI程序正在运行，也会启动另一个CGI应用程序，随着并行请求的数量增加，服务器上将生成越来越多的进程。为每个请求都生成进程既费时又需要大量内存，影响了资源的使用效率，导致性能降低并增加等待时间；④由于SQL与HTML差异很大，CGI程序中的转换代码编写繁琐，维护困难；⑤安全性差，缺少用户访问控制，对数据库难以设置安全访问权限；⑥HTTP协议是无状态且没有常连接的协议，DBMS事务的提交与否无法得到验证，不能构造Web上的OLTP应用。 （二）、基于服务器扩展的API 为了克服CGI的局限性，出现的另一种中间件解决方案是基于服务器扩展API的结构。与CGI相比，API应用程序与Web服务器结合得更加紧密，占用的系统资源也少得多，而运行效率却大大提高，同时还提供更好的保护和安全性。 服务器API一般作为一个DLL提供，是驻留在WWW服务器中的程序代码，其扩展WWW服务器的功能与CGI相同。WWW开发人员不仅可以API解决CGI可以解决的一切问题，而且能够进一步解决基于不同WWW应用程序的特殊请求。各种API与其相应的WWW服务器紧密结合，其初始开发目标服务器的运行性能进一步发掘、提高。用API开发的程序比用CGI开发的程序在性能上提高了很多，但开发API程序比开发CGI程序要复杂得多。API应用程序需要一些编程方面的专门知识，如多线程、进程同步、直接协议编程以及错误处理等。目前主要的WWWAPI有Microsoft公司的ISAPI、Netscape公司的NSAPI和OReily公司的WSAPI等。使用ISPAI开发的程序性能要优于用CGI开发的程序，这主要是因为ISAPI应用程序是一些与WWW服务器软件处于同一地址空间的DLL，因此所有的HTTP服务器进程能够直接利用各种资源这显然比调用不在同一地址空间的CGI程序语句要占用更少的系统时间。而NSAPI同ISAPI一样，给WWW开发人员定制了NetscapeWWW服务器基本服务的功能。开发人员利用NSAPI可以开发与WWW服务器的接口，以及与数据库服务器等外部资源的接口。 虽然基于服务器扩展API的结构可以方便、灵活地实现各种功能，连接所有支持32位ODBC的数据库系统，但这种结构的缺陷也是明显的：①各种API之间兼容性很差，缺乏统一的标准来管理这些接口；②开发API应用程序也要比开发CGI应用复杂得多； ③这些API只能工作在专用Web服务器和操作系统上。 （三）、基于JDBC的Web数据库技术 Java的推出，使WWW页面有了活力和动感。Internet用户可以从WWW服务器上下载Java小程序到本地浏览器运行。这些下载的小程序就像本地程序一样，可独立地访问本地和其他服务器资源。而最初的Java语言并没有数据库访问的功能，随着应用的深入，要求Java提供数据库访问功能的呼声越来越高。为了防止出现对Java在数据库访问方面各不相同的扩展，JavaSoft公司指定了JDBC，作为Java语言的数据库访问API。 采用JDBC技术，在JavaApplet中访问数据库的优点在于：直接访问数据库，不再需要Web数据库的介入，从而避开了CGI方法的一些局限性；用户访问控制可以由数据库服务器本地的安全机制来解决，提高了安全性；JDBC是支持基本SQL功能的一个通用低层的应用程序接口，在不同的数据库功能的层次上提供了一个统一的用户界面，为跨平台跨数据库系统进行直接的Web访问提供了方案。从而克服了API方法一些缺陷；同时，可以方便地实现与用户地交互，提供丰富的图形功能和声音、视频等多媒体信息功能。 JDBC是用于执行SQL语句的Java应用程序接口API，由Java语言编写的类和接口组成。Java是一种面向对象、多线程与平台无关的编程语言，具有极强的可移植性、安全性和强健性。JDBC是一种规范，能为开发者提供标准的数据库访问类和接口，能够方便地向任何关系数据库发送SQL语句，同时JDBC是一个支持基本SQL功能的低层应用程序接口，但实际上也支持高层的数据库访问工具及API。所有这些工作都建立在X/Open SQL CLI基础上。JDBC的主要任务是定义一个自然的Java接口来与X/OpenCLI中定义的抽象层和概念连接。JDBC的两种主要接口分别面向应用程序的开发人员的JDBC API和面向驱动程序低层的JDBC DriverAPI。JDBC完成的工作是：建立与数据库的连接；发送SQL语句；返回数据结果给Web浏览器。
Ⅶ web应用的网络拓扑结构图怎么画
用visio，再下思科设备visio图标画得快还非常漂亮。
注意可以下载visio 2013 但是必须是批量注册版本，后面才好用工具激活。
不然就用2007版本 有绿色版本的。
Ⅷ 简述WEB系统的架构原理
这个话题太大了。
一般来说，WEB系统，主要是指后端，前端就是各种浏览器了。
那么简单来讲，只要是能与浏览器通过网络交互的系统，都可以算是WEB系统。最简洁的就是用NODEJS写一个echo,就是客户端发什么内容，就回什么内容。
而在实际应用中，WEB系统的架构，一般有这么几个部分：负载均衡、授权验证（可选）、静态内容服务、动态内容服务（业务逻辑）、数据库、运维后台。
1）负载均衡是为了改善用户体验、充分利用服务器资源，主要功能是将新的请求转发到不那么忙的服务器进行处理。
2）授权验证，是在对浏览器发起的请求进行授权校验，如果不是合法的请求，就予以拒绝或者重定向至登录页面。
3）静态内容服务，是指图片、CSS等不会根据不同用户而变化的静态内容，将其直接返回给用户。因为不需要进行逻辑判断，性能主要取决于I/O读写，响应可以非常快。超大型网站，也会把一部分动态内容，例如对访问量大的新闻页，做静态处理，以提升响应速度。静态内容服务的典型是CDN。
4）动态内容服务，是根据用户请求的不同，而进行响应的业务逻辑处理。比如对用户数据的CRUD(增删查改）。这是绝大多数WEB系统的核心所在，一般会调用数据库和数据缓存。具体实现会根据业务需要而变化，也可以变得非常复杂。
5）数据库，是数据所在，既有经典的关系型传统数据库系统，也有为了提升访问性能、减轻的内存数据库。
6）运维后台，是为了方便监控运行状态、升级维护系统，不直接参与对外服务。
先写这么多吧。有具体的问题了，可以再问。
Ⅸ Web开发需不需要UML，软件工程
Web技术的发展，使得管理系统的开发更方便、功能更强大，在此系统的开发过程中，Web技术起了一个骨架式的支持作用；与此同时组件技术的发展为系统的开放性、集成性提供了便利，有效合理地引入组件技术是当前Web系统开发与发展的一个方向；通过对系统的开发进行建模，形象直观的图形化表示，可以显示系统的流程与功能。选择有效的建模方法，充分利用Web技术与组件技术，提高软件的开发效率，提高的软件的可靠性和可维护性，是每个软件开发人员所关心的问题。
UML(Unified Modeling Language)是基于对象技术的标准建模语言，定义良好、易于表达、功能强大的特点使它在面向对象的分析与设计中更具优势。在基于Web技术和组件技术的系统建模中，它完善的组件建模思想和可视化建模的优势更利于系统开发人员理解程序流程和功能，进一步提高Web系统的开发效率以及Web组件的可重用性和可修复性。
本文将结合我们自主开发的活塞PDM系统中的项目审批流程的建模，介绍UML在基于WEB技术和组件技术的系统建模中的应用。
2、基于Web的应用系统结构
对于基于Web技术的应用系统，用户直接面对的是客户端浏览器，用户在使用系统时，请求之后的事务逻辑处理和数据的逻辑运算由服务器与数据库系统共同完成，对用户而言是完全透明的。运算后得到的结果再通过浏览器的方式返回给用户。这个过程可分成一些子步骤，每一个子步骤的完成可理解为通过一个单独的应用服务器来处理，这些应用服务器在最终得到用户所需的结论之前，相互之间还会进行一定的数据交流和传递。图1就是Web的应用结构简图。
随着Web应用技术的发展，对Web数据流程的解释上还会有相应的改进或补充。
3、Web应用系统的UML建模方法
页面、脚本、表单和框架是Web应用系统的关键部分，数据流程的模型化表示关键就是用UML对上述Web元素应用及其关系建模，下面对这几种元素的模型化表示作一个简要介绍。
(1)页面建模。用户在使用Web应用系统时，是通过页面进行系统的操作。在页面建模中可用两个类别模板《Client Page》和《Sever Page》分别表示客户端页面和服务器端页面。客户端页面的属性是页的作用域中定义的变量，方法是页面脚本中的函数；服务器页面的属性是页面脚本中的变量，方法是脚本中定义的函数。在使用页面信息传递时，还可能出现服务器页面的重定向，在UML建模中，用类别模板《redirect》来表示；对于客户端页面和服务器页面的构造关联用类别模板《bulid》表示，这种关联是一种单向关联，由服务器页面指向客户端页面，具体表示如图2所示。
在Web应用系统中，还会经常用到的就是超级链接，在UML建模中，用类别模板《link》表示超级链接，它的参数模拟为链接属性。
(2)表单建模。用户的要求一般通过表单与数据库交互。在UML建模中，表单用类别模板《form》表示，属性是表单中的域，表单没有方法。表单在处理请求时，要与Web页面交流数据，这个交流过程是用提交按钮submit来完成，为了在建模中表示这种关系，用类别模板《submit》表示。
(3)组件建模。在使用组件技术的Web应用系统建模中，对组件的建模是个重要环节，在UML基本的图形化建模元素中，设立了专门的组件图。组件在使用过程中，同样的分成了客户端组件(如Java Applet,ActiveX控件)和服务器端组件。在系统的UML模型化表示中，用类别模板《Client Component》表示客户端组件，用《Sever Component》表示服务器端组件。
(4)框架建模。框架通过定义类别模板元素《frameset》来实现，frameset指定并命名各个框架，每个框架容纳一个页面；框架的使用还涉及到目标target，建模时用《target》来表示。
4、UML在活塞PDM系统建模中的运用
活塞PDM系统是在传统PDM系统的基础上，引入了组件技术和Web技术，对数据流程的处理更趋于简易性和方便性。在对该系统的建模过程中，要体现整个系统前台与后台间数据交互的流程。在设计时，主要是考虑设计它的class diagram(类图)和component diagram(组件图),用这两类模型图来体现UML的用例驱动和系统组件结构的特性。由于在系统的开发中采用了模块化的设计方法，因此在构划模型图时，采用了先整体后局部的思路，首先考虑整个系统的案例图，再对子模块进行分析和设计，在每个子模块数据流的入口和出口设置模型图间数据交互的接口。下面以活塞PDM系统中项目审批流程子模块的建模为例说明UML在此系统建模中的应用。
4.1 项目审批流程
项目审批是项目管理流程的一部分，功能就是实现审批过程和数据传递的自动进行，取消了传统审批流程中大量纸质文件的使用。下面以活塞新产品开发的项目审批为例来说明UML对项目审批流程的建模方法。
活塞新产品开发的项目审批过程有7个环节组成，分别是项目申请、组织评审、制定实施方案、技术委员会及专家委员会评审、技术副总审核、总经理审核和董事会审核。通过这七个环节来决定一个项目实施的可行性或者合理性。
审批过程自动化的实现方法，是在Web技术和组件技术的基础上，对每一个环节设置了评审状态tag。当tag=1时，表明项目已通过该环节评审，可进入下步评审；当tag=0时，表明项目还未经过评审，或者未通过评审，需要返回去修改项目运行的可行性研究，等待再一次的评审。同时在每个环节进行评审时，还要考虑该项目是否已进入了下一级评审，如若项目已进行了下一级的评审，这时该环节的操作人员都无权再对该环节所填写的评审意见进行编辑。也就是在对每个环节进行维护时，还要考虑下一级的评审状态。
在建模之前，首先看一下项目审批流程图，如图3所示。
除了这七个审批环节，为了让用户及时了解交叉投入生产的项目审批或进展情况，提供了项目浏览功能，用户按照管理员所授予的权限，在权限范围内并且利用项目浏览子模块中提供的关键字段、项目评审状态或者进展状态进行分类检索。
在项目评审流程的每个环节，一般设置了两部分功能需求，即填写该环节评审的内容、编辑该环节评审的内容。
比如总经理评审环节，它的功能设置如图4所示。
为了实现网上审批的自动化，在整个流程的环节功能设置时，遵照了如下的规则要求：在每个环节的查看已填评审内容时，列出的项目都是正在等待进入该环节评审的项目，而不属于这种情形的项目在此环节中是显示不出来的；同样，对于在编辑此环节评审内容上，已经进行了下一级评审的项目也是不可能列出的，每个环节的负责人只可以对此环节以前的评审内容具有浏览功能，而不具备编辑功能。如果要查看整个项目的评审状况，在管理员授予项目浏览功能的权限下，通过项目浏览一项完成。
整个流程所包括的各个环节，在功能设置上是类似的，差异是评审环节在整个评审流程中所处的位置。在进行UML建模时采用了把这些环节分开的方法，先对每个环节建模，最后再把单个的环节模型图整合成一个完整流程的模型图。由于篇幅所限，下面以总经理评审的环节为例说明UML的建模方法。
4.2 总经理评审的类图(Class Diagram)
在项目审批流程中，设计了总经理审核环节的Class Diagram，如图（5）、图（6）、图(7)所示。图(6)和图(7)是图(5)的延续。该类图显示了总经理审核环节中各个页面之间的关系。为简化，在此类图中没有列出各个类的属性和方法。整个类图实现了查看已填写评审内容、填写总经理评审内容和编辑评审内容。
4.3 总经理评审的组件图(Component Diagram)
组件图是分析该环节所涉及的功能是如何实现的，这部分与具体的编码工作相关。总经理评审环节的模块组件图如图（8）所示。
4.4 由模型图到代码的转换
类图和组件图说明了在基于Web技术的信息交互流程，页面的超级链接和页间的重新导向在JSP代码设计中，由模型图就可以掌握它们之间交互的逻辑，这样使程序编写更富条理性和方便性。在实际工作中，可以设置为CRC卡，方便编程人员的使用。如若再比较详细地设计出对象图和顺序图，对于整个系统的类定义和方法设置，会提供更大的方便。
5、结束语
建模对系统的开发过程中起着很重要的作用，在系统的开发和维护中有必要建立系统的模型。UML是一种图示化的面向对象建模语言，它形象直观、应用广泛，并对Web技术和组件技术在系统开发中的建模方法有了比较合理有效的定义。在UML提供的各种模型图的基础上，还可以依照所有开发技术的特点对它的表示进行扩展，在本文的建模中就是用了UML的类别模块扩充机制，为某些模型元素添加新的语义，构造新的模型，来说明开发过程中的隐含特性。
通过利用UML建模，对基于Web的PDM系统中的项目审批流程进行了分析和设计，对整个流程的功能有了一个清晰的认识，利于开发人员对系统的开发与维护，同时可为系统的升级或者二次开发提供一个理论依据。