软件设计规范

3星(超过75%的资源)
所需积分/C币:18 2018-01-22 15:09:56 531KB PDF
23
收藏 收藏
举报

软件设计规范文档编写,可以按照这个编写软件设计规范文档,
Alexander's Document 1简介 1.1目的 规定了一个设计模型所应具备的基本元素及其结构,统一对设计工具使用的方式,以便使 项目成员将沟通的重点放在如何实现用户需求上,并便于同类项目之间的比较和参考 1.2范围 木规范采用了面向对象的设讣方法(0OD, Object Oriented design),针对应用型项目, 可根据项日的特殊需求作对本规范中制定的设计模型作适当扩充或裁减 1.3定义和首字母缩写词及缩略语 模型元素/ model element:模型元素用于表示从正在建模的系统中提取的抽象概念。 接口/ interface:一个指定的、表小元素行为特征的操作集。 关系/ relationship:模型元素间的语义连接。举例来说,关联关系和泛化关系就是两 种关系。 类/ class:对于一组具有共冋属性、方法、关系和语义的对象的描述。类可使用一组接 口米指定它提供给其环境的操作集合 包/ package:将元素分组的一种通用机制。包之间可进行嵌套 子系统/ subsystem:一种模型元索。它具有包的话义,这样就可以包含其他模型元素, 也具有类的语义,这样就具有了行为。子系统的行为由它所包含的类或其他子系统提供。 子系统实现一个或多个接口,这些接口定义子系统可以执行的行为。 用例实现/use- case realization:用例实现描述如何在设计模型内部使用协作对象米 实现一个特定用例。 视图/vieW:模型的简化说明(抽象),即采取特定角度或观点并忽略与相应角度或观 点无关的实体。 设计模式/ design pattern:设计模式为改进软件系统的子系统、构件或其间的关系提 供了方案、它描述了一组相互通信的构件间的、可重用的结构,能在特定情境中解决常 見旳设计问趨。设计模式是中小规模的模式,其规模比构架模式较小,但通常独立于编 稈语言。当设计模式的范闱界定之后,它将形成一部分具体的设计模型。设计模式所在 的层次决定了它趋向于可在多个领域中应用。设计模式可有效地提高软件的质量。 模型视图控制器/MvC/ Model-view- Controller:最常见的一种构架模式。用于分解应用 程序构件的应用程序构架。模型代表业务逻辑以及数据;视图代表用户界面;控制器用 」管理用户交互,同吋在某些情况下管理和分发应用程序流/请求。在分析类的设汁中 一般而言,模型表示为实体类( entity),视图表示为边界类( boundary),控制器表 示为控制类( control)。 1.4参考资料 《设计模式》: Erich garuna, Richard heli, Ralph johnson and John Vlissides1994 Design Patterns-Elements of Reusable Object-Oriented Software. Addison Wesley Longman. 2007 By hugi Alexander's Document <Rational Unified Process): Rational Software Corporation, Rational Unified Process2000.02.20.038.001 2软件设计质量要求 以卜要求是设计所要达到的目标,当这些目标不能同时达到时,按其优先顺序实现。 1)保证到用户需求的可追踪性 2)元整实现需求 3)保证设计模型正确。如果设计模型实现∏只实现了用例模型所述的功能,则设计模型即 是正确的 4)概要设计和详细设计,各视图之间必须保持一致 5)保持表述的清晰和简单 6)为组织提供可重用的设计模型 7)冇意识地应用设讣模式的思想,常用的设讣模式可作为设计模型的单元,其名称可作为 标准词江 8)总结出新的设计模式 3软件设计表示方式 设计模型采用“1+4”模式,即用例视图+(1逻辑视图,2进程视图,3部署视图,4数据 视图) 对于业务型项目:在所有视图中,要首宄完成用例视图。用例应在需求阶段完成,然后作 为设计阶段的核心输入。 于形台技术型项门:需求以待征列表的形式表示。并在逻视图中针对特征列表中每 待征描述其行为机制和技术实现模式描述段可以是序图,活动图等,也可以是其他天段描 述的行为机制。如宋该特征是用现有纽什的特,在描述时可以不详细描述其行为机制,但需 将所引组件提供的特征这些将红的使用方法述清楚。在设计时如出现无法用ME具描述 清楚的项订以加入附件(使用其他子段的描述文件)。 设计阶段结東时,原则上这5种视图都被包含在设计模型中。在一些特殊情况下,某些视 图可能是不必要的,能否剪裁和剪裁的条件如下: 3.1用例视图(可选) 此视图在业务型项目中必选,在平台型项目中可选视图。 32逻辑视图(必选) 此视图是必需的。 3.2.1用例实现(或特征描述及实现)(必选 对」业务型项目:从实现用户需求的角度看,用例实现是最重要的设计元素。对」用例模 型内的每个用例,设计模型都必须存在一个用例实现。它们之间有在一种实现关系。 对于形台技术型项月:在辑视图中计利特征列表中每一特征(必须全部盖)描述其行 为机制和技术实现模式。据述天段可以是的序图,活动图等,也可以技用其他段来描述行为机 制。如米该特征是引用现有组件的特征,在描述的可以不详细述其行为机制,但需将所列组件 2007 4/37 By hugi Alexander's Document 提供的特征及这些特征的使用方法述清楚。在没计的如出现无法用RSE具描述清楚的项可 以加入所件(用其他手段的描述文件)。每一个特征至少有一张图成件描述机制和技术实 现模式的该描述图(或的件)中覆盖后续设计的所有类子系统,这块证!设计元素的可追 碳性,是从需求向设计转移的关键环节。 以下内容可选实现 用例实现拥有的类图:对于每个用例实现(或特征描述及实现)而言,都可以用一个或多 个类图来描述它的参与,即分析类图。 用例实现拥有的协作图和时序图:对于每个用例实现(或特征描述及实现),都必须用 个或多个交互图来描述它的参与对象以及它们之间的交互。用例实现拥有的交互图表示了设计模 型的动态行为。交互图分为时序图和协作图两类。若采用时序图,对其中的每一组MVC模式,边 界类的对象放在最左边,控制类的对象放在中间,实体类的对象放在右边。 3.2.2子系统和包(必选) 用子系统和包来组织用例实现的参与类。类及其对象通常参与几个用例实现。类及其对象 在不同用例实现(或特征描述及实现)中可能存在不同的需求,因此必须有一个集中的地方来收 集这些需求。一个类必须且只能属于一个子系统或包。用例实现和其他的包若用到该类,只能对 其引用而不能拥有。每个子系统和包都要有名称和简要说明。 以下内容必须实现 类:类的名称、简要说明、公有的属性和方法定义准确。类功能的划分遵循MC模式。其 中的实体类来源于对用例的分析得出的业务对象( Business0 bject),边界类和控制类是为了 在系统内操作实体类的对象而衍生出来的。 以下内容可选实现。 类的状态图:用来表小类的内部行为。对于实体类,可用来表示其对象的生命周期。 子系统和包的类图:对子系统和包中的类都应该出现在图中,类与类之间的关系应该明确 和详细 3.2.3逻辑视图的类图(可选) 画出所有的子系统和包,表明它们之问的关系和接口,即设计类图。 33进程视图(可选) 此视图为可选视图。仅当系统具有多个控制线程并且各个独立线程相互作用或相互依赖时, 才使用此视图。如果系统仅采用单控制线程,则不需要“进程视图” 34部署视图(可选) 此视图为可选视图。仅当系统分布在多个节点上时,才使用此视图。即使是这样,也仅当 分布会影响构架时才使用部署视图。例如,如果有单个服务器和许多客户机,那么只有在将服务 器和客户机的职责描绘成节点类时才需要使用部署视图:如果客广机节点具有相同的功能,则无 须一一显示各客户机节点 单CP系统不需要“部署视图” 2007 5/37 By hugi Alexander's Document 3.5数据视图(可选) 此视图为可选视图。除非对象永久性是系统的重要方面,并且永久性机制要求永久性对象 和非永久性对象之闫存在映射,否则不需要“数据视图 关系数据库设计是数据视图的部分,其表示用单独的文件保存(一般是 Power Designer 文件),其规范请参见《数据厍设计规范》。 4设计工具的使用 4.1工具选择 设计阶段的建模工具统一使用 Rational rose2002及其以上版本,不建议使用Word等工 具编辑设计文档,避免不一致,节省时间 4.2模板选择 在Rose中新建模型时,请选用模板。 此模板中预置了一个较全面地设计模型框架和显示样式,规范设计成果的统一样式。 4.3设计元素和模板元素的映射 本规范中元素在模板(软件设计规范.mdl)中的位置: 位置 备注 用例视图| Use case yiew\ Use-Case Model main AcTors和 Use cases的定义分别 拥有的用 放在 Use case view Use-Case 例图 Model \actors和 Use cases下 用例实现| ogical view Design Mode1 use case 选 和用例的 realizations use case name,use case 映射用例name> Realize dependencies 用例实现| Logical view\ Design Model\use case 拥有的类 realizationsuse case name) uIse case 图 name> Participating classes 用例实现| Logical view、 Design model\ use case 拥有的协 realizations 作图和时 name>Logical Instance 序图 子系统和| Logical view、 Design model\< Layer name> 包拥有的 Layerpackage name>package name 类图 Interfaces 逻辑视图| Logical view、 Design Model、M 可选 拥有的类 Alexander's Document 图 进程视图 Logical view、 Design Model\Process 选 拥有的类 view Mai 图 部署视图| Deployment View 可选 数据视图|使用 Power Designer绘制 Conceptual Dala可选 Mode1图 5设计图的基本规范说明 51外观约定 5.1.1图元属性 图元属性规范 尺寸 ROSE缺省尺寸 缺省填充色RGB(165,207,245)一一淡蓝 缺省字体新米体(五号)GB232 线条颜色RGB(0,0,0) 备选填充色⊥RGB(192,192,192)一-浅火,表示这版不需实现的功能组件 备选填充色2RGB(135,191,191)一一浅绿,区分功能区 各选填充色4RGB(183,183,219)一—淡青,区分功能区 5.1.2连接线画法 1.连接线必须为水平走线或者垂直走线,禁止走斜线 连接线必须为直线型,转弯必须是直角 Alexander's Document 3.多条连接线平行走线时,如果中间没有间隔的图元,必须保持这些平行线等距离走线 × 4.一般情况,避免珧线 5.1.3图元布局 1.图元的最小移动距离是5( Snap to grid) 2007 8/37 By hugi Alexander's Document 2.图元布局应尽量遵循对称原则,禁止无序摆放 3.应当将图元尽量平行的摆放在一条水平线和垂直线上 4.图元之问的问隔应该尽量保持相同的距离 5.应尽量将连接较多的对象摆放在靠中问的位置 A A 6.核心图元可以加大尺寸,以利于突出其地位 2007 9/37 By hugi Alexander's Document 7.如果图元上的连接线较多,可以加大尺寸,使布局更美观 ITEM 5.1.4典型的图纸效果 静态类图 NewPackage6 NewClass7 Newclass5 3 Newclass2 Newclass4 NewClass Newclass8 NewClass Newclass9 状态图 10/37

...展开详情
试读 37P 软件设计规范
立即下载 身份认证后 购VIP低至7折
一个资源只可评论一次,评论内容不能少于5个字
c663231 PDF文档,不怎么好修改自己想要的
2018-12-29
回复
您会向同学/朋友/同事推荐我们的CSDN下载吗?
谢谢参与!您的真实评价是我们改进的动力~
上传资源赚钱or赚积分
最新推荐
软件设计规范 18积分/C币 立即下载
1/37
软件设计规范第1页
软件设计规范第2页
软件设计规范第3页
软件设计规范第4页
软件设计规范第5页
软件设计规范第6页
软件设计规范第7页
软件设计规范第8页

试读结束, 可继续读4页

18积分/C币 立即下载