其他分享
首页 > 其他分享> > 信息系统分析与设计 第九章 系统设计概述

信息系统分析与设计 第九章 系统设计概述

作者:互联网

文章目录

系统设计的任务要求

通俗地说,设计就是要回答“怎么做”
完成技术实现方案的制定,即信息系统的物理模型
-一个逻辑模型,可以提出多个物理模型
-根据物理模型进行实施,得到最终的物理系统

系统设计的目标
-设计系统之前,先看看评价信息系统的标准,这些标准对任何设计方法都适用:
信息系统的功能:是否满足用户的需求
系统的效率:响应时间、操作的方便性
系统的可靠性:抗干扰能力、故障恢复
系统的工作质量:准确性、使用效果
系统的可变更性:修改和维护的难易程度
系统的经济性:系统收益与支出比
-与需求相同,设计的重点也在于软件,因为相对软件,硬件方案的复杂度和多样性较小。

信息系统的可变更性
变化是不变的真理。
统计表示:在信息系统的整个生命周期中,系统维护成本占总成本的80%左右。
因此,可变更性是衡量信息系统设计的重要指标。

良好的结构设计
-结构简单
系统各组成元素分工明确,易于理解
元素之间的关系清晰简洁
-变动灵活
谨防软件维护中的“水波效应”(一石激起千层浪)
使系统各组成元素内部的改变容易实现,改动对其它部分的影响尽量减少
提前考虑将来最易出现的扩展和变更

1、低劣设计带来的问题
糟糕的软件设计可能包含以下症状:
僵化性(rigidity):系统很难改变,即使一个简单的改动也会导致大量有耦合关联的其它部分的连锁反应。
脆弱性(fragility):改变系统的某个部分,会破坏许多无关的其它部分。
固化性(immobility):系统各部分紧密联结无法分开,很难将系统分解成可供其它系统重用的部件。
粘滞性(viscosity):当软件需要改动时,设计不容易保持稳定,逐渐脱离最初的设计思路而走样,造成软件不同版本之间存在较大差异。
不必要的复杂性(needless complexity):过度设计,很多非常聪明的超前的结构目前还不需要,什么时候需要不得而知。
不必要的重复性(needless repetition):因为忽视抽象而使很多代码看上去是重复的,将来修改一处时,导致多处修改。
晦涩性(opacity):很难阅读、理解,不能很好地表现出设计者的意图,难以与需求规格描述进行对照。
-一个低劣的建筑设计方案,技艺高超的工匠也无法造出精品。

2、基本设计方法
为了设计出结构良好的系统,方法如下:
(1) 把系统划分为一些部分,其中每一部分的功能简单明确,内容简明易懂,易于修改。这样的组成单元可以是模块、类、组件、服务和子系统。
(2) 系统功能单元的划分按层次进行。整个系统分解成若干子系统,然后每个子系统按功能再分解为更小的功能单元(如菜单项、人机窗口界面、业务功能组件等),依次下去。最底层的基本单元可以设计成一个函数、子过程、或类的一个方法。
(3) 每一个功能单元应尽可能封装为独立的元素,对外提供必要的使用接口,隐藏内部的数据、算法等实现细节,并尽可能减少各单元间的控制关系和数据交换,使得系统各部分之间是松耦合的状态。“独立而不孤立”
(4) 各功能单元对外的接口、以及相互间的控制和依赖等关系要阐明。这样,在修改时可以追踪和控制。

3、系统设计师的素质要求
创造性设计思维;
丰富的编程经验和很强的逻辑思维能力;
具备将复杂的问题分解成简单问题的能力,设计易于使用和维护的软件结构,并保证较好的重用性;
应对系统结构尤其是软件结构具有较强美感,善于运用巧妙优美的设计模式;
应有大局观,懂得平衡各种开发局限的制约,权衡时间、进度成本与系统质量、性能等因素提出最佳方案。

从分析过渡到设计
分析的目标是做正确的事(do the right thing)
设计工作就是正确地做事(do the thing right)
分析与设计任务和目标不同,但在一些软件开发过程方法(如敏捷方法)中,分析和设计可能没有严格的阶段管理。
-因为工作内容或模型有较强关联,分析到设计的建模过程某种程度上是一个从粗到精、不断构思和设计、推翻或优化、从抽象到具体的过程。
-例如分析阶段建立了领域对象模型,完成了对领域对象最本质和核心的分析和抽象,设计阶段还会基于该模型进一步修正和完善(对需求的认识可能不是一步到位的)。

系统设计的内容

一般划分为两部分:
总体设计
-设计软件的体系结构(也称架构,architecture)
-设计软件结构,即具体组成元素及其关系(structure)
-设计系统对外接口和服务
详细设计
-各项具体细节,涉及软硬件的各个方面

软件结构的演变
粒度越来越大,范围越来越广
在这里插入图片描述
基于模块封装的软件结构
采用强调自顶向下、逐层分解的功能模块设计,也称为结构化设计。主要包括:
-将系统划分成功能模块(Module);
-决定每个模块的功能;
-决定模块的调用关系;
-决定模块的界面(Interface,接口),即调用时传入的信息(函数参数),以及返回的信息(返回值)。
主要模型:模块结构图(SC,Structure Chart),也称功能结构图。
设计依据:数据流图(结构化方法)

基于对象封装的软件结构
强调面向对象的封装,主要包括:
-识别系统中的对象(Object),设计类(Class);
-决定每个类的属性(Attribute)和操作(Operation);
-决定对象之间的协作/通信关系;

主要模型:类图(Class Diagram)
-类的方法本质上也是模块封装

设计依据:领域类图、用例图、状态图

基于服务封装的软件结构
-从概念上讲,SOA中有三个主要的抽象级别元素:
操作:代表单个逻辑工作单元的事务。SOA操作可以与面向对象中类的方法相提并论。
服务:代表操作的逻辑分组。例如,如果我们将客户信用视为服务,则按照客户名称获得客户信用数据、建立信用记录、更新客户信用等就代表相关的操作。
业务流程:为实现特定业务目标而执行的一组长期运行的动作或活动,如:批准一项贷款、本科生转专业、完成订单等。业务流程可以通过编排一组服务来定义和实现。
底层基于主要模型:构件图(Component Diagram)/OMG SoaML/Business Process Modeling Notation(BPMN)等 (Music Natation是什么?)
类来实现
-设计依据:业务流程图、数据流图、用例

软件设计的两类模型
软件模型最主要的两个方面:
静态模型,用于表示软件结构,即组成元素及其关系,又划分为两种:
-一种是开发态(编辑态)的源程序的结构,一般采用模块结构图(结构化方法)和类图(面向对象方法)描述
-一种是运行态(发布态)的构件结构,即程序打包编译后的文件或组件的结构(Component,如html、jar、dll) ,一般采用构件图描述
动态模型,用于表示软件执行动作的步骤和流程控制。
-程序流程图(结构化方法) 、顺序图(面向对象方法)

详细设计内容
包括:
输入设计
输出设计
人机交互设计(用户界面设计)
模块处理过程详细设计/类及用例的详细设计
数据库设计
事物代码体系设计
计算机系统和网络设计

系统设计说明书

设计完成,提交系统设计书,两种形式:
单册报告,分章节介绍系统架构、总体结构、编码体系、输入/输出、人机交互、数据库、网络等各部分内容
多册,以上各部分单独书写成册,如总体设计报告、用户界面设计报告、数据库设计报告、网络详细设计报告等

标签:信息系统,软件结构,第九章,模型,系统,模块,设计,方法
来源: https://blog.csdn.net/LoraRae/article/details/111551548