软件的什么设计又称为总体设计,其主要任务是建立软件系统的总体结...
6.l 系统总体结构设计 6.1.1 系统总体结构设计的任务 系统总体结构设计的任务,是根据系统分析的逻辑模型设计应用软件系统的物理结构。
系统物理模型必须符合逻辑模型,能够完成逻辑模型所规定的信息处理功能,这是物理设计的基本要求。
系统应具有可修改性,即易读,易于进行查错、改错、可以根据环境的变化和用户的要求进行各种改变和改进。
系统是否具有可修改性,对于系统开发和维护影响极大。
据统计,在系统生命周期中各阶段的应用软件费用及人力投入大体分布如下: 系统开发:20% 系统维护:80% 6.1.2 结构化设计的基本思想 1.结构化设计的要点 系统是否具有可修改性与其结构有着密切的关系。
“结构化设计” 的构想,成为系统设计的基本思想。
其要点如下: (1)模块化。
(2)由顶向下,逐步求精。
系统划分模块的工作应按层次进行:①把整个系统看做一个模块,然后把它按功能分解成若干第一层模块,它们各担负一定的局部功能,共同完成整个系统的功能。
②每个第一层模块又可以进一步分解成为更简单一些的第二层模块,越下层的模块,其功能越具体、越简单。
...
怎么理解"软件概要设计是系统总体结构设计或系统架构设计
软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系 统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。
在面向 对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。
特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。
但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在Rational Unified Process 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管 理软件产品的高级设计。
软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。
一般而言,软件系统的架构(Architecture)有两个要素: 它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。
详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(Task-flow)。
所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。
建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。
显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
设计软件结构的具体任务是什么?
一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。
具体地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(Task-flow)。
所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行具体设计甚至建造,这些决定就很难更改甚至无法更改。
显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代,历史非常短暂,而相比之下建筑工程则从石器时代就开始了,人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点,一是建筑风格,二是建筑模式。
独特的建筑风格和恰当选择的建筑模式,可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑,Chichen-Itza大金字塔,九个巨大的石级堆垒而上,九十一级台阶(象征着四季的天数)夺路而出,塔顶的神殿耸入云天。
所有的数字都如日历般严谨,风格雄浑。
难以想象这是石器时代的建筑物。
图1、位于墨西哥Chichen-Itza(在玛雅语中chi意为嘴chen意为井)的古玛雅建筑。
(摄影:作者)软件与人类的关系是架构师必须面对的核心问题,也是自从软件进入历史舞台之后就出现的问题。
与此类似地,自从有了建筑以来,建筑与人类的关系就一直是建筑设计师必须面对的核心问题。
英国首相丘吉尔说,我们构造建筑物,然后建筑物构造我们(We shape our buildings, and afterwards our buildings shape us)。
英国下议院的会议厅较狭窄,无法使所有的下议院议员面向同一个方向入座,而必须分成两侧入座。
丘吉尔认为,议员们入座的时候自然会选择与自己政见相同的人同时入座,而这就是英国政党制的起源。
Party这个词的原意就是"方"、"面"。
政党起源的要害就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的,形式必须服从功能。
与此类似地,在建筑学界,现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能(Forms follows function)。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。
最为闻名的,当然就是模式理论和XP理论。
架构的目标是什么正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:·可靠性(Reliable)。
软件系统对于用户的商业经营和治理来说极为重要,因此软件系统必须非常可靠。
·安全行(Secure)。
软件系统所承担的交易的商业价值极高,系统的安全性非常重要。
·可扩展性(Scalable)。
软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。
只有这样,才能适应用户的市场扩展得可能性。
·可定制化(Customizable)。
同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性(Extensible)。
在新技术出现的时候,一个软件系统应当答应导入新技术,从而对现有系统进行功能和性能的扩展·可维护性(Maintainable)。
软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。
一个易于维护的系统可以有效地降低技术支持的花费·客户体验(Customer Experience)。
软件系统必须易于使用。
·市场时机(Time to Market)。
软件用户要面临同业竞争,软件提供商也要面临同业竞争。
以最快的速度争夺市场先机非常重要。
架构的种类根据我们关注的角度不同,可以将架构分成三种:·逻辑架构、软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出,此系统被划分成三个逻辑层次,即表象层次,商业层次和数据持久层次。
每一个层次都含有多个逻辑元件。
比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构,图中所有的元件都是物理设备,包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图3、一个物理架构的例子·系统架构、系统的非功能性特征,如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这一工作无疑是架构设计工作中最为困难的工作。
此外,从每一个角度上看,都可以看到架构的两要素:元件划分和设计决定。
首先,一个软件系统中的元件首先是逻辑元件。
这些逻辑元件如何放到硬件上,以及这些元件如何为整...
软件设计中系统架构设计包括哪些内容
软件架构 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。
在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。
特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。
”[GS93] 但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。
软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。
概要设计和详细设计怎么写 知乎
撰写的设计文档主要分为:总体概要设计文档 + 详细设计文档,后简称为“概设”+“详设”。
总设和详设都应该包含的部分:(1) 需求:一般以产品的语言描述,这一块可以拷贝产品需求文档中的story list部分;(2) 名词解释(可选):非相关领域内的同学需要看到文档需要提前了解的一些概念性质的东西;(3) 设计目标:又分为功能目标和性能目标,功能目标一般是对产品需求的技术描述,性能目标是根据产品给出的数据对性能进行的评估。
一般来说,新服务必须要有性能目标一项,性能目标可能会影响设计方案。
除了都应该包含的部分,总体概要设计一般还包含:(1) 系统架构:一般来说会有个简单的架构图,并配以文字对架构进行简要说明;(2) 模块简介:架构图中如果有很多模块,需要对各个模块的功能进行简要介绍;(3) 设计与折衷:设计与折衷是总体概要设计中最重要的部分;(4) 潜在风险(可选);输出总体概要设计的时候,很多方案还是不确定的,需要在设计评审会议上确认。
总体概要设计重点在“方案折衷”,总体概要设计评审完毕之后,此时应该是所有方案都确认了,需要输出各模块的详细设计,详细设计重点在“详细”:(1)总体概要设计结论汇总(可选):达成一致的结论有个简要概述,说明详设是对这些结论的实现;(2)交互流程:简要的交互可用文字说明,复杂的交互建议使用流程图,交互图或其他图形进行说明;(3)数据库设计:这个是应该放在总设还是详设呢?(4)接口形式:有了数据库+接口+流程,别的同学拿到详设文档,基本也能够搞定了;(5)其他细节:例如公式等;理论上输出了详细设计之后,无论谁拿到了这个详设文档,都是能够完成该项目的。
个人实践分享:一、 大图(1) 大系统或复杂流程,其架构图或者流程图会非常大,经常比A4纸或word的一页大很多,此时不宜在word中直接贴图形,贴了也看不清,建议将图放在wiki上,文档中直接贴链接;(2) 一定要保存viso或者其他图形的源文件,否则今后改动起来要重画,代价可想而知;二、 设计与折衷(1) 设计与折衷是总设中最重要的内容,总设评审中,主要就是讨论这些折衷的优劣;(2) 评审过后,不但要邮件周知结论,还要在总设中进行更新,说明最终决定使用了哪种方案,为什么使用这种方案;根据自己的经验,接手别人的模块、项目,拿到代码和文档,设计方案对我来说完全是个谜!!!(3) 有时候因为排期或者其他原因,不一定采用了最优的设计方案,此时更应该在总设中记录决策的过程与原因;(4) 最后,设计折衷是一个很好的自我辩解的机会:因为项目进度,或者历史遗留问题,我不得不采取了一个这样的设计,不要再骂我了。
三、 性能目标性能目标是新模块文档必不可少的一部分,很多项目对性能影响较大的话,也必须撰写性能目标,性能一般来说可能包含以下部分:(1) 日平均请求:一般来自产品人员的评估;(2) 平均QPS:日平均请求 除以 4w秒得出,为什么是4w秒呢,24小时化为86400秒,取用户活跃时间为白天算,除2得4w秒;(3) 峰值QPS:一般可以以QPS的2~4倍计算;互联网公司,产品迭代块,项目周期长,基本没有“文档”一说,但其实写好文档,对系统和项目未来的维护是非常有帮助的。
进行软件架构设计有什么样的益处?
一般来说,软件架构设计是降低成本,改进质量,按时交付产品和按需交付产品的关键因素。
在这篇文章中,我将会把讨论的焦点放在实现这些目标所能带来的好处上面。
作为一个构架师,证明我们的存在是没有任何意义的。
这个部分将会提供一些方法,这些方法对于把处理架构设计作为一个软件开发过程的关键部分是很有用处的。
架构设计能够满足系统的品质 系统的功能性是软件构架师通过组成体系架构的多种元素之间的交互作用来支持的。
然而,架构设计的一个关键特性是,系统的品质是通过某些手段来实现的。
软件的品质,例如性能,安全性和可维护性等,它们在缺少统一的架构设计视图时是无法实现的,因为这些品质并不是被限制在一个单一的架构设计元素中,而是渗透在整个架构设计体系中的。
例如,为了满足性能要求,可能需要考虑体系架构中的每一个组件的实现时间,同时还要考虑各组件之间通讯所花费的时间。
同样地,为了满足安全性要求,可能需要考虑两个组件之间自然的通讯,并且要在需要的特定的地方引入安全性提示组件。
所有的这些关系都属于体系架构,在上面的例子中,这些关系包括组件自身的和组件之间的。