利用“4+1”视图建模方法进行“网上选课系统”软件体系结构设计
基于UML4+1视图和概念模型的建模方法
基于UML4+1视图和概念模型的建模⽅法RUP的4+1视图包括： 逻辑视图：关注功能性的、整个系统的抽象结构，不涉及具体的编译即输出和部署。
开发视图：是逻辑视图的实现，描述程序⽣成多少个exe、dll、jar、配置⽂件等。
⼜叫实现视图。
运⾏视图：关注程序运⾏时各个⼦系统、组件之间的交互策略。
如多进程、多线程，⽣产者-消费者模式。
运⾏视图⼜称过程视图。
部署视图：关注软件交付以后在机器上的部署形态，以及和上下⽂的关系。
⼜称物理视图。
⽤例视图：关注需求，⼜叫场景视图。
RUP 4+1视图相对完整的描述了从需求分析到系统设计的过程，但没有专门针对数据持久层的描述。
温li在软件架构设计中⽤数据视图替换了⽤例视图，应该说他相对重视架构设计，对需求关注的少⼀些。
关于需求的描述⽅法，应当清醒的看到，仅仅通过⽤例视图是不够的，⽤例技术涉及、但⽆法全⾯涵盖⾮功能需求。
需求 = 功能 + 质量+ 约束。
⼤量的信息还是要通过详细的⽂字描述才能够讲清楚。
⽤例视图只不过提供了描述了⼀个软件的需求概貌。
除了⽤例视图以外，还应该关注软件的概念模型（⼜称领域模型、信息模型）。
如果说⽤例着重于描述⼀个个具体的需求，概念模型则从业务的⾓度描述了整个软件系统所要完成的功能中涉及的所有概念以及彼此之间的关系。
例如对于⼀个⽹管系统，核⼼的两个概念是设备和端⼝，端⼝从属于设备，他们之间是多对⼀的关系。
分别详述4+1视图：逻辑视图关注的静态元素是：层、⼦系统、类、接⼝，⽤类图来描述。
关注的动态因素是协作关系，⽤时序图、协作图、状态图等来描述。
是否需要在架构设计中体现类和类之间的关系？这取决于设计的层级。
开发视图关注的元素是程序包（SDK、解析器、中间件）、⽂件组织结构、编译依赖关系、⽬标单元（jar、exe、dll等）。
它和逻辑视图的静态元素通常有映射关系。
运⾏视图关注进程、线程、对象等运⾏时概念，以及相关的并发、同步、通信等问题。
运⾏架构和开发架构的关系：开发架构⼀般偏重程序包在编译时期的静态依赖关系，⽽这些程序运⾏起来之后会表现为对象、线程、进程，运⾏架构⽐较关注的是这些运⾏时单元的交互问题。
4+1模型学生信息管理系统分析与设计
“4+1”模型学生信息管理系统分析与设计“4+1”模型概述Kruchten在1995年提出了“4+1”的视图模型。
“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。
1，逻辑视图逻辑视图(logic view)主要支持系统的功能需求，即系统提供给最终用户的服务。
在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图(class diagram)来描述逻辑视图。
可以从Booch标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用Rational Rose 进行体系结构设计。
类图用于表示类的存在以及类与类之间的相互关系，是从系统构成的角度来描述正在开发的系统。
一个类的存在不是孤立的，类与类之间以不同的方式互相合作，共同完成某些系统功能。
关联关系表示两个类之间存在着某种语义上的联系，其真正含义要有附加在横线之上的一个短语来予以说明。
在表示包含关系的图符中，带有实心圆的一端表示整体，相反的一端表示部分。
在表示使用关系的图符中，带有空心圆的一端连请求服务的类，相反的一端连接提供服务的类。
在表示继承关系的图符中，箭头由子类指向基类。
逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问是要保持一个单一的、内聚的对象模型贯穿整个系统。
对于规模更大的系统来说，体系结构级中包含数十甚至数百个类。
2，开发视图开发视图(development view)也称模块视图(module view)，主要侧重于软件模块的组织和管理。
软件可以通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。
基于“4+1”视图模型的学生信息管理系统的分析与设计
基于“4+1”模型的学生信息管理系统的分析与设计Based on the "4 + 1" model students' information management system analysis and design摘要：随着计算机的发展以及网络技术的应用，当今社会正快速向信息化社会迈进，信息自动化融人日常生活中，使人们从烦琐的事务中解放出来.随着高校招生规模的不断扩大，面对庞大的信息t，需要一个学生信息管理系统来提高对学生信息管理的工作效率。
本文以UML描述为基础，建立学生信息管理“4+1”视图模型，从系统的多个视图描述软件体系结构出发以后提高软件开发效率、平均软件质量与开发周期的矛盾。
Absract:With the development of the computer and network technology application,today's society is rapidly to the information society forward，the information automation into daily life，make people in the affairs of loaded down with trivial details from liberating. With the constant expansion of college enrollment，facing huge informationt, need a students' information management system to improve the students' information management work efficiency.This paper described in UML，based students' information management "4 + 1" view model，from the system of more views describe software system structure of improving the efficiency of software development，after an average software quality and development cycle of conflict.关键字：“4+1”视图模型学生信息管理系统建模语言The Unified Modeling Language（UML）Keywords:The "4 + 1" view model Students' information management system Modeling Language The Unified Modeling Language (UML)随着学校的规模不断扩大,学生数量急剧增加,有关学生的各种信息量也成倍增长。
体系结构蓝图—软件体系结构的4 1视图(中文版)
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry 和Wolfe 使用一个精确的公式来表达，该公式由Boehm 做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
我们用由多个视图或视角组成的模型来描述它。
为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图1）：∙逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
体系结构蓝图—软件体系结构的41视图（中文版）
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的 Abowd& Allen、SEI 的Clemen ts。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry和 Wolfe使用一个精确的公式来表达，该公式由 Boehm做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
4 1体系结构视图PPT课件
举例：用例模型中添加通信关联的指向 执行者启动用例
订货
客户
系统启动用例
客户
获得订单的状态
由客户或者系统 启动用例
客户
获得订单的状态
Yourdon的OOA方法
以类与对象图及对象状态图为辅助工 具，建立问题域的五层模型.
OOA模型被划分为五个层次 (五个视图)
OOA的结构
Class &object layer (类及对象层)
帐册
前班节余 销售事件表 收入累计 上交款 本班节余
接班 计帐 报帐交班
@上级系统接口
帐目目册
@消息发送
查帐 报帐 价格更新 种类增删
供货员
缺货登记表 缺货登记 供货
建立数据字典
为所有模型实体准备一个数 据字典, 精确描述每一个对象 类,包括:
•成员 •约束 •关联、属性、操作
对象字典举例：
类名 父类 提供的服务 需要的服务
分析 模型 出纳员接口
吐钞器
设计 模型
显示
吐钞传感器
提取 帐户
提取
帐户
数字键盘
吐钞输送器 储户管理
永久类
读卡机
点钞机
事务管理 帐户管理
《分析子系统》 TM接口
出纳员接口
《分析子系统》 控制逻辑
《分析子系统》 帐户管理
提取
吐钞器
转帐
帐户
出纳员
存入
有三个子系统的分析模型,在影射到设计模型 之前需要把分析类型分解到各个分析子系统中
从一般类发现特殊类
公司职员
姓名 身分证号码
股份 工资 ……
？ …… ？
股东 股份
五个步骤常根据需要交叉进行
软件体系结构 4+1模型案例
案例教学1：4+1视图方法进行软件体系结构设计要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。
1、呼唤体系结构设计的多重视图方法灵感一闪，就想出了把大象放进冰箱的办法，这自然好。
但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。
需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。
以工程领域的例子开道吧。
比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
图1 软件需求分类的复杂性2、超市系统案例：理解需求种类的复杂性例子是最好的老师。
为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。
在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
表1 超市系统案例：理解需求种类的复杂性简单而言，功能需求就是"软件有什么用，软件需要做什么"。
选课系统体系结构设计
选课系统体系结构设计一、引言选课系统是现代高等教育中必不可少的重要组成部分，它为学生提供了方便、快捷的课程选择途径，同时也为学校和教职工提供了管理和分配资源的手段。
本文将针对选课系统的体系结构进行设计，旨在提供一个高效、稳定和可扩展的系统架构。
二、系统需求分析1. 用户需求选课系统的用户主要包括学生、教职工和管理员。
学生希望能够方便地查看和选择自己的课程，教职工需要能够发布和管理课程信息，管理员则需要具备对整个系统进行维护和管理的权限。
2. 功能需求选课系统应该具备以下功能：- 学生能够浏览、搜索和筛选课程信息；- 学生能够选择和退选课程；- 教职工能够发布和管理课程信息；- 系统能够自动进行选课结果的计算和统计；- 系统能够处理选课冲突和资源分配问题；- 管理员能够管理用户、课程和系统设置；- 系统能够提供数据备份和恢复功能。
3. 性能需求选课系统需要具备以下性能要求：- 快速响应：系统对于用户的请求需要有较快的响应速度，尽量减少等待时间；- 稳定可靠：系统应当具备高可用性和容错机制，确保系统能够持续稳定地运行；- 可扩展性：系统应能够根据需求的增加灵活地进行扩展，保证系统的性能和效率。
三、系统架构设计基于对选课系统需求的分析，我们提出了以下的系统架构设计方案：1. 前端设计前端是用户与系统进行交互的界面，对于选课系统而言，前端应具备良好的用户体验和友好的界面设计。
我们可以采用现代前端框架进行开发，如React、Angular等，以实现前后端分离和页面的动态渲染。
2. 后端设计后端负责处理前端的请求，并与数据库进行交互。
我们可以采用分布式架构，将后端拆分为多个服务，提高系统的性能和并发处理能力。
常用的后端开发框架有Spring Boot、Django等，可以根据具体需求进行选择。
3. 数据库设计选课系统的数据库设计对于系统的稳定性和数据一致性至关重要。
我们可以使用关系型数据库如MySQL或非关系型数据库如MongoDB，以满足系统的需要。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
利用“4+1”视图建模方法进行“网上选课系统”软件体系结构设计所学专业：软件工程年级班级： 2010级软工-2 班所属小组：第六组组负责人：耿奇云组内成员：耿奇云郜振南杨建威成员学号: 1010107041 1010107040 1010107054河南农业大学信息与管理科学学院2012年12月19日一、引言(一)运用4+1视图方法：针对不同需求进行架构设计要开发出用户满意的软件并不是件容易的事，软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
Philippe Kruchten提出的4+1视图方法为软件架构师"一一征服需求"提供了良好基础，如图1示。
图1运用4+1视图方法针对不同需求进行架构设计场景视图：场景视图关注案例描述，即对案软件需求的功能描述和非功能描述；对应于UML建模中的用例建模。
逻辑视图：逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。
开发视图：开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。
开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
处理视图：处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。
处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图：物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。
物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
(二)软件需求分类需要架构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。
软件需求包括功能需求和非功能需求。
非功能需求包括质量属性和约束条件。
质量属性包括运行期质量属性和开发期质量属性。
软件需求分类如图2所示。
图2 软件需求分类(三)网上选课需求1．网上选课系统需求描述管理员通过系统管理界面进入，建立本学期要开设的各门课程，并将课程信息保存到数据库中，并可以对课程进行一定的改动和删除操作。
学生通过浏览器可以查询已选课程信息并进行选课，教师可以选择所要上的课程并提交所选课程的成绩。
管理员同时负责维护各项信息。
以上信息统一保存到数据库中。
2．网上选课系统需求表1 网上选课系统：需求种类分析二、网上选课系统场景建模场景视图：场景视图关注案例描述，即对案软件需求的功能描述和非功能描述；对应于UML建模中的用例建模。
(一)用例建模与分析步骤根据网上选课系统需求概述进行用例建模与分析。
用例建模与分析步骤如图3示。
1.确定网上选课系统的边界范围，找出系统外部的参与者和外部系统2.确定各个参与者应有的系统行为，并命名为用例3. 把系统中公共的系统行为分解为新的用例，供其它用例引用4. 把系统中一些变更的行为分解为扩展用例5. 编制用例的脚本6. 绘制系统的用例图7. 把系统用例中特殊情况的用例画成单独的子用例图(二)用例建模具体过程1.确定系统边界范围，找出参与者系统参与者包括：管理员、学生和老师管理员学生老师系统图42.确定每一个参与者所希望的系统行为管理员：登陆、课程管理、学生管理和老师管理学生：登录、选课、查询课程老师：登录、查询课程、提交成绩图53. 把公共系统行为分解为新的用例将管理员、学生和老师的登陆抽取为公共用例；管理员学生系统老师课程管理学生管理登录老师管理查询课程提交成绩选课<<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>><<uses>>图64. 扩展用例将所有操作保存的用例扩展为数据库。
图75.用例图优化抽取用户角色，实现统一登录；抽取课程管理用例，与学生信息管理、教师信息管理等用例并列图86.用自然语言和事件流编写网上选课用例脚本（1）用户登陆脚本：1）运行程序，弹出登录界面；2）在登陆界面输入用户名、密码和用户类型；3）提交信息进行验证；A1：用户信息验证异常4）进入操作界面。
A1：用户信息验证异常3a）提示用户用户名或密码或用户类型错误3b）重新输入用户名、密码和用户类型3c）转到3）老师的选课脚本：一、(1)运行程序，弹出登陆界面，（2）在登陆界面输入用户名、密码和用户类型；（3）提交信息进行验证；A:用户信息验证异常（4）进入操作界面。
A：用户信息验证异常1、提示用户用户名或密码或用户类型错误2、重新输入用户名、密码和用户类型3、转到（3）二、（1）登陆成功后，在选课界面进行选课；（2）选择课程，单击完成，系统进行验证；A1：课程信息异常，重新进行选课；（3）选课成功；（4）退出程序；老师的提交成绩脚本如下：（1）用户登陆界面后输入用户名、密码和用户类型；（2）提交信息进行验证：如果信息异常系统将退出，用户需重新登陆（3）用户登陆成功后进入学生成绩界面，并提交学生的成绩，因此显示选课学生的姓名、学号、班级、成绩；（4）系统确认输入的信息完整没有缺失或错误；（5）系统将输入的学生成绩存储建档；（6）用户提交成绩成功后退出程序。
若提交失败将退回（3）；学生的选课教本：（1）用户登陆界面后输入用户名、密码和用户类型；（2）提交信息进行验证：如果信息异常系统将退出，用户需重新登陆（3）用户登陆失败将返回（1），登陆成功后进入学生选课系统；（4）学生选择所要选择的课程后提交，系统将确认改门课程是否已满；A：若所选课程人数已满，选课失败，返回（3）重新选课；若选课成功，则系统将会把改课程添加到学生的课程表里；（5）用户退出程序；学生的查询课程教本：（1）用户登陆界面后输入用户名、密码和用户类型；（2）提交信息进行验证：如果信息异常系统将退出，用户需重新登陆;（3）用户登陆失败将返回（1），登陆成功后进入学生主页查询课程；（4）用户退出程序管理员的教师信息教本：（1）用户登陆界面后输入用户名、密码和用户类型；（2）提交信息进行验证：如果信息异常系统将退出，用户需重新登陆;（3）用户登陆失败将返回（1），登陆成功后进入管理员主页；（4）管理员在主页上进行教师的信息管理操作；（5）用户推出程序；管理员的教师信息教本：（1）用户登陆界面后输入用户名、密码和用户类型；（2）提交信息进行验证：如果信息异常系统将退出，用户需重新登陆;（3）用户登陆失败将返回（1），登陆成功后进入管理员主页；（4）管理员在主页上进行学生的信息管理操作；（5）用户推出程序；管理员的教师信息教本：（1）用户登陆界面后输入用户名、密码和用户类型；（2）提交信息进行验证：如果信息异常系统将退出，用户需重新登陆;（3）用户登陆失败将返回（1），登陆成功后进入管理员主页；（4）管理员在主页上进行课程管理界面进行相应的操作；（5）用户推出程序；7.绘制用例图根据分析与描述，本网上选课系统的用例图如下图10三、网上选课系统逻辑视图逻辑视图：逻辑视图对应于功能需求，设计满足功能需求的架构。
逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。
首先根据功能需求进行初步设计，进行大粒度的职责划分。
根据用例描述，将系统划分为6层，如图？所示。
图？网上选课系统架构的逻辑视图四、网上选课系统开发视图开发视图：开发视图对应于开发期质量属性，设计满足开发期质量属性的架构，包括扩展性、可重用性、可移植性、易理解性和易测试性等。
开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。
开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
软件架构的开发视图应当为开发人员提供切实的指导。
任何影响全局的设计决策都应由架构设计来完成，这些决策如果"漏"到了后边，最终到了大规模并行开发阶段才发现，可能造成"程序员碰头儿临时决定"的情况大量出现，软件质量必然将下降甚至导致项目失败。
其中，采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台，都应该考虑是否由软件架构的开发视图确定下来。
图*展示了网上选课系统的（一部分）软件架构开发视图：数据库层持久层与连通层（DAO）商务逻辑层会话层表示层应用层StrutsSpringHibernate图* 网上选课系统架构的开发视图在说说约束性需求。
约束应该是每个架构视图都应该关注和遵守的一些设计限制。
例如，考虑到"一部分开发人员没有嵌入式开发经验"这条约束情况，架构师有必要明确说明系统的目标程序是如何编译而来的：图**展示了整个系统的桌面部分的目标程序pc-moduel.exe 、以及嵌入式模块rom-module.hex 是如何编译而来的。
这个全局性的描述无疑对没有经验的开发人员提供了实感，利于更全面地理解系统的软件架构。
图** 网上选课系统架构的开发视图五、网上选课系统过程视图处理视图：处理视图，即过程视图，设计满足运行期质量属性的架构，对应于运行期质量属性，包括易用性、性能、可伸缩性、持续可用性、鲁棒性和安全性等。
处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。
处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
性能是软件系统运行期间所表现出的一种质量水平，一般用系统响应时间和系统吞吐量来衡量。
为了达到高性能的要求，软件架构师应当针对软件的运行时情况进行分析与设计，这就是我们所谓的软件架构的处理视图的目标。
处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。
图展示了网上选课系统架构的处理视图。