信息系统开发与管理实验报告4.doc

电 子 科 技 大 学 实 验 报 告 学生姓名： 学 号： 指导教师： 一、实验室名称：电子政务可视化实验室 1. 系统体系结构设计 （1）基本定义 系统体系结构也成为系统架构，是一个或一组结构，它包含组成系统的元素、这些元素对外可见的性质以及它们之间的关系，其中对外可见的性质指的是构成系统的元素能够提供的服务、性能特征、错误处理、共享资源的用法等。系统体系结构是最高层次的系统分解，从逻辑设计方面来讲，系统体系结构主要对系统的层、包、软件类、接口以及子系统的组织方式进行描述。 （2）系统体系结构设计的常见模式 分层技术是使用最广泛的系统架构设计方法，是一种将系统进行有效组织的方式。系统采用分层架构时，处于下一层的组件负责对上层组件提供服务，层与层之间通常是不透明的，每一层都具有独立的职责。分层结构描述的是设计元素在概念上的组织，是一种逻辑结构，而非物理上的部署。常见的分层结构有以下几种： 1) 三层模式 表现层——用于用户和信息系统之间的交互；业务逻辑层——含有信息系统所有和领域相关的工作；数据访问层——负责数据的持久化操作。在三层之间的依赖关系上，须保证表现层只依赖于业务逻辑层，业务逻辑层只依赖于数据访问层，不能反向依赖。 2) MVC模式 MVC（Model-View-Controller）也包含三层结构：模型——提供视图层进行展示的数据，不包含业务逻辑，也不包含数据读取功能；视图——提供了展示模型数据的不同方式；控制器——调用并协调需要的资源/对象来执行用户请求。 3) C N层模式 当业务逻辑变得越来越复杂时，可以根据系统的实际情况或设计需求，进行进一步的分解扩展；进行更多层次设计的根本目的是对系统进行解耦，以保证系统整体架构的灵活性。 2. 绘制系统包图 实验三已经将类分为边界类、控制类和实体类三部分，在这一部分要基于已经给定的系统架构对原来的三个包进行修改，绘制新的系统包图。 3. 设计类 （1）设计类的基本概念 设计类，也成为软件类，常用于设计模型中，它可以一一映射到分析阶段的成果物上，具体来说就是分析类为设计类所需要的界面、逻辑和数据提供了很好的抽象基础，设计类可以非常容易和自然地从分析类中演化出来。设计类的主要任务包括确定设计类，并使用特定的实现语言描述其属性、方法和关系。也就是说设计类依赖于实现语言。除此之外，其还依赖于在系统架构设计中所选择的实现框架。主要任务包括获取设计类、属性的设计、方法的设计和类之间关系的设计。 （2）获取设计类 根据实验原理可得，设计类主要来源于分析模型中的分析类，根据所选框架技术和一些设计原则的要求，将分析类进行细化而来。因此，本步骤的获取设计类需要和实验三中的识别分析类相结合。 1）表现层的考虑 由系统体系结构的设计可知，表现层采用MVC架构，使用Struts2框架实现。因此，需要考虑Struts2框架所要求的类：控制器类——即ActionServlet类，已经由框架本身实现；模型类——主要是Action的子类；视图类——主要包括JSP等界面。 2）业务逻辑层的考虑 业务逻辑层主要对应于系统包图中的控制类。 3）数据访问层的考虑 在数据访问层，使用了Hibernate框架。为了使用上的方便，将Session对象的获取方式再次进行了封装，设计了一个名为HSessionFactory的类提供Session对象的获取操作。 4）业务实体层 业务实体层主要对应于系统包图中的实体集和系统中的业务主角和参与者。 5）交互图的更新 获取了设计类后，需要根据新的类将实现每个用例的交互方式进行细化。 （3）属性的设计 在设计属性这一过程中，需要详细定义类的属性，定义的内容包括属性的可见性、类型以及初始值。 其中可见性包括公有（+）、受保护（#）和私有（-）三种。一个属性的完整定义如下： 可见性 属性名：类型=初始值 属性设计的指导原则：仔细考虑类图中的属性，分析类的属性和软件类的属性并不都是一一对应的。有时，分析类的一个属性隐含着软件类需要有一个或多个属性；考虑属性的候选类型时，可以根据实际的编程语言来确定；如果一个设计类因为其属性的原因变得复杂而难以理解时，可以视具体情况将其中的一些属性分离出来形成单独的类。 （4）方法的设计 类的方法与类的职责密切相关，类的某项职责就是该类的对象应该执行的一个操作。一个类的所有操作需要支持该类在不同用例中担负的所有职责。因此，可以通过遍历所有的用例图和交互图，发送给某个类的所有消息的集合来找到该类必须定义的大多数方法。此外，还需要补充一些辅助方法。方法的定义格式如下： 可见性 方法名（方法参数列表）：类型表达式 （5）关系的设计 类之间的关系主要有依赖关系、泛化关系、关联关系和聚合关系等几种。其中，聚合