《软件架构设计》课程报告.docx

1、软件架构设计课程报告目录1 软件设计风格、软件应用框架和软件设计模式的特征和区别21.1 软件设计风格21.2 软件应用框架21.3 软件设计模式21.4 软件风格、应用框架和设计模式的区别21. 课堂考勤管理系统32.1 项目开发背景32.2 项目用户需求分析32.2.1 学生需求32.2.2 任课教师需求42.2.3 教学秘书功能要求42.2.4 辅导员用户需求42. 课堂考勤系统的软件架构、框架以及设计模式53.1 考勤系统的软件架构53.2 系统框架73.2.1 数据访问层部分代码：73.2.2 业务逻辑层：83.2.3 表示层：83.2.4 详细介绍93.3 设计模式103. 软件架

2、构对软件开发过程的作用及影响11131 软件设计风格、软件应用框架和软件设计模式的特征和区别1.1 软件设计风格体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器” 模式，则不必给出设计细节，我们立刻会明白系统是如何组织和工作的。1.2

3、 软件应用框架软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段， 这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。1.3 软件设计模式设计模式(英语 design pattern) 是对面向对象设计中反复出现的问题的解决方案。这个术语是在 1990 年代由 Er

4、ich Gamma 等人从建筑设计领域引入到计算机科学中来的。这个术语的含义还存有争议。算法不是设计模式，因为算法致 力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被 初学者和其他设计者掌握。设计模式还为软件重构提供了目标。1.4 软件风格、应用框架和设计模式的区别体系结构指的是构成系统的组成元素及其之间的关系，是形而上的东西。体系结构框架相对于体系结构更加务实，有些时候已经是一个半成品，可以在此基础上进行定制开发或二次开发。设计模式不同于体系结构（甚至可以说没有可比性，虽然定义上有些容易混淆），因为

5、它更加通用，是设计的通用解决方案和经验总结。举个例子来说，你可以说我们讨论一下某个系统的体系结构，但不能说 讨论一下某个系统的设计模式，最多只能说其中用到了多少种设计模式及其变体。1. 课堂考勤管理系统2.1 项目开发背景在课堂教学中，学生的考勤检查是一项很重要的内容。它能够实时的检查每一位学生的到课情况和听课情况，为学生的平时成绩做一个客观公正的参考。传统的学生出勤检查往往是教师拿着一张纸质名单逐一点名，或让学生上交课堂作业以便课后查询出勤情况。这些方法往往造成统计结果不及时，数据容易遗漏， 对学生进行教育难及时到位，甚至容易出现无法处分学生的现象，班主任、辅导员、教师、学生无法及时了解考勤

6、状况，监控失效。针对以上问题，开发基于 ASP.NET 的学生考勤管理与预警系统，任课教师可以在课堂上直接登录系统进行学生考勤检查并记录考勤信息。可以根据实际情况设置课程的缺勤预警条件，当某个学生的缺勤达到预警条件的时候，系统将列出学生的姓名等相关信息，使教师能够及时、直观地看到，对此类学生进行帮扶。此外，在课余，任课教师、班主任、辅导员及学校各级领导也可以登陆该系统查询学生的出勤情况。图 2-1 课堂考勤系统登录界面2.2 项目用户需求分析2.2.1 学生需求查看出勤信息需求：学生可以查看上课出勤的详细信息，如：具体某个个学期请假、旷课、迟到、早退了多少次，以及具体的时间、任课老师姓名、课程

7、名称等详细信息。其它需求：修改个人用户密码，查看本班课表安排。2.2.2 任课教师需求学生上课考勤需求：根据学校安排的课表，随着时间的变化，自动列出需要考勤的学生信息、课程信息、上课时间等信息，提交学生上课出勤情况。图 2-2 教师所授课程信息查询查看学生出勤信息需求：查看所教班级学生出勤统计信息及详细信息。设置考勤预警条件：对自己所教授课程设置预警条件，如：可以设置缺预警条件为 4 次，系统将会显示缺勤次数达到 4 次的学生的详细信息。其它需求：修改个人用户密码，查看本人课表安排。2.2.3 教学秘书功能要求系统管理员拥有系统的最高权限，负责系统运行必需数据维护，基本功能需求如下：维护教学秘

8、书信息、维护上课教室课表的信息、设置学期的开始时间， 结束时间，持续周数；设计教师检查考勤的有效时间段，如：如果设置有效时间为 10 分钟，则考勤有效时间为课程开始 10 分钟之内；设置数据可用性，如：设置2015-2016 年第一学期，2015-2016 年第二学期的数据可用，表示这两个学期的数据可用，其他学期的数据不可用。其他需求：修改个人用户密码。图 2-3 教学秘书课程信息维护2.2.4 辅导员用户需求查看学生出勤信息需求：查看所属院系班级学生的出勤统计信息及详细信息。设置考勤预警条件：对所属院系课程单一课程以及全部课程的预警条件，如：可以设置单一课程预警条件为 4 次，全部课程的预警

9、条件为 10 次，系统将会显示单一课程缺勤次数达到4 次，全部课程缺勤次数达到10 次的学生的详细信息。图 2-4 辅导员查看学生具体缺勤信息其它需求：修改个人用户密码。2. 课堂考勤系统的软件架构、框架以及设计模式3.1 考勤系统的软件架构应用软件开发通用的做法是将应用程序的实现分布在从底向高的三个层：数据访问层，业务逻辑层，表示层，如下图所示。数据访问层实现对数据库的操作， 这对于特定 DBMS 是固定的，不需更改的；业务逻辑层利用数据访问层实现业务逻辑，这层是关键，如果用户的业务需求改了，可以在这层中修改，因为这层有很多独立的方法，而且，改某个功能不会影响到别的功能；表示层调用业务逻辑层

10、实现用户的功能，只要业务逻辑层有这个功能，就可以调用，表示层只需提供输入输出和提示等。图 3-1 三层架构原理图本系统遵循三层架构，数据访问层的类，直接访问数据库，实现基本记录操作；业务逻辑层的类，调用相关的数据访问类，实现用户所需功能；表示层部署控件后，调用业务逻辑层的类，实现具体功能。将应用程序的功能分层后，对于固定的 DBMS，数据访问层基本可以不变，一旦用户的需求改变，修改业务逻辑层，表示层稍做改动即可。这种做法使程序的可复用性、可修改性，都得到了很好的改善，大大提高了软件工程的效率。网站采用 SQL Server 2014 数据库，名称为 KQGL，包含表如下图所示图 3-2 数据库

11、表图具体表介绍：在本系统中实体模型包括系统管理员表（ tb_manager ）、 系别表（ tb_department ）、 专业班级表（ tb_professional ）、 教学年度学期表（tb_annual）、学生信息表（tb_student）、教师信息表（tb_teacher）、课程表（ tb_course ）、 班 级 课 程 表 （ tb_professionalCourse ）、 教 师 课 程 表（tb_teacherCourse）、教室信息表（tb_classroom）、教学秘书信息表（tb_dean）、辅导员信息表（tb_assistant）、各系学生考勤表（tb_chec

12、kOnWorking_*_*）、预警信息表（ tb_alert ）、预警条件表（ tb_alertSet ）、考勤有效时间表（tb_validTime）、课程安排信息表（tb_CourseDetail）。教师存储过程信息介绍：表 3-1 教师存储过程信息表序号名称1GetCheckedProfessional2345teacherLogin,teacherInsert teacherSelectByDepartmentId teacherUpdate说明得到按系别的已经考勤完毕的专业，教师考勤一半退出系统再次登录时考勤完毕的专业不再写入缓存教师登录添加教师信息得到某系的全部教师更新教师信息67

13、891011teacherDeleteById删除教师信息teacherChangePwd教师更改登录密码teacherSelectById按教师编号得到教师teacherGetIdByname按教师的姓名得到 IDteacherSelectAll得到全部教师信息teacherCourseSelectCourseNameById 查询某教师的该学期所授的全部课程3.2 系统框架高校学生考勤系统是采用三层架构实现的， 系统包含 8 个项目。BusinessLogicLayer 是业务逻辑层； DALFactory 是数据访问层的抽象工厂； DBHelper 是 数 据 访 问 基 础 类 ； I

14、DAL 是 数 据 访 问 层 的 接 口 定 义 ； E:CheckOnWorkWebSite3 是表示层，是系统的 UI 部分，负责使用者与整个系统的交互；Model 是实体层；SQLServerDAL 是数据访问层，操作 SQL Server 数据库；WebConfig 系统配置层。系统各项目的依赖关系如下图所示。图 3-3 系统各项目的依赖关系下面从教师的例子中看一下这三层之间的调用关系3.2.1 数据访问层部分代码：#region 更新教师信息/ / 更新教师信息/ / Teacher对象/ public int Update(Teacher teacher)SqlParameter

15、 param = new SqlParameter(teacherID,teacher.teacherID),new SqlParameter(teacherName,teacher.teacherName), new SqlParameter(teacherPwd,teacher.teacherPwd), new SqlParameter(departmentID,teacher.departmentID),new SqlParameter(teacherTitleName,teacher.teacherTitleName), new SqlParameter(teacherPhone,te

16、acher.teacherPhone),new SqlParameter(teacherEmail,teacher.teacherEmail);return ExecuteNonQuery(StoredProcedureName.teacherUpdate,param);#endregion3.2.2 业务逻辑层：/ / 更新教师信息/ / Teacher对象/ public int Update(Teacher teacher)return dal.Update(teacher);3.2.3 表示层：表示层负责直接和用户交互。一般就是指系统的界面，用于数据的录入，显示等功能。图 3-4 教师

17、信息维护界面后台 cs 代码：protected void ImageButton1_Click(object sender, ImageClickEventArgs e)CheckOnWork.Model.Teacher teacher2 = new Teacher(Label1.Text,txtName.Text,teacher.teacherPwd,Convert.ToInt32(SessiondepartmentId), txtTitle.Text, txtPhone.Text, txtEmail.Text);int sign = tBll.Update(teacher2); if (

18、sign = 1)Response.Write(alert(更新成功);/添加成功则清空行else Response.Write(alert(更新失败，请仔细核对信息);3.2.4 详细介绍实体层一个数据库表、视图等的逻辑映射，在系统中起一个数据传输的作用。实体层中包含系统的实体类，实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。DBHelper 项目可以包含操作各种数据库的 Helper 类，不同数据

19、库的 Helper 类的方法基本相同，本系统采用的是 SQLServer 数据库，所以 DBHelper 项目只有一个类SQLHelper。如果还需要操作其他数据库，例如 Oracle 数据库，可以添加 OracleHelper 类SqlHelper 类通过一组静态方法封装了数据访问功能，这些方法调用起来非常方便。该类是抽象类不能被继承或实例化。在 SqlHelper 类中实现的方法包括： ExecuteNonQuery 方法用于执行不返回任何行或值的命令，通常用于执行数据库的添加和更新；ExecuteReader 方法用于返回 SqlDataReader 对象，该对象包含由某一命令返回的结果

20、集；GetDataSet 方法返回 DataSet 对象，该对象包含由某一命令返回的结果集；ExecuteScalar 方法返回一个值，该值始终是该命令返回的第一行的第一列；PrepareCommand：此方法为执行命令准备参数。IDAL 是数据访问层的类要实现的一组接口。数据访问层的各类需要完成对数据库的访问，但是不同的数据库需要使用不同的数据访问对象，这样对于业务逻辑层来说无法实现数据库无关性，为了实现数据库无关性，可以将数据访问层对象转化为他所实现的接口类型，这样就和具体的数据库访问对象无关了，也就是说数据访问层对象实现 IDAL 接口，上层程序在使用时不直接使用数据访问层对象，而是使用

21、 IDAL 接口，从而使得整个数据访问层有利于数据库迁移。IDAL 要达到的目的是：实现业务逻辑与数据库访问层的完全分离。IDAL 的创建方式与 Model 类似，不同之处在于 Model 最后一步创建的是类，而 IDAL 创建的是接口。BusinessLogicLayer 业务逻辑层包含了整个系统的核心业务，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。在业务逻辑层中，不能直接访问数据库，而必须通过数据访问层。对数据访问业务的调用，是通过接口项目 IDAL 来完成的。既然与具体的数据访问逻辑无关，则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现，只要不涉

22、及到 IDAL 的接口定义，那么业务逻辑层就不会受到任何影响。WebConfig 项目只有一个类 Config，这个类用来读取表示层中 Web.config 配置文件中的配置信息，其中 SQLServerConString 是 SQL Server 数据库的链接字符串，在SQLServerDAL 项目中使用。WebDal 是数据访问层的程序集名称，在DALFactory 项目中使用。如果数据库更换为 Oracle，只需更换为 Oracle 数据库的链接字符串，OracleDAL 数据访问层的程序集名称即可。SQLServerDAL 项目中的类要实现 IDAL 项目中相对应的接口，其中包含的逻辑

23、就是对数据库的 Select，Insert ，Update 和 Delete 操作。本系统采用的是SQL Server 数据库，所以创建了 SQLServerDAL 项目。如果还需要操作其他数据库，例如 Oracle 数据库，可以创建了 OracleDAL 项目。前面提到的数据库的更换，实现的关键就在于此项目。DALFactory 项目中我们使用反射和抽象工厂来实例化数据访问层的类对象。实现方法是：通过WebConfig 项目的Config 类读取表示层中Web.config 配置文件中程序集名称信息 ， 然 后 使 用 反 射 来 实 例 化 数 据 访 问 层 的 类 对 象 ， ITea

24、cher dal=(ITeacher)Assembly.Load(“程序集名称”).CreateInstance(“程序集名称”.“要实例化的类名”)。此方法可以根据程序集名称和类名动态实例化数据访问层的类对象，实现数据库的无缝切换。3.3 设计模式抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式可以向客户 端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对象。根据里氏替换原则，任何接受父类型的地方，都应当能够接受子类型。 因此，实际上系统所需要的，仅仅是类型与这些抽象产品角色相同

25、的一些实例，而不是这些抽象产品的实例。换言之，也就是这些抽象产品的具体子类的实例。工厂 类负责创建抽象产品的具体子类的实例。例如本系统中的：namespace CheckOnWork.IDALpublic interface ITeacher/得到某系的教师IList GetTeachersByDepartment(int departmentId);/添加教师信息int Insert(Teacher teacher);/更新教师信息int Update(Teacher teacher);/删除教师信息 int Delete(string id);/教师修改密码int ChangePwd(st

26、ring id, string pwd);/检查此教师编号是否存在bool CheckTeacher(string id);/按编号查找教师CheckOnWork.Model.Teacher GetTeacherById(string teacherId);/按教师名查找教师IList GetTeacherIdByName(string name);/ 查 询 全 部 教 师 IList GetTeacherAll();public Teacher(string id,string name,string pwd,int departmentId,string title,string pho

27、ne,string email)this._teacherID=id; this._teacherName=name; this._teacherPwd=pwd; this._departmentID=departmentId; this._teacherTitleName=title; this._teacherPhone=phone; this._teacherEmail=email;实现了教师类的封装与继承。3. 软件架构对软件开发过程的作用及影响课堂考勤管理系统是我学习 ASP.ENT 以来做的第一个完整的项目，虽然我只是负责处理一些逻辑代码，但是从整个项目的设计过程，开发流程感受到三

28、层架构带来的优点，本系统遵循三层架构，数据访问层的类，直接访问数据库，实现基本记录操作；业务逻辑层的类，调用相关的数据访问类，实现用户所需功能； 表示层部署控件后，调用业务逻辑层的类，实现具体功能。将应用程序的功能分层后，对于固定的 DBMS，数据访问层基本可以不变，一旦用户的需求改变，修改业务逻辑层，表示层稍做改动即可。这种做法使程序的可复用性、可修改性，都得到了很好的改善，大大提高了软件工程的效率，如果你不考虑到分层，你就会发现有时候你的工作要重新返工， 你敲了好几天的代码可能就要全部删了重新修改，但是这样可能会加大代码的编写量，其次时间安排要合理，因为三层之间还是有影响的，你要了解到每一

29、层他 传递的参数的类型，个数以及需不需要返回值等等；还有就是如果你注释清晰， 函数名类名规范，从表示层你更清楚的看到这个页面具体实现的逻辑结构和框架， 具体是怎么实现的，实现的过程放在了业务逻辑层，在就是复用性方面有了很大 的提高，很多管理系统无非就是对数据库进行增删改查操作，有时这些操作都是 类似的，你只需要写一个公共类里面的函数，给他传值调用就可以，这样节省了 开发时间。架构体现了结构化的设计思想 ：首先,根据系统分析的要求以及可以利用的资源对软件的总体结构进行大致的功能设计。这是宏观的、全局的规划和设计 , 要充分考虑各方面情况 。接着将功能复杂、繁多的总体结构按功能分解为子结构,各子结

30、构功能总和为上层结构 的总的功能。如果分解得到的子结构比较 复杂,功能较多,可将子结构再分解为结构更简单,功能更单一的子结构,以此类推 , 直至分解出的子结构功能比较容易实现,分解的子结构也容易实现。软件架构带来模块化的设计思想：将系统设计成由若干模块组成的方法称为模块化 。各模块之间相对独立,实现功能单一,彼此间通过接口进行相互调用。每个模块可以单独的被理解、编写、调试、查错与修改。这样一来,可以简化开发、维护工作,防止错误蔓延,提高软件的可靠性。最后感谢学院为我们开了这门课程，我们觉得学习软件架构很有必要，非常感谢王老师的谆谆教导，教给我们的更多是方法和经验，从王老师的例子中去体会架构，才会觉得这些架构更有实际意义，王老师通过专题的形式总结了一些常用的数据库设计，开发中的一些架构等等；而且老师对我们每一次研讨提出了意见和建议，这样通过互动方式，能收获更多，你能从其他组里面学到一些东西， 也能从老师的点评以及和其他组对比里面反思一些东西，都是有价值的。参考文献：1 王彦良,蒋远辉.几种软件体系结构风格论述 J.信息通信,2015,(第 4 期).2 戚继宏.软件体系结构风格及其应用J.网络安全技术与应用,2014,(第12 期).3 陈长喜.ASP.NET 程序设计基础教程.清华大学出版社，2011，（第二版）4 张利兵.软件架构中的关键因素J. 电脑与电信. 2009(08)