精华内容
下载资源
问答
  • 变电工程初步设计阶段设计招标表汇总.doc
  • 215;215;工程初步设计阶段专业互提资料深度要求内容.doc
  • 初步设计阶段BIM协同造价管理模式的设计与实现
  • 215;215;工程初步设计阶段水电建设项目截流设计大纲范本.doc
  • 某路段延长线初步设计阶段审查咨询报告.doc
  • 项目实施建议书、可行性研究报告、初步设计阶段报告编制要求.docx
  • 计算得出3种初步设计方案钢斜拉桥在施工阶段结构的弹性稳定安全系数为4.9~10.2,非线性稳定安全系数为2.1~7.9,表明3种方案钢斜拉桥在施工全过程中的弹性稳定性和非线性稳定性都是足够的。最后,评价了施工过程中...
  • 兴山县古夫镇郑家坪大桥两阶段初步设计评审汇报.pptx
  • 项目实施建议书、可行性研究、初步设计方案三阶段报告编制要求.doc
  • 总体设计(概要设计或初步设计)的基本目的就是回答“概括地说,系统应该如何实现?” 工作内容:将划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等黑盒子级“产品”。黑盒子里的具体内容将在...

    基本目的:“概括回答地说就是,系统应该如何实现?”

    工作内容: 将划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等黑盒子级“产品”。黑盒子里的具体内容将在以后仔细设计。

    重要任务: 是设计软件的结构——模块组成,以及这些模块相互间的关系。
    首先根据需求分析阶段得到的数据流图寻找实现目标系统的各种不同的方案,为每个合理的方案准备一份系统流程图,列出组成系统的所有物理元素,进行成本/效益分析,并且制定实现这个方案的进度计划。选出一个最佳方案向用户推荐。

    必要性(详细设计之前): 站在全局高度上,花较少成本,从较抽象的层次上分析对比多种可能的系统实现方案和软件结构,从中选出最佳方案和最合理的软件结构,降低成本、提高质量。

    一、设计过程

    • 系统设计阶段:确定系统的具体实现方案;
    • 结构设计阶段:确定软件结构。

    (一) 9个步骤

    典型的总体设计过程包括下述9个步骤

    1. 设想供选择的方案

    • 考虑各种可能的实现方案从中选出最佳
    • 根据系统的逻辑模型,分析比较不同的物理实现方案,选出最佳方案,提高系统的性/价比。
    • 由需求分析的数据流图作为出发点,把数据流图中的处理分组的各种可能的方法,抛弃在技术上行不通的分组方法,提供可供选择的物理系统。

    2. 选取合理的方案

    选取低成本、中等成本和高成本的三种方案,对每个合理的方案分析员都应该准备下列4份资料
    (1) 系统流程图;
    (2) 组成系统的物理元素清单;
    (3) 成本/效益分析;
    (4) 实现这个系统的进度计划。

    3. 推荐最佳方案

    推荐一个最佳的方案,并且为推荐的方案制定详细的实现计划。
    提请使用部门负责人进一步审批之后,将进入总体设计过程的下一个重要阶段——结构设计。

    4. 功能分解

    1. 程序和文件(或数据库)是组成系统的主要元素,需要设计决定。
    2. 对程序的设计通常分为两个阶段完成:结构设计和过程设计。
    3. 结构设计确定程序由哪些模块组成,以及这些模块之间的关系(总体设计);
    4. 过程设计确定每个模块的处理过程(详细设计)。
    5. 为确定软件结构,首先需要从实现角度把复杂的功能进一步分解。
    6. 经过分解之后应该使每个功能对大多数程序员而言都是明显易懂的。
    7. 功能分解导致数据流图的进一步细化,同时还应该用IPO图或其他适当的工具简要描述细化后每个处理的算法。

    5. 设计软件结构

    1. 通常程序中的一个模块完成一个适当的子功能,将模块组织成良好的层次系统,顶层模块调用下层模块以实现程序的完整功能
    2. 软件结构(即由模块组成的层次系统)可以用层次图或结构图来描绘。
    3. 若数据流图细化到适当的层次,则可以直接从数据流图映射出软件结构。

    6. 设计数据库

    1. 对于需要使用数据库的应用系统,软件工程师应该在需求分析阶段所确定的系统数据需求的基础上,进一步设计数据库。
    2. 在数据库课中已经详细讲述了设计数据库的方法,本书不再赘述。

    7. 制定测试计划

    在软件开发的早期阶段考虑测试问题,能促使软件设计人员在设计时注意提高软件的可测试性。
    本书第7章将仔细讨论软件测试的目的和设计测试方案的各种技术方法。

    8. 书写文档

    完成的文档通常有下述几种:

    1. 用系统流程图描绘的系统构成方案,组成系统的物理元素清单,成本/效益分析;对最佳方案的概括描述,精化的数据流图,用层次图或结构图描绘的软件结构,用IPO图或其他工具(例如,PDL语言)简要描述的各个模块的算法,模块间的接口关系,以及需求、功能和模块三者之间的交叉参照关系等等。
    2. 用户手册根据总体设计阶段的结果,修改更正在需求分析阶段产生的初步的用户手册。
    3. 测试计划包括测试策略,测试方案,预期的测试结果,测试进度计划等等。
    4. 详细的实现计划
    5. 数据库设计结果
    6. 审查和复审

    最后应该对总体设计的结果进行严格的技术审查,在技术审查通过之后再由使用部门的负责人从管理角度进行复审。
    在这里插入图片描述
    在这里插入图片描述软件设计工作流程

    二、设计原理

    (一) 模块化

    “模块”,又称“构件” 。

    • 过程、函数、子程序和宏等,都可作为模块;面向对象方法学中的对象是模块,对象内的方法(或称为服务)也是模块。模块是构成程序的基本构件。
    • 模块化就是把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,把这些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求。
    • 模块化是为了使一个复杂的大型程序能被人的智力所管理,化繁为简、化难为易、化整为零。

    设函数C(x)定义问题x的复杂程度,函数E(x)确定解决问题x需要的工作量(时间)。对于两个问题P1和P2,如果C(P1)>C(P2),显然E(P1)>E(P2)。
    C(P1+P2)>C(P1)+C(P2)
    E(P1+P2)>E(P1)+E(P2)
    这就是模块化的根据。
    在这里插入图片描述
    在这里插入图片描述

    (二)抽象

    • 抽象就是抽出事物的本质特性而暂时不考虑它们的细节。

    • 处理复杂系统的有效的方法是用层次的方式构造和分析它。一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解,这些高级概念又可以用一些较低级的概念构造和理解,如此进行下去,直至最低层次的具体元素。

    • 任何问题的模块化时,可提出许多抽象的层次。
      在抽象的最高层次使用问题环境的语言,以概括的方式叙述问题的解法;
      较低抽象层次采用更过程化的方法,把面向问题的术语和面向实现的术语结合起来叙述问题的解法;
      最后在最低的抽象层次用可直接实现的方式叙述问题的解法。

    • 软件工程过程的每一步都是对软件解法的抽象层次的一次精化。
      可行性研究阶段,软件作为系统的一个完整部件;
      需求分析期间,软件解法是使用在问题环境内熟悉的方式描述的;
      由总体设计向详细设计过渡时,抽象的程度也就随之减少了;
      最后,当源程序写出来以后,也就达到了抽象的最低层。

    • 逐步求精和模块化的概念,与抽象是紧密相关的。
      软件结构顶层的模块,控制了系统的主要功能并且影响全局;
      在软件结构底层的模块,完成对数据的一个具体处理,用自顶向下由抽象到具体的方式分配控制,简化了软件的设计和实现,提高了软件的可理解性和可测试性,并且使软件更容易维护。

    (三)逐步求精

    逐步求精是人类解决复杂问题时采用的基本方法,逐步求精可定义为:“为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。”
    逐步求精之所以如此重要,是因为人类的认知过程遵守Miller法则:一个人在任何时候都只能把注意力集中在(7±2)个知识块上。
    Miller法则是人类智力的基本局限,我们不可能战胜自己的自然本性,只能接受这个事实,承认自身的局限性,并在这个前提下尽我们的最大努力工作。
    逐步求精最初是由Niklaus Wirth提出的一种自顶向下的设计策略, Wirth曾说:
    “我们对付复杂问题的最重要的办法是抽象,因此,对一个复杂的问题不应该立刻用计算机指令、数字和逻辑符号来表示,而应该用较自然的抽象语句来表示,从而得出抽象程序。抽象程序对抽象的数据进行某些特定的运算并用某些合适的记号(可能是自然语言)来表示。对抽象程序做进一步的分解,并进入下一个抽象层次,这样的精细化过程一直进行下去,直到程序能被计算机接受为止。这时的程序可能是用某种高级语言或机器指令书写的。”
    求精要求设计者细化原始陈述,随着每个后续求精(即细化)步骤的完成而提供越来越多的细节。

    • 抽象与求精是一对互补的概念。
    • 抽象使得设计者能够说明过程和数据,同时却忽略低层细节。
    • 求精则帮助设计者在设计过程中逐步揭示出低层细节。
    • 这两个概念都有助于设计者在设计演化过程中创造出完整的设计模型。
      在这里插入图片描述

    (四) 信息隐藏和局部化

    如何得到最好的一组模块?

    • 信息隐藏原理指出:设计一个模块,使得包含的信息(过程和数据) 对于不需要这些信息的模块来说,是不能访问的。
    • 局部化是指把一些关系密切的软件元素
    • 物理地放得彼此靠近。
    • 在模块中使用局部数据元素是局部化的一个例子。局部化有助于实现信息隐藏。

    (五) 模块独立

    模块独立是模块化、抽象、信息隐藏和局部化概念的直接结果。
    希望这样设计软件结构,使得每个模块完成一个相对独立的特定子功能,并且和其他模块之间的关系很简单。

    模块独立的两条理由:
    第一,有效的模块化(即具有独立的模块)的软件比较容易开发。
    因为功能简单而且接口可简化,当许多人分工合作时这个优点尤其重要。
    第二,独立的模块比较容易测试和维护。
    模块独立是设计的关键,而设计又是决定软件质量的关键环节。
    模块的独立程度可以由两个定性标准度量,分别称为内聚和耦合。

    • 耦合用于衡量不同模块彼此间互相依赖(连接)的紧密程度;
    • 内聚衡量一个模块内部各个元素彼此结合的紧密程度。
    • 模块独立要求:高内聚、低耦合;
    • 耦合
      耦合是对一个软件结构内不同模块之间互连程度的度量。
      耦合强弱取决于模块间接口的复杂程度,进入或访问一个模块的点,以及通过接口的数据。
      模块间的耦合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性。
      在软件设计中应该追求尽可能松散耦合的系统。
      模块分解的一个目标是使块间联系尽可能小,块间联系的大小可从三个方面衡量:
      在这里插入图片描述
      在这里插入图片描述
      (1)内容耦合(content coupling)
      一个模块直接访问另一模块的内部数据。
      一个模块不通过正常入口转到另一模块的内部。
      一个模块有多个入口。
      两个模块有部分代码重迭。
      在这里插入图片描述
      (2)公共耦合(common coupling)
      若干模块访问一个公共的数据环境,则它们之间的耦合称为公共耦合。公共环境可为全局数据结构、共享的通信区、内存的公共覆盖区等。显然,公共数据区的变化,将影响所有公共耦合模块,严重影响模块的可靠性和可适应性,降低软件的可读性。
      在这里插入图片描述
      (3)控制耦合(control coupling)
      一个模块传递给另一模块的信息是用于控制该模块内部逻辑的控制信号。
      显然,对被控制模块的任何修改,都会影响控制模块。
      在这里插入图片描述
      (4)复合耦合(Data Coupling)
      一个模块传送给另一个模块的参数是一个复合的数据结构,例如,包含几个数据单项的记录。

    (5)数据耦合(Data Coupling)
    若两个模块间通过参数交换信息,而且交换的信息仅仅是数据。数据耦合是松散的耦合,模块之间的独立性比较强。
    2. 内聚
    内聚标志一个模块内各个元素彼此结合的紧密程度,它是信息隐藏和局部化概念的自然扩展。
    理想内聚的模块只做一件事情。
    设计时应该力求做到高内聚,通常中等程度的内聚也是可以采用的,而且效果和高内聚相差不多;但是,低内聚很坏,不要使用。
    内聚性愈强,模块独立性愈好。
    在这里插入图片描述
    偶然内聚:
    模块内部各部件之间没有任何关系,仅仅为了满足模块尺寸要求而将一些程序合入一可模块,出现错误时,难以确定位置;
    在这里插入图片描述
    逻辑内聚:
    这种模块把几种相关的功能组合在一起,每次调用时,由传送给模块的判断参数来确定该模块应执行那种功能。
    在这里插入图片描述
    瞬时内聚:
    模块包含的任务必须在同一段时间内执行,由于不使用选择参数,逻辑简单,但结合了许多无关任务,错误难以定位。
    例如:各种初始化。

    通信内聚:
    模块中所有的部件都访问同一组数据,几个部件之间有数据关系而无控制关系。
    优点:可通过参数选择不同的作用,是一种较理想的内聚。在这里插入图片描述

    顺序内聚:
    模块完成多个功能,各个功能都在同一数据结构上操作,每项功能有唯一的入口点。
    较好的内聚。
    在这里插入图片描述
    功能内聚:
    模块内所有部件处理同一组数据,共同完成单一的功能,是最理想的内聚之一。
    在这里插入图片描述

    三、启发规则

    在长期的软件开发实践中,总结经验,得出了一些启发式规则。
    没有基本原理和概念那样普遍适用,在改进软件设计,提高软件质量有积极意义。
     下面介绍几条启发式规则。
      1.改进软件结构提高模块独立性
      2.模块规模应该适中
      3. 深度、宽度、扇出和扇入都应适当
      4. 模块的作用域应该在控制域之内
      5. 力争降低模块接口的复杂程度
      6. 设计单入口单出口的模块
      7. 模块功能应该可以预测

    四、描绘软件结构的图形工具

    (一) 层次图和HIPO图

    层次图用来描绘软件的层次结构。
    在这里插入图片描述

    (二)结构图

    结构图也是描绘软件结构的图形工具。
    一个方框代表一个模块,框内注明模块的名字或主要功能;方框之间的箭头(或直线)表示模块的调用关系。
    尾部是空心圆表示传递的是数据,实心圆表示传递的是控制信息。
    在这里插入图片描述

    (三)结构图

    有一些附加的符号,可以表示模块的选择调用或循环调用。
    如左图表示当模块M中某个判定为真时调用模块A,为假时调用模块B。如右图表示模块M循环调用模块A、B和C。

    五、 面向数据流的设计方法

    面向数据流的设计方法的目标是给出设计软件结构的一个系统化的途径。
    因为任何软件系统都可以用数据流图表示,所以面向数据流的设计方法理论上可以设计任何软件的结构。
    通常所说的结构化设计方法(简称SD方法),也就是基于数据流的设计方法。

    (一)概念

    面向数据流的设计方法把信息流映射成软件结构,信息流的类型决定了映射的方法。信息流有下述两种类型。

    1. 变换流
      在这里插入图片描述
    2. 事务流
      如图所示,数据流是“以事务为中心的”,即数据沿输入通路到达一个处理T,根据输入数据的类型选出一个来执行。这类数据流应该划为一类特殊的数据流,称为事务流。
      在这里插入图片描述
      如图处理T称为事务中心,它完成下述任务:
      (1) 接收输入数据(输入数据又称为事务);
      (2) 分析每个事务以确定它的类型;
      (3) 根据事务类型选取一条活动通路。

    3 设计过程
    基于数据流方法的设计过程
    在这里插入图片描述

    (二) 变换分析

    变换分析把具有变换流特点的数据流图按预先确定的模式映射成软件结构。
     
    中心变换型(transform center)— 变换分析
    其特点是:DFD图可以明显分为“输入-处理-输出”三部分。
    在这里插入图片描述
     事务处理型(transaction)— 事务分析
      这类数据流图可看成是对一个数据经过某种加工后,按加工的结果选择一个输出数据流继续执行的处理。
    在这里插入图片描述

    (三)事务分析技术

    ① 确定流界:首先从数据流图中找出事务流、事务处理中心和事务路径。
    ② 进行一级分析,设计上层模块:对事务中心应设计“事物控制”模块;对事物流应设计“接受事物”模块;对事务路径,应设计“发送控制”模块。
    ③ 进行二级分解,设计中下层模块:接受分支,用类似于转换处理型数据流图中对输入数据流的方法设计中下层。对于发送分支,在发送控制模块下为每条事务路径设计一个事务处理模块,这一层称为事务层。
    在这里插入图片描述

    (四) 设计优化

    设计优化应力求做到在有效的模块化的前提下使用最少量的模块,以及在能够满足信息要求的前提下使用最简单的数据结构。
    对于时间是决定性因素的场合,下述方法对软件进行优化是合理的:

    • (1)在不考虑时间因素的前提下开发并精化软件结构;

    • (2)在详细设计阶段选出最耗费时间的那些模块,仔细地设计它们的处理过程(算法),以求提高效率;

    • (3) 使用高级程序设计语言编写程序;

    • (4) 在软件中孤立出那些大量占用处理机资源的模块;

    • (5) 必要时重新设计或用依赖于机器的语言重写上述大量占用资源的模块的代码,以求提高效率。

    上述优化方法遵守了一句格言:“先使它能工作,然后再使它快起来。”

    展开全文
  • 公路设计阶段

    千次阅读 2012-03-28 17:04:42
    公路设计阶段  公路勘测设计是指具体完成一条公路所进行的外业勘测和内业设计的全部工作。由于涉及面广、影响因素多,必须经历一个调查研究范围由大到小、工作深度由粗到细的过程。按照公路的使用性质、技术等级...

    公路设计阶段

      公路勘测设计是指具体完成一条公路所进行的外业勘测和内业设计的全部工作。由于涉及面广、影响因素多,必须经历一个调查研究范围由大到小、工作深度由粗到细的过程。按照公路的使用性质、技术等级和建设规模,通常分成:一阶段、二阶段、三阶段三种设计方式进行。
      (1)一阶段设计:适用于技术简单、方案明确的小型建设项目,也称为一阶段施工图设计。一阶段施工图设计应相应采用一次定测,即不经过初测和初步设计,按照工程可行性研究报告或计划任务书所确定的修建原则和路线走向方案,在现场进行方案比选与优化,及时完成纵断面设计、横断面设计以及桥涵、防护工程等的布置,以便及时综合检查和修改。对地形十分复杂、现场定线很困难的地段,也可先测导线、测绘地形图进行纸上定线后再实地放线。
      (2)两阶段设计:公路设计一般都采用两阶段,包括:初测--初步设计----设计概算;定测—施工图设计----施工图预算。初步设计根据批复的可行性研究报告、测设合同和初测资料编制;施工图设计根据批复的初步设计、定测合同和定测资料编制。
      (3)三阶段设计:对于技术上复杂、基础资料缺乏和不足的建设项目或建设项目中的特大桥、互通式立体交叉、隧道、高速公路和一级公路的交通工程及沿线设计中的机电设备等,必要时采用三阶段设计,即:初测----初步设计----设计概算;定测----技术设计----修正概算;补充定测----施工图设计----施工图预算。技术设计应根据批复的初步设计、测设合同和定测、详勘资料编制;施工图设计应根据批复的技术设计、测设合同和补充定测、补充详勘资料编制。
       什么是初步设计
      初步设计阶段的主要目的是确定设计方案.必须根据批复的可行性研究报告、测设合同的要求,拟定修建原则,选定设计方案,计算工程数量及主要材料数量,提出施工方案的意见,编制设计概算,提供文字说明及图表资料。初步设计文件经审查批复后,则为订购主要材料、机具、设备,安排重大科研试验项目,联系征用土地、拆迁,进行施工准备,编制施工图设计文件和控制建设项目投资等的依据。采用三阶段设计时,经审查批复的初步设计亦为编制技术设计文件的依据。
      初步设计在选定方案时,应对路线的走向、控制点和方案进行现场核查,征求沿线地方政府和建设单位意见,基本落实路线布置方案,一般应进行纸上定线,赴实地核对,落实并放出必要的控制线位桩。对复杂困难地段的路线、互通式立体交叉、隧道、特大桥、大桥的位置等,一般应选择两个或两个以上的方案进行同深度、同精度的测设工作和方案比选,提出推荐方案。
      初步设计应完成的任务如下:
      选定路线设计方案,基本确定路线位置;
      基本查明沿线地质、水文、气候、地震等情况;基本查明沿线筑路材料的质量、储量、供应量及运输,并进行原材料、混合料的试验;
      基本确定排水系统与防护工程的位置、路线长度、结构形式和尺寸;
      基本确定路基标准横断面和特殊路基横断面的设计方案及沿线路基取土、弃土方案,计算路基土石方数量并进行调配;
      基本确定路面设计方案、路面结构类型及主要尺寸;
      基本确定特大、大、中桥桥位,设计方案,结构类型及主要尺寸;
      基本确定小桥、涵洞、漫水桥及过水路面等的位置、结构类型及主要尺寸;
      基本确定隧道位置、设计方案、结构类型及主要尺寸;
      基本确定路线交叉的位置、形式、结构类型及主要尺寸;
      基本确定通道及人行天桥的位置、形式、结构类型及主要尺寸;
      基本确定交通工程及沿线设施各项工程的位置、类型及主要尺寸;
      基本确定环境保护的内容、措施及方案;
      基本确定渡口码头的位置、结构形式及主要尺寸;
      基本确定占用土地、拆迁建筑物及电力、电讯等设施的数量;
      提出需要试验、研究的项目;
      初步拟定施工方案;
      计算各项工程数量;
      计算人工及主要材料、机具、设备的数量;
      编制设计概算;
      经论证确定分期修建的工程实施方案(含交通工程及沿线设施)。
       什么是技术设计?
      技术设计是在技术上复杂、基础资料缺乏和不足的建设项目或建设项目中的特大桥、互通式立体交叉、隧道、高速公路和一级公路的交通工程及沿线设施中的机电设备设计中所增加的一个阶段的工作。目的是根据初步设计批复意见、测设合同的要求,对重大、复杂的技术问题通过科学试验、专题研究,加深勘探调查及分析比较,解决初步设计中未解决的问题,落实技术方案,计算工程数量,提出修正的施工方案,修正设计概算。具体要求是:
      ①对初步设计所定方案详加研究,进一步补充和修改;
      ②补充必要的地质、水文、气象、地震和地质钻探资料,以及土工、材料结构或模型试验成果;
      ③提出科学试验成果、专题报告;
      ④提出修正的施工方案;
      ⑤编制修正概算。
      技术设计批准后即成为编制施工图设计的依据。
       什么是施工图设计?
      两阶段(或三阶段)施工图设计是在两阶段初步设计(或三阶段技术设计)的基础上,根据批复意见和测设合同要求,进一步对所审定的修建原则、设计方案、技术决定加以具体和深化,最终确定各项工程数量,提出文字说明和适应施工需要的图表资料以及施工组织计划,并编制施工预算。一阶段施工图设计则是根据可行性研究报告批复意见和测设合同,拟定修建原则,确定设计方案和工程数量,提出文字说明和图表资料以及施工组织计划,编制施工图预算,满足审批要求和适应施工的需要。
      施工图设计应完成的任务有:
      确定路线具体位置;
      确定路基标准横断面和特殊路基横断面,绘制路基超高、加宽设计图;计算土石方数量并进行调配;确定路基取土、弃土的位置,绘制取土坑纵、横断面图;
      确定路基路面排水系统和防护工程的结构类型和尺寸,绘制相应布置图和结构设计图;
      确定特殊路基设计的结构类型及尺寸,绘制特殊路基设计图;
      确定各路段的路面结构类型及尺寸,绘制路面结构图;
      确定特大、大、中桥的位置、孔数及孔径、结构类型及各部尺寸,绘制结构设计图;
      确定小桥、涵洞、漫水桥、过水路面等位置、孔数及孔径、结构类型及各部尺寸,绘制布置图。特殊设计的,应绘制特殊设计详图;
      确定隧道及其附属设施的形式及尺寸,绘制布置图和设计详图。
      确定路线交叉形式、结构类型及各部尺寸,绘制布置图及设计详图;
      确定交通工程及沿线设施的各项工程的位置、类型及各部尺寸,绘制布置图和设计详图。
      确定环境保护设施的位置、类型及数量,绘制布置图及设计详图;
      确定渡口码头及其它工程的位置、结构形式及尺寸,绘制相应的位置图和设计详图;
      落实沿线筑路材料的质量、储藏量、供应量及运距,绘制筑路材料运输示意图;
      确定征用土地、拆迁建筑物以及电力、电讯等的数量;
      计算各项工程数量;
      提出施工组织计划;
      提出人工数量及主要材料、机具、设备的规格及数量;
      编制施工图预算。
    展开全文
  • 初步设计对复杂系统的意义

    千次阅读 2015-01-04 11:07:59
    所谓鲁棒性分析是这样一种方法:通过分析用例规约中的事件流,识别出实现用例规定的功能所需的主要对象及其职责,形成以职责模型为主的初步设计。 --温昱,《软件架构设计》 ADMEMS方法的Conceptual Architecture...

    好的开始是成功的一半。

    --谚语

    所谓鲁棒性分析是这样一种方法:通过分析用例规约中的事件流,识别出实现用例规定的功能所需的主要对象及其职责,形成以职责模型为主的初步设计。

    --温昱,《软件架构设计》

    ADMEMS方法的Conceptual Architecture阶段包含3个步骤:

    第1步,初步设计。

    第2步,高层分割。

    第3步,考虑非功能需求。

    本章讲解如何根据关键功能,借助鲁棒图进行初步设计。

    8.1  初步设计对复杂系统的意义

    初步设计并不总是必须的--架构师只有在设计复杂系统时才需要它。

    另外,"复杂"与否还和"熟悉"程度有关。一个"很小"的系统涉及你未接触过的领域,你会觉得它挺复杂;一个"较大"的系统,但你有很具体的经验,你依然会觉得它"Just so so"。

    初步设计的目标简单而明确:那就是发现职责。初步设计无须展开架构设计细节,否则就背上了"包袱",这是复杂系统架构设计起步时的大忌。正如"初步设计"这个名字所暗示的,它只是狭义的架构设计的"第一枪"--之前的Pre-architecture阶段并未对"系统"做任何"切分"。

    "初步设计"这个名字还暗示我们,后续的架构设计工作必然以之为基础。具体而言,初步设计识别出了职责,后续的高层分割方案才有依据,因为每个"高层分割单元"都是职责的承载体,而分割的目的也恰恰在于规划高层职责模型。

    ADMEMS方法强调"关键需求决定架构"的策略,"基于关键功能,进行初步设计"就是一个具体体现。如第3章3.4.1节所述,系统的每个功能都是由一条"职责协作链"完成的;而初步设计的具体思路正是"通过为功能规划职责协作链来发现职责"(如图8-1所示)。

     

     

    -------------------------------------------------------------------------------------------------------------------

    8.2  鲁棒图简介

    ADMEMS方法推荐以鲁棒图来辅助初步设计。那么,什么是鲁棒图呢?

    8.2.1  鲁棒图的3种元素

    鲁棒图包含3种元素(如图8-2所示),它们分别是边界对象、控制对象、实体对象:

    边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入,处理内部内容的解释,并表达或传递相应的结果。

    控制对象对行为进行封装,描述用例中事件流的控制行为。

    实体对象对信息进行描述,它往往来自领域概念,和领域模型中的对象有良好的对应关系。

     

    海象不是象,如此命名是因为"类比思维"在人的头脑中是根深蒂固的。关于鲁棒图3元素的"类比",自然是MVC。在图8-3中,我们做了更全面地对比,我们发现鲁棒图3元素和MVC还是有着不小的差异的。

     

    由图可以看出,鲁棒图3元素和MVC的主要不同在于:

    View仅涵盖了"用户界面"元素的抽象,而鲁棒图的边界对象全面涵盖了三种交互,即本系统和外部"人"的交互、本系统和外部"系统"的交互、本系统和外部"设备"的交互。

    数据访问逻辑是Controller吗?不是。控制对象广泛涵盖了应用逻辑、业务逻辑、数据访问逻辑的抽象,而MVC的Controller主要对应于应用逻辑。

    MVC的Model对应于经典的业务逻辑部分,而鲁棒图的实体对象更像"数据"的代名词--用实体对象建模的数据既可以是持久化的,也可以仅存在于内存中,并不像有的实践者理解的那样直接就等同于持久化对象。

     

    --------------------------------------------------------------------------------------------------------------

    8.2.2  鲁棒图一例

      

    为了实现销户的功能,银行工作人员要访问3个"边界对象":

    活期账户销户界面。

    磁条读取设备。

    打印设备。

    "销户"是一个"控制对象",和"计算利息"一起进行销户功能的逻辑控制。

    其中,"计算利息"对"活期账户"、"利息率"、"利息税率"这3个"实体对象"进行读取操作。

    而"销户"负责读出"客户资料"……最终销户的完成意味着写入"活期账户"和"销户流水"信息。

     

    8.2.4  为什么叫"鲁棒"图

    也许你会问:"为什么叫'鲁棒'图?它和'鲁棒性'有什么关系?"

    答案是:词汇相同,含义不同。

    软件系统的"鲁棒性(Robustness)"也经常被翻译成"健壮性",同时它和"容错性(Fault Tolerance)"含义相同。具体而言,鲁棒性指当如下情况发生时依然具有正确运行功能的能力:非法输入数据、软硬件单元出现故障、未预料到的操作情况。例如,若机器死机,"本字处理软件"下次启动应能恢复死机前5分钟的编辑内容。再例如,"本3D渲染引擎"遇到图形参数丢失的情况时,应能够以默认值方式呈现,从而将程序崩溃的危险度减小为渲染不正常的危险度。

    而"鲁棒图(Robustness Diagram)"的作用有两点,除了初步设计之外,就是检查用例规约是否正确和完善。"鲁棒图"正是因为第2点作用而得名的--所以严格来讲"鲁棒图(Robustness Diagram)"所指的不是"鲁棒性(Robustness)"。

    从Doug Rosenberg在《用例驱动的UML对象建模应用》的描述中,也可得到上述结论:

    在ICONIX过程中,鲁棒分析扮演了多个必不可少的角色。通过鲁棒分析,您将改进用例文本和静态模型。

    有助于确保用例文本的正确性,且没有指定不合理或不可能的系统行为(基于要使用的一组对象),从而提供了健康性检查(Sanity Check)。这种改进使用例文本的特性从纯粹的用户手册角度变为对象模型上下文中的使用描述。

    有助于确保用例考虑到了所有必需的分支流程,从而提供了完整性和正确性检查。经验表明,为实现这种目标,并编写出遵循某些定义良好的指南的文本,而在绘制鲁棒图上花费的时间,将在绘制时序图时3~4倍地节省下来。

    有利于发现对象,这一点很重要,因为在域建模期间肯定会遗漏一些对象。您还可以发现对象命名冲突的情况,从而避免进一步造成严重的问题。另外,鲁棒分析有利于确保我们在绘制时序图之前确定大部分实体类和边界类。

    如前所述,它缩小了分析和详细设计之间的鸿沟,从而完成了初步设计。

     

    --------------------------------------------------------------------------------------

    8.2.5  定位

    在本书中,关于鲁棒图最重要的一点是:它是初步设计技术。

    不要再困惑于类似"鲁棒图是分析技术,还是设计技术"这样的问题了。大家只须记住两个公式:

    需求分析 ≠ 系统分析

    系统分析 ≈ 初步设计

    关于"分析"与"设计"的区分,邵维忠教授和杨芙清院士在《面向对象的系统设计》一书中早已做过精彩阐释:

    用"做什么"和"怎么做"来区分分析与设计,是从结构化方法沿袭过来的一种观点。但即使在结构化方法中这种说法也很勉强……

    在"做什么"和"怎么做"的问题上为什么会出现上述矛盾?究其根源,在于人们对软件工程中"分析"这个术语的含义有着不同的理解--有时把它作为需求分析(Requirements Analysis)的简称,有时是指系统分析(Systems Analysis),有时则作为需求分析和系统分析的总称。

    需求分析是软件工程学中的经典术语之一,名副其实的含义应是对用户需求进行分析,旨在产生一份明确、规范的需求定义。从这个意义上讲,"分析是解决做什么而不是解决怎么做"是无可挑剔的。

    但迄今为止,在人们所提出的各种分析方法(包括结构化分析和面向对象分析)中,真正属于需求分析的内容所占的分量并不太大;更多的内容是给出一种系统建模方法(包括一种表示法和相应的建模过程指导),告诉分析员如何建立一个能够满足(由需求定义所描述的)用户需求的系统模型。分析员大量的工作是对系统的应用领域进行调查研究,并抽象地表示这个系统。确切地讲,这些工作应该叫做系统分析,而不是需求分析。它既是对"做什么"问题的进一步明确,也在相当程度上涉及"怎么做"的问题。

    忽略分析、需求分析和系统分析这些术语的不同含义,并在讨论中将它们随意替换,是造成上述矛盾的根源。

    至于实践者为什么常将"需求分析"和"系统分析"混淆,这背后有着重要的现实原因。实际的工程化实践中,需求捕获、需求分析、系统分析不是完全孤立进行的。相反,它们往往是相互伴随、交叉进行的。需求工作伊始,无疑更多地是进行需求捕获工作,相伴进行的需求分析工作占的比例偏少;但随着掌握的需求信息越来越多,我们须要开展的对需求的分析和整理工作也越来越多了;而此时,伴随着对问题的分析,自然而然地会在高层次提出相应的应对策略……这,恰就是系统分析工作。《软件架构设计》一书中有如下阐述:

    需求捕获是获取知识的过程,知识从无到有,从少到多。需求采集者必须理解用户所从事的工作,并且了解用户和客户希望软件系统在哪些方面帮助他们。

    需求分析是挖掘和整理知识的过程,它在已掌握知识的基础上进行。毕竟,初步捕获到的需求信息往往处于不同层次,也有一些主观甚至不正确的信息。而经过必要的需求分析工作之后,需求更加系统、更加有条理、更加全面。

    那么系统分析呢?如果说,需求分析致力于搞清楚软件系统要"做什么"的话,那么系统分析已经开始涉及"怎么做"的问题了。《系统分析》一书中写道:

    简单地说,系统分析的意义如下:"系统分析是针对系统所要面临的问题,搜集相关的资料,以了解产生问题的原因所在,进而提出解决问题的方法与可行的逻辑方案,以满足系统的需求,实现预定的目标。"

    需求捕获、需求分析,以及系统分析之间的关系我们必须理解透彻,否则会影响工作的有效进行。图8-5概括了三者之间的关系。

      

    再次强调,鲁棒图已经"打开"了"系统"这个"黑盒子",将它划分成很多不同的职责,所以它是"设计技术"。

     

    -----------------------------------------------------------------------------------------------------------

    基于鲁棒图进行初步设计的10条经验

    那么,如何借助鲁棒图进行初步设计呢?

    ADMEMS方法归纳了鲁棒图建模的10条经验要点(其中50%是ADMEMS方法的原创经验,另一半来自业界其他专家),分别覆盖语法、思维、技巧、注意事项等4个方面(如图8-6所示),帮助一线架构师快速提升初步设计的能力。

      

    下面将逐一讲解鲁棒图建模的10条经验。

    8.3.1  遵守建模规则

    图8-7展示了鲁棒图的建模规则。Doug Rosenberg在《UML用例驱动对象建模》中写道:

    通过以下4条语句,可以理解该图的本质:

    1)  参与者只能与边界对象交谈。

    2)  边界对象只能与控制对象和参与者交谈。

    3)  实体对象也只能与控制对象交谈。

    4)  控制对象既能与边界对象交谈,也能与控制对象交谈,但不能与参与者交谈。

     

      

     

    遵循3种元素的发现思路

    图8-9说明了发现鲁棒图3种元素的思维方式。

      

    用例(Use Case)=N个场景(Scenario)。每个场景的实现都是一连串的职责进行协作的结果。所以,初步设计可以通过"研究用例执行的不同场景,发现场景背后应该有哪些不同的职责"来完成。

     

    量建模能解决鲁棒图建模卡壳的问题;从大处讲,这种方式适用于所有种类的UML图建模实践。

    例如,类似WinZip、WinRar这样的压缩工具大家都用过。请一起来为其中的"压缩"功能进行基于鲁棒图的初步设计。

    首先,识别最明显的职责。对,就是你自己认为最明显的那几个职责--不要认为设计和建模有严格的标准答案。如图8-10所示,你认为压缩就是把原文件变成压缩包的处理过程,于是识别出了3个职责:

    原文件。

    压缩包。

    压缩器(负责压缩处理)。

      

    接下来,开始考虑职责间的关系,并发现新职责。压缩器读取原文件,最终生成压缩包--嗯,这里可以将打包器独立出来,它是受了压缩器的委托而工作的。哦,还有字典……如图8-11所示。

      

    继续同样的思维方式(别忘了用例规约定义的各种场景是你的"输入",而且,没有文档化的《用例规约》都没关系,你的头脑中有吗?)。图8-12的鲁棒图中间成果,又引入了压缩配置,它影响着压缩器的工作方式,例如加密压缩、分卷压缩或其他。

    ……最终的鲁棒图如图8-13所示。压缩功能还要支持显示压缩进度,以及随时取消进行了一半的压缩工作,所以,你又识别出了压缩行进界面和监听器等职责。

    模型之于人,就像马匹之于人一样--它是工具。如果你不知怎样真正将"模型"为自己所用,反而被"建模"所累(经典的"人骑马、马骑人"的问题),请你问自己一个问题:

    我是不是被太多的假设限制了思维?

    或许,工具本身根本没有这样限制我!

       

       

     

     

    8.3.8  勿关注细节

    初步设计不应关注细节。例如,回顾前面图8-4所示的"销户"的鲁棒图:

    对每个对象只标识对象名,都未识别其属性和方法。

    "活期账户销户界面",具体可能是对话框、Web页面、字符终端界面,但鲁棒图中没有关心这些细节问题。

    "客户资料"等实体对象须要持久化吗?不关心,更不关心用Table还是用File或其他方式持久化。

    没有标识控制流的严格顺序。

     

     

    过分关心UI,会陷入诸如有几个窗口,是不是有一个专门的结果显示页面等诸多细节之中,初步设计就没法做了。

    别忘了,初步设计的目标是发现职责。初步设计无须展开架构设计细节,否则就背上了"包袱",这是复杂系统架构设计起步时的大忌

     

    ---------------------------------------------------------------------------------

     

    展开全文
  • nullnull 一、公路勘察设计阶段 一阶段设计:对于技术简单、方案明确的小型建设项目,可采用,即一阶段施工图设计; 两阶段设计:公路工程基本建设项目一般采用两阶段设计,即初步设计
  • 数据库设计的四个阶段

    万次阅读 2017-10-25 22:06:51
    数据库设计分为四个阶段: 1)需求分析阶段:编写软件规格说明书及初步的用户手册,提交评审。...2)概念设计(概要设计)阶段:E-R图设计阶段。 3)逻辑设计阶段:主要是E_R转换成关系模式。 4)物理设计阶段
    数据库设计分为四个阶段:
    1)需求分析阶段:编写软件规格说明书及初步的用户手册,提交评审。
    2)概念设计(概要设计)阶段:E-R图设计阶段。
    3)逻辑设计阶段:主要是E_R转换成关系模式。
    4)物理设计阶段。
    展开全文
  • 方案设计阶段目标成本形成过程

    千次阅读 2018-06-28 10:34:21
    方案设计阶段目标成本形成过程上级说到各个业务部门的通力合作下完成了投资阶段和启动阶段对应的目标成本土地版和目标成本启动版。并且生成了方案设计任务书。本级将继续讨论在方案设计阶段目标成本的形成过程。在...
  • 城镇智慧水务平台初步设计方案

    千次阅读 2020-03-27 11:23:32
    主智慧水务建设内容及目标 智慧水务建设内容 随着物联网、大数据、云计算及移动互联网等新技术不断融入传统行业的各个环节,新兴技术和智能工业的不断融合,确保居民用水安全,解决取水、供水、用水、排水等问题的...
  • 菜鸟初步设计的开放平台框架

    千次阅读 2016-06-16 10:24:29
    经过一段时间的思考,初步想好了框架怎么搭建,下面是我的框架逻辑视图:此开放平台才从零开始搭建,处在雏形阶段,目前使用的技术主要是oauth2.0,rop开源框架。并准备对rop框架进行一些优化。业务流程:第三方...
  • FLASH阶段复习教学设计 一教材分析 本学期的信息课教材的内容是FLASH动画制作第一单元式Flash动画初步认识包括逐帧动画的制作补间动画的制作动作补间和形状补间动画的制作 二学情分析 学生在前面的几周已学习了Flash...
  • 方案设计阶段的准备工作

    千次阅读 2018-01-27 22:47:05
    也有一些不是研发出身的老板跟我抱怨,硬件工程师让结构先设计、结构工程师说硬件工程师应该先给大致的需求,不知道应该谁先动。 工欲善其事,必先利其器是说:工匠想要使他的工作做好,一定要先让工具锋利。比喻要...
  • Mosila.OA初步设计文档

    千次阅读 2006-03-15 18:59:00
    Mosila.OA 设计草稿设计理念: 做JAVA开发不仅不觉也5年多了,项目做了不少,用过开源的工具和代码也不少,但是为开源社区做的贡献却没有多少。某天特发奇想的想为开源社区作些什么,所以就有了Mosila.OA这个念头...
  •  技术方向主要是用了IP/TCP 和UDP 通信,使用了大量的OSX和windows 底层的API接口,移动端的UI 我只是做了一个简简单单的初步设计(其实就是乱画得),因为我个人在大学也学过一段PS(闲得无聊),所以全部的UI ...
  • 发酵工厂设计主要内容

    千次阅读 2009-08-04 09:56:00
    3.工厂建设前期阶段的工作包括:项目建议书、可行性研究报告、设计任务书、初步设计和总概算5个内容。4.工厂的组成包括:生产车间、辅助车间、动力车间、行政部门、职工宿舍。5.设计阶段按工程规模的大小、工程的...
  • 软件工程各阶段的评审内容

    万次阅读 2015-01-17 17:50:36
    软件工程各阶段的评审内容如下表: 评审点 评审人员 评审文档 评审内容 需求调研评审 用户  管理人员(PM) 软件开发人员 (质量管理人员) (初步)需求规格说明书  (初步)项目开发...
  • 在公司战略与市场方向确定后,选择合适的调研方式,设计、整理调研问题,并给出初步设想答案。2.根据目标用户进行抽样调查,采用录音或笔记的方式收集、记录、挖掘用户需求。3.把收集到的需求整理后进行分类,分别...
  • 内容 :ASIC设计关键问题 来自 :时间的诗 原文:http://blog.sina.com.cn/s/blog_629d62b60100u42r.html ASIC的复杂性不断提高,同时工艺在不断地改进,如何在较短的时间内开发一个稳定的可重用的ASIC芯片的...
  • 软件工程各阶段的评审内容(转载)

    千次阅读 2016-06-21 18:19:02
    软件工程各阶段的评审内容如下表: 评审点 评审人员 评审文档 评审内容 需求调研评审 用户 l  管理人员(PM)  软件开发人员 l (质量管理人员) (初步)需求规格说明书 l  (初步)...
  • 网络逻辑结构设计内容不包括( )。 A.逻辑网络设计图 B.IP地址方案 C.具体的软硬件、广域网和基本服务 D.用户培训计划 正确答案:D 解析: 网络逻辑结构设计输出内容包括以下几点: ・ 网络逻辑设计图 ・ IP地址...
  • 客户端的系统模块的划分客户端详细设计初步进行接口文档的进一步确定用户界面设计的进行 作为客户端的开发者,我在这里主要对前两部分工作进行介绍。 客户端系统模块划分 在第一周我们组就对系统模块进行...
  • DAY 1:五级流水线CPU设计--初步学习

    千次阅读 2019-04-13 09:24:09
    1.前提学习 2.数据通路的构建

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 56,037
精华内容 22,414
关键字:

初步设计阶段内容